March 2008 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-953) CLONE [JBREM-945] - Allow ServerThread to keep running after SocketTImeoutException

by Ron Sigal (JIRA)

CLONE [JBREM-945] - Allow ServerThread to keep running after SocketTImeoutException ----------------------------------------------------------------------------------- Key: JBREM-953 URL: http://jira.jboss.com/jira/browse/JBREM-953 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP4 Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.2.SP7 Currently, org.jboss.remoting.transport.socket.ServerThread will close its socket and return itself to the threadpool in the event of a SocketTimeoutException. However, it could simply continue trying to read the next invocation. The javadoc for java.net.Socket.setSoTimeout() states: Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the Socket is still valid. If the timeout is due to transitory circumstances, then it would be much more efficient to allow the ServerThread to continue, rather than forcing the client to start over with a new socket. -- 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

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-951) CLONE [JBREM-942] - A deadlock encountered on ConnectionValidator

by Ron Sigal (JIRA)

CLONE [JBREM-942] - A deadlock encountered on ConnectionValidator ------------------------------------------------------------------ Key: JBREM-951 URL: http://jira.jboss.com/jira/browse/JBREM-951 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.2.SP5 Environment: JBoss-EAP-4.2, JBossMessaging-1.4.0-SP3, JBossRemoting-2.2.2-SP5 Reporter: Tyronne Wickramarathne Assigned To: Ron Sigal Priority: Critical Fix For: 2.2.2.SP7 This deadlock occurred on JBREM when a JBossMessaging Bridge was set and consuming messages. here's the StackTrace : Found one Java-level deadlock: ============================= "Thread-278": waiting to lock monitor 0x08128544 (object 0xce8b25e0, a java.lang.Object), which is held by "Timer-4" "Timer-4": waiting to lock monitor 0x08129160 (object 0xce89f508, a java.util.ArrayList), which is held by "Thread-278" Java stack information for the threads listed above: =================================================== "Thread-278": at org.jboss.remoting.ConnectionValidator.doStop(ConnectionValidator.java:526) - waiting to lock <0xce8b25e0> (a java.lang.Object) at org.jboss.remoting.ConnectionValidator.stop(ConnectionValidator.java:252) at org.jboss.remoting.ConnectionValidator.removeConnectionListener(ConnectionValidator.java:344) - locked <0xce89f508> (a java.util.ArrayList) at org.jboss.remoting.Client.removeConnectionListener(Client.java:398) at org.jboss.jms.client.remoting.JMSRemotingConnection.removeConnectionListener(JMSRemotingConnection.java:493) - locked <0xce8b18c8> (a org.jboss.jms.client.remoting.JMSRemotingConnection) at org.jboss.jms.client.container.ConnectionAspect.handleClose(ConnectionAspect.java:184) at sun.reflect.GeneratedMethodAccessor134.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121) at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java) at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java) at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java) at org.jboss.jms.client.delegate.ClientConnectionDelegate.close(ClientConnectionDelegate.java) at org.jboss.jms.client.JBossConnection.close(JBossConnection.java:132) at org.jboss.jms.server.bridge.Bridge.cleanup(Bridge.java:1098) at org.jboss.jms.server.bridge.Bridge.access$1100(Bridge.java:66) at org.jboss.jms.server.bridge.Bridge$FailureHandler.run(Bridge.java:1496) at java.lang.Thread.run(Thread.java:619) "Timer-4": at org.jboss.remoting.ConnectionValidator.notifyListeners(ConnectionValidator.java:553) - waiting to lock <0xce89f508> (a java.util.ArrayList) at org.jboss.remoting.ConnectionValidator.run(ConnectionValidator.java:286) - locked <0xce8b25e0> (a java.lang.Object) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) Found 1 deadlock. -- 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

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-952) CLONE [JBREM-944] - Fix race in ConnectionNotifier

by Ron Sigal (JIRA)

CLONE [JBREM-944] - Fix race in ConnectionNotifier -------------------------------------------------- Key: JBREM-952 URL: http://jira.jboss.com/jira/browse/JBREM-952 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP4 Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.2.SP7 org.jboss.remoting.ConnectionNotifier.connectionTerminated() throws NullPointerExceptions from the following code: ConnectionListener[] list = (ConnectionListener[])listeners.toArray(new ConnectionListener[listeners.size()]); for(int x = 0; x < list.length; x++) { list[x].handleConnectionException(ex, client); // <<== NPE's thrown here } It seems that listeners got smaller between the call to listeners.size() and the call to listeners.toArray(), which could result in list having one or more null elements. -- 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

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-938) CLONE [JBREM-937] - Callback BisocketServerInvoker should reuse available ServerThreads

by Ron Sigal (JIRA)

CLONE [JBREM-937] - Callback BisocketServerInvoker should reuse available ServerThreads --------------------------------------------------------------------------------------- Key: JBREM-938 URL: http://jira.jboss.com/jira/browse/JBREM-938 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP5 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP6 When org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlConnectionThread.run() creates a new socket, it always creates a new org.jboss.remoting.transport.socket.ServerThread. Instead, it should look in org.jboss.remoting.transport.socket.SocketServerInvoker.threadpool for existing ServerThreads waiting to be reused. -- 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

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-936) CLONE [JBREM-915] - NullPointerException in InvokerLocator

by Ron Sigal (JIRA)

