May 2008 - jboss-remoting-issues - Jboss List Archives

[JBoss JIRA] Updated: (JBREM-761) NPE in BisocketServerInvoker$ControlConnectionThread

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-761?page=all ] Ron Sigal updated JBREM-761: ---------------------------- Fix Version/s: 2.4.0.Beta1 (Pinto) Added fix version 2.4.0.Beta1 - see JBREM-975 "Make sure all fixes on 2.2 branch are applied to 2.x branch". > NPE in BisocketServerInvoker$ControlConnectionThread > ---------------------------------------------------- > > Key: JBREM-761 > URL: http://jira.jboss.com/jira/browse/JBREM-761 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA > > > From Tim Fox: > Here's one I saw today: > @main 18:11:54,129 INFO [FailoverTest] tearing down > Exception in thread "control: Socket[addr=/127.0.0.1,port=3243,localport=55075]" java.lang.NullPointerException > at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(BisocketServerInvoker.java:669) > It seems pretty harmless, but nevertheless I thought I'd inform you. -- 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

16 years, 7 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-761) NPE in BisocketServerInvoker$ControlConnectionThread

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-761?page=all ] Ron Sigal closed JBREM-761. --------------------------- Resolution: Done > NPE in BisocketServerInvoker$ControlConnectionThread > ---------------------------------------------------- > > Key: JBREM-761 > URL: http://jira.jboss.com/jira/browse/JBREM-761 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA > > > From Tim Fox: > Here's one I saw today: > @main 18:11:54,129 INFO [FailoverTest] tearing down > Exception in thread "control: Socket[addr=/127.0.0.1,port=3243,localport=55075]" java.lang.NullPointerException > at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(BisocketServerInvoker.java:669) > It seems pretty harmless, but nevertheless I thought I'd inform you. -- 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

16 years, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-757) Implement quick Client.removeListener() for polled callbacks.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-757?page=all ] Ron Sigal updated JBREM-757: ---------------------------- Fix Version/s: 2.4.0.Beta1 (Pinto) Added fix version 2.4.0.Beta1 - see JBREM-975 "Make sure all fixes on 2.2 branch are applied to 2.x branch". > Implement quick Client.removeListener() for polled callbacks. > ------------------------------------------------------------- > > Key: JBREM-757 > URL: http://jira.jboss.com/jira/browse/JBREM-757 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto) > > > For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods. The per invocation timeout is set by calling Client.setDisconnectTimeout(). When the disconnect timeout is set to 0, network i/o is avoided entirely. > However, the quick version of Client.removeListener() was implemented only for push callbacks. It should also be implemented for pull callbacks. -- 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

16 years, 7 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBREM-761) NPE in BisocketServerInvoker$ControlConnectionThread

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-761?page=all ] Ron Sigal reopened JBREM-761: ----------------------------- > NPE in BisocketServerInvoker$ControlConnectionThread > ---------------------------------------------------- > > Key: JBREM-761 > URL: http://jira.jboss.com/jira/browse/JBREM-761 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA > > > From Tim Fox: > Here's one I saw today: > @main 18:11:54,129 INFO [FailoverTest] tearing down > Exception in thread "control: Socket[addr=/127.0.0.1,port=3243,localport=55075]" java.lang.NullPointerException > at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(BisocketServerInvoker.java:669) > It seems pretty harmless, but nevertheless I thought I'd inform you. -- 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

16 years, 7 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-757) Implement quick Client.removeListener() for polled callbacks.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-757?page=all ] Ron Sigal closed JBREM-757. --------------------------- Resolution: Done > Implement quick Client.removeListener() for polled callbacks. > ------------------------------------------------------------- > > Key: JBREM-757 > URL: http://jira.jboss.com/jira/browse/JBREM-757 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA > > > For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods. The per invocation timeout is set by calling Client.setDisconnectTimeout(). When the disconnect timeout is set to 0, network i/o is avoided entirely. > However, the quick version of Client.removeListener() was implemented only for push callbacks. It should also be implemented for pull callbacks. -- 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

