March 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (SECURITY-474) LogAuditProvider is not correclty logging when there is no underlying exception

by Marcus Moyses (JIRA)

LogAuditProvider is not correclty logging when there is no underlying exception ------------------------------------------------------------------------------- Key: SECURITY-474 URL: https://jira.jboss.org/jira/browse/SECURITY-474 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Bug Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: JBossSecurity_2.0.4.SP3 Reporter: Marcus Moyses Assignee: Marcus Moyses Fix For: JBossSecurity_2.0.4.SP4 Need to fix the logic to write events when there is no underlying exception. -- 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

16 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBEE-37) Release jboss-javaee_6.0_spec 1.0.0.Beta2

by Shelly McGowan (JIRA)

Release jboss-javaee_6.0_spec 1.0.0.Beta2 ----------------------------------------- Key: JBEE-37 URL: https://jira.jboss.org/jira/browse/JBEE-37 Project: JBoss JavaEE APIs Issue Type: Release Affects Versions: 1.0.0.Beta1 Reporter: Shelly McGowan Assignee: Shelly McGowan Update jboss-javaee_6.0_spec to include jboss-servlet-api-3.0_spec 1.0.0.Beta2 -- 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

16 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBEE-36) Release jboss-servlet-api_3.0_spec 1.0.0.Beta2

by Shelly McGowan (JIRA)

Release jboss-servlet-api_3.0_spec 1.0.0.Beta2 ---------------------------------------------- Key: JBEE-36 URL: https://jira.jboss.org/jira/browse/JBEE-36 Project: JBoss JavaEE APIs Issue Type: Release Affects Versions: 1.0.0.Beta1 Reporter: Shelly McGowan Assignee: Shelly McGowan Fix For: 1.0.0.Beta2-servlet-api -- 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

16 years, 4 months

1
1
0 / 0

[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

16 years, 4 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

16 years, 4 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

16 years, 4 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

16 years, 4 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

16 years, 4 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

16 years, 4 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

16 years, 4 months

1
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2010