October 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-349) FD_SOCK: incorrect suspicion

by Bela Ban (JIRA)

FD_SOCK: incorrect suspicion ---------------------------- Key: JGRP-349 URL: http://jira.jboss.com/jira/browse/JGRP-349 Project: JGroups Issue Type: Bug Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 Config: udp.xml - Start A - Start B - Start C - Leave A: B shows the error message below (it is suspected by C !): 0 [WARN] [IncomingPacketHandler (channel=DrawGroupDemo)] FD_SOCK.up(): I was suspected by 192.168.5.2:1466; ignoring the SUSPECT message -- 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: (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

19 years, 6 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

19 years, 6 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

19 years, 6 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

19 years, 6 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

19 years, 6 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

19 years, 6 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

19 years, 6 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

19 years, 6 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

19 years, 6 months

1
1
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