16 years, 7 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBREM-757) Implement quick Client.removeListener() for polled callbacks.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-757?page=all ] Ron Sigal reopened JBREM-757: ----------------------------- > Implement quick Client.removeListener() for polled callbacks. > ------------------------------------------------------------- > > Key: JBREM-757 > URL: http://jira.jboss.com/jira/browse/JBREM-757 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto) > > > For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods. The per invocation timeout is set by calling Client.setDisconnectTimeout(). When the disconnect timeout is set to 0, network i/o is avoided entirely. > However, the quick version of Client.removeListener() was implemented only for push callbacks. It should also be implemented for pull callbacks. -- 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

16 years, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-751) Eliminate unnecessary "Unable to process control connection:" message from BisocketServerInvoker

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-751?page=all ] Ron Sigal updated JBREM-751: ---------------------------- Fix Version/s: 2.4.0.Beta1 (Pinto) Added fix version 2.4.0.Beta1 - see JBREM-975 "Make sure all fixes on 2.2 branch are applied to 2.x branch". > Eliminate unnecessary "Unable to process control connection:" message from BisocketServerInvoker > ------------------------------------------------------------------------------------------------ > > Key: JBREM-751 > URL: http://jira.jboss.com/jira/browse/JBREM-751 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.2.1.GA, 2.4.0.Beta1 (Pinto) > > > In org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(), there is a try/catch block that catches IOExceptions. If the IOException is caused by a closed socket, then the thread quietly shuts down, instead of logging an error. However, the test "socket closed".equals(e.getMessage()) should have been "Socket closed".equals(e.getMessage()), and so an error is sometimes logged unnecessarily. -- 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

16 years, 7 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-751) Eliminate unnecessary "Unable to process control connection:" message from BisocketServerInvoker

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-751?page=all ] Ron Sigal closed JBREM-751. --------------------------- Resolution: Done > Eliminate unnecessary "Unable to process control connection:" message from BisocketServerInvoker > ------------------------------------------------------------------------------------------------ > > Key: JBREM-751 > URL: http://jira.jboss.com/jira/browse/JBREM-751 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.4.0.Beta1 (Pinto), 2.2.1.GA > > > In org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(), there is a try/catch block that catches IOExceptions. If the IOException is caused by a closed socket, then the thread quietly shuts down, instead of logging an error. However, the test "socket closed".equals(e.getMessage()) should have been "Socket closed".equals(e.getMessage()), and so an error is sometimes logged unnecessarily. -- 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

16 years, 7 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-750) Logger in HTTPClientInvoker should be static.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-750?page=all ] Ron Sigal closed JBREM-750. --------------------------- Resolution: Done > Logger in HTTPClientInvoker should be static. > --------------------------------------------- > > Key: JBREM-750 > URL: http://jira.jboss.com/jira/browse/JBREM-750 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.2.2.GA > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.SP1 > > > When org.jboss.remoting.transport.http.ssl.HTTPSClientInvoker.createSocketFactory() (which is called from the RemoteClientInvoker() constructor) tries to log an error, it throws a NullPointerException because the log variable has not been initialized. > The log variable should be static. -- 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

16 years, 7 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBREM-751) Eliminate unnecessary "Unable to process control connection:" message from BisocketServerInvoker

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-751?page=all ] Ron Sigal reopened JBREM-751: ----------------------------- > Eliminate unnecessary "Unable to process control connection:" message from BisocketServerInvoker > ------------------------------------------------------------------------------------------------ > > Key: JBREM-751 > URL: http://jira.jboss.com/jira/browse/JBREM-751 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.2.1.GA > > > In org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(), there is a try/catch block that catches IOExceptions. If the IOException is caused by a closed socket, then the thread quietly shuts down, instead of logging an error. However, the test "socket closed".equals(e.getMessage()) should have been "Socket closed".equals(e.getMessage()), and so an error is sometimes logged unnecessarily. -- 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

16 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues May 2008