March 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBLOGGING-35) Excessive memory consumption by logger nodes

by David Lloyd (JIRA)

Excessive memory consumption by logger nodes -------------------------------------------- Key: JBLOGGING-35 URL: https://jira.jboss.org/jira/browse/JBLOGGING-35 Project: JBoss Logging Issue Type: Bug Security Level: Public (Everyone can see) Components: jboss-logging-logmanager Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.2.0.CR1-jboss-logmanager Using a ConcurrentReferenceHashMap on every logger node to track children is too consumptious of memory. Perhaps a better alternative would be a weak-value variant of FastCopyHashMap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBEE-35) jboss-servlet-api_3.0_spec 1.0.0.Beta1 release missing LocalString.properties

by Shelly McGowan (JIRA)

jboss-servlet-api_3.0_spec 1.0.0.Beta1 release missing LocalString.properties ------------------------------------------------------------------------------ Key: JBEE-35 URL: https://jira.jboss.org/jira/browse/JBEE-35 Project: JBoss JavaEE APIs Issue Type: Bug Reporter: Shelly McGowan Assignee: Shelly McGowan Fix For: 1.0.0.Beta2 Testing the newly released APIs integrated into JBoss AS, the build was successful but the server failed to start due to: 21:56:30,025 INFO [TomcatDeployment] deploy, ctxPath=/invoker 21:56:30,576 INFO [[/invoker]] Marking servlet JMXInvokerServlet as unavailable 21:56:30,577 ERROR [[/invoker]] Servlet /invoker threw load() exception: java.util.MissingResourceException: Can't find bundle for base name javax.servlet.LocalStrings, locale en_US at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1521) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1260) at java.util.ResourceBundle.getBundle(ResourceBundle.java:715) at javax.servlet.GenericServlet.<clinit>(GenericServlet.java:93) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:278) The 1.0.0.Beta1 release does not contain the LocalStrings.properties files: javax/servlet/LocalStrings.properties javax/servlet/http/LocalStrings.properties To ensure these are added to the target jar, I have to add the following to the pom: + <build> + <resources> + <resource> + <directory>src/main/java</directory> + </resource> + </resources> + </build> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JGRP-1122) Revisit critical path in UNICAST

by Bela Ban (JIRA)

Revisit critical path in UNICAST -------------------------------- Key: JGRP-1122 URL: https://jira.jboss.org/jira/browse/JGRP-1122 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 Same as https://jira.jboss.org/jira/browse/JGRP-1104, but for UNICAST. Reduce contention on the down and up directions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
4
0 / 0

[JBoss JIRA] Created: (JGRP-1131) Minimize unicast ACKs

by Bela Ban (JIRA)

Minimize unicast ACKs --------------------- Key: JGRP-1131 URL: https://jira.jboss.org/jira/browse/JGRP-1131 Project: JGroups Issue Type: Sub-task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 Minimize the number of ACK sent. By default, only the highest message of a message batch should be acked, e.g. for 1 4 2 5 3 6 8, 6 should get ack'ed, which would ack all seqnos smaller than 6 as well. We should then not get or send acks for 1-5 (assuming we received 1-8 as a batch) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-1134) UNICAST.down(): move add to retransmitter out of the lock scope

by Bela Ban (JIRA)

UNICAST.down(): move add to retransmitter out of the lock scope --------------------------------------------------------------- Key: JGRP-1134 URL: https://jira.jboss.org/jira/browse/JGRP-1134 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 In UNICAST.down(), we acquire a lock per sender to which we send a message: entry.lock(); // threads will only sync if they access the same entry try { seqno=entry.sent_msgs_seqno; send_conn_id=entry.send_conn_id; hdr=new UnicastHeader(UnicastHeader.DATA, seqno, send_conn_id, seqno == DEFAULT_FIRST_SEQNO); msg.putHeader(getName(), hdr); entry.sent_msgs.add(seqno, msg); // add *including* UnicastHeader, adds to retransmitter entry.sent_msgs_seqno++; } finally { entry.unlock(); } the code entry.sent_msgs.add() is costly as it adds the message to the hashmap, but also to the retransmitter, which schedules a timer task etc. The temp solution is to split add(0 into 2 part, which add the message to the hashmap (fast) and to the retransmitter (costly). The costly part is moved outside the lock scope, for example: entry.lock(); // threads will only sync if they access the same entry try { seqno=entry.sent_msgs_seqno; send_conn_id=entry.send_conn_id; hdr=new UnicastHeader(UnicastHeader.DATA, seqno, send_conn_id, seqno == DEFAULT_FIRST_SEQNO); msg.putHeader(getName(), hdr); entry.sent_msgs.addToMessages(seqno, msg); // add *including* UnicastHeader, adds to hashmap entry.sent_msgs_seqno++; } finally { entry.unlock(); } entry.sent_msgs.addToRetransmitter(seqno, msg); // adds to retransmitter However, the issie is if the addition to the retransmitter fails (e.g. due to an OOME): then we'd have a message gap on the receiver ! SOLUTION: #1 Do the add to the retransmitter in a loop. If there's a failure, sleep a bit and try again. Increase the sleep time and so on. Not very nice code, but works and doesn't ever *lose* a message. OK, if we get OOMEs, then sth's wrong anyway, but this covers temp OOMEs #2 If there's an issue, set a flag. Next time around, we check the flag. If it is set, we re-add all messages in the hashmap into the retransmitter. Involves locking of the hashmaps and retransmitter, but that's OK since this case should almost never happen anyway ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-1105) UNICAST: don't send retransmission messages individually

