October 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-350) Regular leave fails after merge

by Bela Ban (JIRA)

Regular leave fails after merge ------------------------------- Key: JGRP-350 URL: http://jira.jboss.com/jira/browse/JGRP-350 Project: JGroups Issue Type: Bug Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 To reproduce (this is test 20 in ManualTests.txt): - Nodes A and B connected to a switch - Kill the switch (or pull the plugs on all nodes) - Power up the switch (or reinsert the plugs) - After the merge: - Leave the new coordinator (A) - The leave should immediately install a new view, this is not the case REASON: - The AckCollector's reset() method does *not* clear the suspect set - The AckCollector does therefore *not* wait for the ack from the new member, and because the coord leaves immediately after sending the new VIEW out, the new VIEW might not be received by B -- 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

18 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-767) Variable substitution in ejb-jar.xml

by Stephan Pelikan (JIRA)

Variable substitution in ejb-jar.xml ------------------------------------ Key: EJBTHREE-767 URL: http://jira.jboss.com/jira/browse/EJBTHREE-767 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: EJB 3.0 RC9 - FD Environment: JBoss 4.0.5.GA; Windows jdk1.5.0_06; Reporter: Stephan Pelikan Priority: Minor In EJB2.x deployments "variables" are substituted but in EJB3 not: JVM started with argument -Dx.y.z=abc META-INF/ejb-jar.xml: ... <env-entry> <env-entry-name>xyz</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>${x.y.z}</env-entry-value> .... In a EJB2.x-deployment fetching this env-entry results in "abc" in EJB3-deployments the result is "${x.y.z}". -- 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

18 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-825) PassivationInterceptor emits notification even if the node isn't loaded

by Brian Stansberry (JIRA)

PassivationInterceptor emits notification even if the node isn't loaded ----------------------------------------------------------------------- Key: JBCACHE-825 URL: http://jira.jboss.com/jira/browse/JBCACHE-825 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0.SP1 Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 1.4.1.GA, 2.0.0.GA PassivationInterceptor emits pre- and post-passivation notifications even if the node being evicted doesn't actually exist in memory. It also unnecessarily calls loader.put(). This is causing issues with EJB3 SFSBs -- see EJBTHREE-746. As an aside, it also looks like the post-passivation notification is happening before the actual passivation. -- 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

18 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-610) Prevent org.jboss.remoting.callback.CallbackPoller from delivering callbacks out of order.

by Ron Sigal (JIRA)

Prevent org.jboss.remoting.callback.CallbackPoller from delivering callbacks out of order. ------------------------------------------------------------------------------------------ Key: JBREM-610 URL: http://jira.jboss.com/jira/browse/JBREM-610 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) Each delivery of a list of Callbacks is handled in a new thread, allowing the Callbacks to be delivered out of order. -- 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

18 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-613) ServerInvoker.InvalidStateException should be a static class.

by Ron Sigal (JIRA)

ServerInvoker.InvalidStateException should be a static class. ------------------------------------------------------------- Key: JBREM-613 URL: http://jira.jboss.com/jira/browse/JBREM-613 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) Since the class is not static, it has an enclosing ServerInvoker instance, which is not serializable. -- 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

18 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-619) In SocketServerInvoker.run() and MultiplexServerInvoker().run, guarantee ServerSocketRefresh thread terminates.

by Ron Sigal (JIRA)

In SocketServerInvoker.run() and MultiplexServerInvoker().run, guarantee ServerSocketRefresh thread terminates. --------------------------------------------------------------------------------------------------------------- Key: JBREM-619 URL: http://jira.jboss.com/jira/browse/JBREM-619 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) Currently, in some cases the run loop can catch an Exception and return without terminating the thread. -- 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

18 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-621) http transport should behave more like other transports.

by Ron Sigal (JIRA)

http transport should behave more like other transports. -------------------------------------------------------- Key: JBREM-621 URL: http://jira.jboss.com/jira/browse/JBREM-621 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) The http transport makes special allowances for the possibility that HTTPClientInvoker might be connected to a server other than CoyoteInvoker and CoyoteInvoker might be connected to a client other than HTTPClientInvoker. However, it is possible for CoyoteInvoker to detect that its client is HTTPClientInvoker because HTTPClientInvoker sets a request property with key "User-Agent: and value beginning with the String "JBossRemoting". Some work toward this goal has already been committed in connection with JIRA issue JBREM-601. 1. If the return is null, CoyoteInvoker will return a response code of 200 instead of 204 if its client is HTTPClientInvoker. This is because returning 204 causes the client side response to return an empty input stream, which causes a problem for ObjectInputStream. 2. If its client is HTTPClientInvoker, CoyoteInvoker will wrap its response in an InvocationResponse. Currently, however, CoyoteInvoker does not treat raw invocations properly. In particular, if Client.RAW with value of true appears in the InvocationRequest metadata map, the raw payload is sent to the server, but, if it sees that its client is HTTPClientInvoker, CoyoteInvoker will still wrap its response in an InvocationResponse. The socket transport, on the other hand, will return the raw response in this case. -- 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

18 years, 2 months

1
1
0 / 0

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

by Shigeru Chiba (JIRA)

[ http://jira.jboss.com/jira/browse/JASSIST-20?page=comments#action_12345953 ] Shigeru Chiba commented on JASSIST-20: -------------------------------------- Oh, thank you. I didn't notice it. > 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

18 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3796) Better fix for undeployment causes an exception and redeployment fails(JBAS-2914).

by Scott M Stark (JIRA)

Better fix for undeployment causes an exception and redeployment fails(JBAS-2914). ---------------------------------------------------------------------------------- Key: JBAS-3796 URL: http://jira.jboss.com/jira/browse/JBAS-3796 Project: JBoss Application Server Issue Type: Support Patch Security Level: Public (Everyone can see) Components: Web (Tomcat) service Reporter: Scott M Stark Assigned To: Scott M Stark The JBAS-2914 fix is reported to cause problems with encodings of forwarded pages. It seems the source used for this fix did not match that tomcat version in jboss-3.2.4. The patch was based on tomcat-5.0.28 when it should have been 5.0.26 (http://archive.apache.org/dist/tomcat/tomcat-5/archive/v5.0.26-beta/src/j...). -- 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

18 years, 2 months

1
1
0 / 0

[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

18 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2006