October 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JGRP-205) Out-of-band messages

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-205?page=all ] Bela Ban updated JGRP-205: -------------------------- Description: We need to be able to tag individual messages with a quality-of-service bit: ASYNC. This means that, when such a message is received, it can be delivered asynchronously, e.g. by a thread from a separate threadpool (compared this to http://jira.jboss.com/jira/browse/JGRP-181). Examples for OOB messages: - ACKs (unicast) - XMIT requests (NAKACK) - Credit replenishment messages (FC) - Failure detection: heartbeats and are-you-alive messages, plus acks We might even introduce priority based message delivery One example for FC: - We have members A and B - A and B continuously invoke put()s on the TreeCache in *synchronous* mode - When B receives a put() request, it applies it and wants to send the response. However, assume that the response is blocked in FC.down() because we don't have enough credits available to send the response to A - Now A sent a REPLENISH message to B, but B is still stuck in the FC.down() method, which blocks the *up thread* ! - Therefore B cannot handle the replenishment message from A and therefore won't unblock: deadlock ! - If we could deliver the REPLENISH message from A to B *on a separate thread*, B would receive the REPLENISH message and unblock the FC.down() method was: We need to be able to tag individual messages with a quality-of-service bit: ASYNC. This means that, when such a message is received, it can be delivered asynchronously, e.g. by a thread from a separate threadpool (compared this to http://jira.jboss.com/jira/browse/JGRP-181). Examples for OOB messages: - ACKs (unicast) - XMIT requests (NAKACK) - Credit replenishment messages (FC) One example for FC: - We have members A and B - A and B continuously invoke put()s on the TreeCache in *synchronous* mode - When B receives a put() request, it applies it and wants to send the response. However, assume that the response is blocked in FC.down() because we don't have enough credits available to send the response to A - Now A sent a REPLENISH message to B, but B is still stuck in the FC.down() method, which blocks the *up thread* ! - Therefore B cannot handle the replenishment message from A and therefore won't unblock: deadlock ! - If we could deliver the REPLENISH message from A to B *on a separate thread*, B would receive the REPLENISH message and unblock the FC.down() method > Out-of-band messages > -------------------- > > Key: JGRP-205 > URL: http://jira.jboss.com/jira/browse/JGRP-205 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.5 > > > We need to be able to tag individual messages with a quality-of-service bit: ASYNC. This means that, when such a message is received, it can be delivered asynchronously, e.g. by a thread from a separate threadpool (compared this to http://jira.jboss.com/jira/browse/JGRP-181). > Examples for OOB messages: > - ACKs (unicast) > - XMIT requests (NAKACK) > - Credit replenishment messages (FC) > - Failure detection: heartbeats and are-you-alive messages, plus acks > We might even introduce priority based message delivery > One example for FC: > - We have members A and B > - A and B continuously invoke put()s on the TreeCache in *synchronous* mode > - When B receives a put() request, it applies it and wants to send the response. However, assume that the response is blocked in FC.down() because we don't have enough credits available to send the response to A > - Now A sent a REPLENISH message to B, but B is still stuck in the FC.down() method, which blocks the *up thread* ! > - Therefore B cannot handle the replenishment message from A and therefore won't unblock: deadlock ! > - If we could deliver the REPLENISH message from A to B *on a separate thread*, B would receive the REPLENISH message and unblock the FC.down() method -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3787) If you perform JPA actions in JSPs, complains about EHCache not being available

by gregorypierce (JIRA)

If you perform JPA actions in JSPs, complains about EHCache not being available ------------------------------------------------------------------------------- Key: JBAS-3787 URL: http://jira.jboss.com/jira/browse/JBAS-3787 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.4.GA Environment: JBoss AS 4.0.4, OSX, JDK 1.5 Reporter: gregorypierce When running a JSP that made calls to the JPA entitymanager, the system complained about EHCache not being available. Since the second-level cache is on by default, EHCache needs to be in the distribution by default. java.lang.NoClassDefFoundError: net/sf/ehcache/CacheException at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328) at java.lang.Class.getConstructor0(Class.java:2640) at java.lang.Class.newInstance0(Class.java:321) at java.lang.Class.newInstance(Class.java:303) ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3788) Annotation based webservice not deploying with SARDeployer

by gregorypierce (JIRA)

Annotation based webservice not deploying with SARDeployer ---------------------------------------------------------- Key: JBAS-3788 URL: http://jira.jboss.com/jira/browse/JBAS-3788 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.4.GA Environment: Jboss 4.0.4, OSX, JDK 1.5 Reporter: gregorypierce When deploying a service in a SAR that only uses annotations: @Service (objectName="Foo.server:jar=Foo.jar,service=J2ME,name=FooService,type=ManagementInterface") receive an error back from the SAR deployer that jboss-service.xml doesn't exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3783) LdapLoginModule allows access when JUST the username is entered (NO Password entered).

by Mark Burgeson (JIRA)

LdapLoginModule allows access when JUST the username is entered (NO Password entered). -------------------------------------------------------------------------------------- Key: JBAS-3783 URL: http://jira.jboss.com/jira/browse/JBAS-3783 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.3 Final Environment: This issue is was tested and is known to be present in Linux and SUN platforms. Reporter: Mark Burgeson Assigned To: Scott M Stark LdapLoginModule is enabled for LDAP Group authentication. As expected, access is allowed when a valid username/password is supplied and the user belongs to the LDAP group. In addition, access is allowed when JUST the username is entered, without the password, and the user belongs to the LDAP group. This appears to be a bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-620) If HTTPClientInvoker receives an Exception in an InvocationRespose, it should throw it instead of creating a new Exception.

by Ron Sigal (JIRA)

If HTTPClientInvoker receives an Exception in an InvocationRespose, it should throw it instead of creating a new Exception. --------------------------------------------------------------------------------------------------------------------------- Key: JBREM-620 URL: http://jira.jboss.com/jira/browse/JBREM-620 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.0.Beta1 (Bluto) Currently, if HTTPClientInvoker receives an Exception in an InvocationResponse, it will create and throw a new WebServerError(). However, an application might be expecting the actual Exception thrown on the server side. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-617) CallbackPoller should have its own thread.

by Ron Sigal (JIRA)

CallbackPoller should have its own thread. ------------------------------------------ Key: JBREM-617 URL: http://jira.jboss.com/jira/browse/JBREM-617 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta1 (Bluto) Currently, LeasePinger and CallbackPoller share the single thread in org.jboss.remoting.util.TimerUtil. Messaging stress tests have revealed that if CallbackPoller gets a large list of callbacks to deliver, it can take long enough to cause a lease to expire. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-616) Deletion of callback files in getNext() is not synchronized, allowing callbacks to be returned multiple times.

by Ron Sigal (JIRA)

Deletion of callback files in getNext() is not synchronized, allowing callbacks to be returned multiple times. -------------------------------------------------------------------------------------------------------------- Key: JBREM-616 URL: http://jira.jboss.com/jira/browse/JBREM-616 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta1 (Bluto) After a callback file is read, it is deleted, but the deletion is not synchronized. Another call to getNext() could retrieve the file and return its contents a second time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-615) If CallbackStore.add() is called twice quickly, System.currentTimeMillis() might not change, leading to duplicate file names.

by Ron Sigal (JIRA)

If CallbackStore.add() is called twice quickly, System.currentTimeMillis() might not change, leading to duplicate file names. ----------------------------------------------------------------------------------------------------------------------------- Key: JBREM-615 URL: http://jira.jboss.com/jira/browse/JBREM-615 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta1 (Bluto) Callbacks are stored in files whose names are distinguished by a time stamp, but the granularity of System.currentTimeMillis() isn't enough to insure that all filenames are distinct. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 6 months

1
1
0 / 0

[JBoss JIRA] Assigned: (JBMESSAGING-407) XARecovery integration of JBossMessaging with JBossTS

by Juha Lindfors (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=all ] Juha Lindfors reassigned JBMESSAGING-407: ----------------------------------------- Assignee: Juha Lindfors (was: Ovidiu Feodorov) > XARecovery integration of JBossMessaging with JBossTS > ----------------------------------------------------- > > Key: JBMESSAGING-407 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Tests and Performance > Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2 > Reporter: Madhusudhan Konda > Assigned To: Juha Lindfors > Priority: Critical > Fix For: 1.0.2.CR1 > > Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java > > Original Estimate: 1 week > Remaining Estimate: 1 week > > To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JASSIST-20) Proxy serialization

by Emmanuel Bernard (JIRA)

[ http://jira.jboss.com/jira/browse/JASSIST-20?page=comments#action_12345936 ] Emmanuel Bernard commented on JASSIST-20: ----------------------------------------- This should work: the Proxy handler traps "writeReplace" serialize a SerializableProxy object having the knowledge to recreate the initial proxy + keep the infos to populate it SerializableProxy implements readResolve and return the fully initialized initial proxy > Proxy serialization > ------------------- > > Key: JASSIST-20 > URL: http://jira.jboss.com/jira/browse/JASSIST-20 > Project: Javassist > Issue Type: Feature Request > Reporter: Carlo de Wolf > Assigned To: Shigeru Chiba > Attachments: JASSIST-20.zip > > > Proxy serialization doesn't work accross VM's (/ ClassLoaders). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 6 months

1
0
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 October 2006