by Bela Ban (JIRA)

UNICAST: don't send retransmission messages individually -------------------------------------------------------- Key: JGRP-1105 URL: https://jira.jboss.org/jira/browse/JGRP-1105 Project: JGroups Issue Type: Sub-task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 Essentially the same as for NAKACK: instead of adding every message to the retransmitter and creating 1 timer task for it, we create SeqnoRanges in increments of (say) 1000 messages. SeqnoRange #1 is 1-1000, #2 is 1001-2000 and so on. Every SeqnoRange has a low and a high, e.g. lo=1 and high=1000. However, we only retransmit messages with their bit set to 0 from low to bits.length: if we added messages 1-100 to the first range, then low=1, length=100 and high=1000. We only retransmit from 1-100. This creates 1 task in the timer for 1000 messages, instead of 1000 tasks ! When adding a new message (e.g. 101), length() gets automatically adjusted, so retransmission will include 1-101 (only the 0 bits of course). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
6
0 / 0

[JBoss JIRA] Created: (JGRP-1135) UNICAST: add piggybacking of acks

by Bela Ban (JIRA)

UNICAST: add piggybacking of acks --------------------------------- Key: JGRP-1135 URL: https://jira.jboss.org/jira/browse/JGRP-1135 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.10 For 2 sync RPCs between A and B, we have the following message exchange: 1: A --> DATA(15) --> B // A sends the first request to B 2: A <-- ACK(15) <-- B // B acks the request 3: A <-- DATA(27) <-- B // B sends the response to A 4: A --> ACK(27) --> B // A acks the response 5: A --> DATA(16) --> B // A sends the second request to B 6: A <-- ACK(16) <-- B // B acks the request 7: A <-- DATA(28) <-- B // B sends the response to A 8: A --> ACK(28) --> B // A acks the response If we piggybacked acks, this would look as follows: 1: A --> DATA(15) --> B // A sends the first request to B 2: A <-- DATA-ACK(27,15) <-- B // B sends the response to A and acks A's request 3: A --> DATA(16,27) --> B // A sends the second request to B and acks B's response 4: A <-- DATA(28,16) <-- B // B sends the response to A and acks A's request 5: A --> ACK(28) --> B // A acks the response So instead of 8 exchanges, we have 5. Note, however, that *message bundling* might mitigate this somewhat and not send 8 requests ! This needs to be investigated further. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-1140) UNICAST based on negative acks

by Bela Ban (JIRA)

UNICAST based on negative acks ------------------------------ Key: JGRP-1140 URL: https://jira.jboss.org/jira/browse/JGRP-1140 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.10 Currently, UNICAST is based on positive acks: we send an ack for each message received. This causes a lot of ack traffic (piggybacking remedies this to a certain extent). Investigate a version of UNICAST which uses negative acks; the sender never retransmits a message unless the receiver asks it to. The receiver only asks the sender for retransmission if it sees a missing seqno. Issue: the last-message-lost problem. To solve it, we could exchange the last-seqno when there is no traffic any longer, e.g. by a timer task. The task would only run once, unless there's more traffic. This is what NAKACK does, and we could even reuse the NakReceiverWindow class this ay, and eliminate AckSenderWindow and AckReceiverWindow. We could also remove DefaultRetransmitter and also use the RangeBasedRetransmitter (liek NAKACK). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBNAME-48) Thread leak on server due to WeakReferenced Naming objects in NamingContext

by Oleg Nitz (JIRA)

Thread leak on server due to WeakReferenced Naming objects in NamingContext --------------------------------------------------------------------------- Key: JBNAME-48 URL: https://jira.jboss.org/jira/browse/JBNAME-48 Project: JBoss Naming Issue Type: Bug Reporter: Oleg Nitz Over time the number of threads named "RMI TCP Connection(...)-..." on server grows infinitely. I discovered that this is due garbage collection of Naming objects on client, which are cached in NamingContext.cachedServers map. The correspondent server objects with their threads remain on server waiting for distributed garbage collection, which happens rarely due to "-Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000" in run.conf. I propose not use WeakReferences, instead to remove "expired" Naming objects from NamingContext.cachedServers periodically by some Timer, and also to explicitely remove correspondent remote RMI objects from server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-7807) EJB method having QName as an argument fails on jboss

by Rishi Agarwal (JIRA)

EJB method having QName as an argument fails on jboss ------------------------------------------------------ Key: JBAS-7807 URL: https://jira.jboss.org/jira/browse/JBAS-7807 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-5.1.0.GA Environment: linux Reporter: Rishi Agarwal Assignee: Carlo de Wolf I have a EJB method that has javax.xml.namespace.QName as an argument. On trying to connect to it from the jse client it gives the following exception: Our EJBs are deplyed on JBOSS AS 5. java.lang.RuntimeException: java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classdesc serialVersionUID = -9120448754896609940, local class serialVersionUID = -711357515002332258 After removing QName class from stax-api.jar in the endorsed\lib directory , i could successfully invoke the EJB method. This is the due to the fact the QName class is available as part of JRE libraries as well and i guess this is a well-known fact that there are issue around it due to incompatible serialVersionUID. Now my point is what is the solution to resolve this.We can't recommend removing QName class from stax-api.jar for EJBs( methods with QName as argument) to work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2010