CLONE [JBREM-915] - NullPointerException in InvokerLocator ----------------------------------------------------------- Key: JBREM-936 URL: http://jira.jboss.com/jira/browse/JBREM-936 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: jmx remoting Affects Versions: 2.2.2.SP4 Environment: JBEAP 4.3 (JBoss Remoting 2.2.2 SP4) Windows 2000 Reporter: Matthew Brasier Priority: Minor A NullPointerException is thrown by InvokerLocator.resolveHost if a null host is passed in. (Line 333 of InvokerLocator.java for the 2.2.2SP4 tag) This was observed when running JBEAP 4.3 on a laptop that has a VPN client installed. JBoss was configured to bind to all interfaces (-b0.0.0.0) and iIt appears that this configuration results in a null host being passed to resolveHost. resolveHost then does a host.indexOf("0.0.0.0") which throws the NPE. On the laptop in question, this can be worked around by explicitly binding the the required IP address, rather than binding to all, but the code should handle the case where a null host is passed in more gracefully. -- 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

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-943) Release 2.2.0.SP7

by Ron Sigal (JIRA)

Release 2.2.0.SP7 ----------------- Key: JBREM-943 URL: http://jira.jboss.com/jira/browse/JBREM-943 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal -- 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

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-937) Callback BisocketServerInvoker should reuse available ServerThreads

by Ron Sigal (JIRA)

Callback BisocketServerInvoker should reuse available ServerThreads ------------------------------------------------------------------- Key: JBREM-937 URL: http://jira.jboss.com/jira/browse/JBREM-937 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP5 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP6 When org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlConnectionThread.run() creates a new socket, it always creates a new org.jboss.remoting.transport.socket.ServerThread. Instead, it should look in org.jboss.remoting.transport.socket.SocketServerInvoker.threadpool for existing ServerThreads waiting to be reused. -- 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

1
5
0 / 0

[JBoss JIRA] Closed: (JBREM-915) NullPointerException in InvokerLocator

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-915?page=all ] Ron Sigal closed JBREM-915. --------------------------- Resolution: Done > NullPointerException in InvokerLocator > -------------------------------------- > > Key: JBREM-915 > URL: http://jira.jboss.com/jira/browse/JBREM-915 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jmx remoting > Affects Versions: 2.2.2.SP4 > Environment: JBEAP 4.3 (JBoss Remoting 2.2.2 SP4) > Windows 2000 > Reporter: Matthew Brasier > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.2.2.SP7 > > > A NullPointerException is thrown by InvokerLocator.resolveHost if a null host is passed in. (Line 333 of InvokerLocator.java for the 2.2.2SP4 tag) > This was observed when running JBEAP 4.3 on a laptop that has a VPN client installed. JBoss was configured to bind to all interfaces (-b0.0.0.0) and iIt appears that this configuration results in a null host being passed to resolveHost. resolveHost then does a host.indexOf("0.0.0.0") which throws the NPE. > On the laptop in question, this can be worked around by explicitly binding the the required IP address, rather than binding to all, but the code should handle the case where a null host is passed in more gracefully. -- 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

1
0
0 / 0

[JBoss JIRA] Reopened: (JBREM-915) NullPointerException in InvokerLocator

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-915?page=all ] Ron Sigal reopened JBREM-915: ----------------------------- > NullPointerException in InvokerLocator > -------------------------------------- > > Key: JBREM-915 > URL: http://jira.jboss.com/jira/browse/JBREM-915 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jmx remoting > Affects Versions: 2.2.2.SP4 > Environment: JBEAP 4.3 (JBoss Remoting 2.2.2 SP4) > Windows 2000 > Reporter: Matthew Brasier > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.2.2.SP7 > > > A NullPointerException is thrown by InvokerLocator.resolveHost if a null host is passed in. (Line 333 of InvokerLocator.java for the 2.2.2SP4 tag) > This was observed when running JBEAP 4.3 on a laptop that has a VPN client installed. JBoss was configured to bind to all interfaces (-b0.0.0.0) and iIt appears that this configuration results in a null host being passed to resolveHost. resolveHost then does a host.indexOf("0.0.0.0") which throws the NPE. > On the laptop in question, this can be worked around by explicitly binding the the required IP address, rather than binding to all, but the code should handle the case where a null host is passed in more gracefully. -- 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

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-915) NullPointerException in InvokerLocator

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-915?page=all ] Ron Sigal updated JBREM-915: ---------------------------- Fix Version/s: 2.2.2.SP7 > NullPointerException in InvokerLocator > -------------------------------------- > > Key: JBREM-915 > URL: http://jira.jboss.com/jira/browse/JBREM-915 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jmx remoting > Affects Versions: 2.2.2.SP4 > Environment: JBEAP 4.3 (JBoss Remoting 2.2.2 SP4) > Windows 2000 > Reporter: Matthew Brasier > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.2.2.SP7 > > > A NullPointerException is thrown by InvokerLocator.resolveHost if a null host is passed in. (Line 333 of InvokerLocator.java for the 2.2.2SP4 tag) > This was observed when running JBEAP 4.3 on a laptop that has a VPN client installed. JBoss was configured to bind to all interfaces (-b0.0.0.0) and iIt appears that this configuration results in a null host being passed to resolveHost. resolveHost then does a host.indexOf("0.0.0.0") which throws the NPE. > On the laptop in question, this can be worked around by explicitly binding the the required IP address, rather than binding to all, but the code should handle the case where a null host is passed in more gracefully. -- 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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues March 2008