June 2009 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-947) ConnectionValidator hangs when server dies

by Tim Fox (JIRA)

ConnectionValidator hangs when server dies ------------------------------------------ Key: JBREM-947 URL: http://jira.jboss.com/jira/browse/JBREM-947 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Tim Fox Fix For: 2.2.2.SP7 If the connection between client and server is pulled (pull the real cable) or the entire server suddenly dies, then the connection won't be closed from the server (unlike a kill -9 of the server where the OS will terminate that processses connections), so the client making the write() or read() on the socket won't receive an exception. In the eyes of TCP the connection is still alive and the read/write will block until the socket timeout is reached. Typically the socket timeout will be much higher than the desired failure detection time (the validation interval), but currently failure will never be detected in this situation before the socket timeout time. Remoting should not be dependent on the socket timeout for failure detection, the connetion validation and socket timeout should be possible to be configured separately. E.g. you might want to configure a socket timeout of 60 seconds, but a connection validation frequency (ping) of 5 seconds. Currently this is not possible. The current implementation gives inconsistent behaviour depending on how the server died - i.e. whether the process died (e.g. kill -9) or the cable was pulled or the entire server disappeared. -- 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

14 years, 5 months

3
9
0 / 0

[JBoss JIRA] Created: (JBREM-949) CLONE [JBREM-947] - ConnectionValidator hangs when server dies

by Ron Sigal (JIRA)

CLONE [JBREM-947] - ConnectionValidator hangs when server dies -------------------------------------------------------------- Key: JBREM-949 URL: http://jira.jboss.com/jira/browse/JBREM-949 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP7 Reporter: Tim Fox Assigned To: Ron Sigal Fix For: 2.4.0.GA If the connection between client and server is pulled (pull the real cable) or the entire server suddenly dies, then the connection won't be closed from the server (unlike a kill -9 of the server where the OS will terminate that processses connections), so the client making the write() or read() on the socket won't receive an exception. In the eyes of TCP the connection is still alive and the read/write will block until the socket timeout is reached. Typically the socket timeout will be much higher than the desired failure detection time (the validation interval), but currently failure will never be detected in this situation before the socket timeout time. Remoting should not be dependent on the socket timeout for failure detection, the connetion validation and socket timeout should be possible to be configured separately. E.g. you might want to configure a socket timeout of 60 seconds, but a connection validation frequency (ping) of 5 seconds. Currently this is not possible. The current implementation gives inconsistent behaviour depending on how the server died - i.e. whether the process died (e.g. kill -9) or the cable was pulled or the entire server disappeared. -- 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

14 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1135) Release 2.5.2

by Ron Sigal (JIRA)

Release 2.5.2 ------------- Key: JBREM-1135 URL: https://jira.jboss.org/jira/browse/JBREM-1135 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1107) SocketServerInvoker.IdleTimeoutTask interrupts ServerThreads during long invocation

by Ron Sigal (JIRA)

SocketServerInvoker.IdleTimeoutTask interrupts ServerThreads during long invocation ----------------------------------------------------------------------------------- Key: JBREM-1107 URL: https://jira.jboss.org/jira/browse/JBREM-1107 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) org.jboss.remoting.transport.socket.SocketServerInvoker.IdleTimerTask is intended to shut down org.jboss.remoting.transport.socket.ServerThreads that haven't been in use for some configured amount of time. For each ServerThread, it compares the value of System.currentTimeMillis() to the time at which the ServerThread last started or finished processing an invocation, and, if the difference exceeds the value of the "idleTimeout" parameter, it shuts down the ServerThread. The problem is that if processing an invocation takes longer than the value of "idleTimeout", a ServerThread could be shut down DURING the processing of an invocation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1105) DefaultLoadBalancer doesn't use all available server (if there are x servers available it uses x-1 of these)

by Mikael Thorman (JIRA)

DefaultLoadBalancer doesn't use all available server (if there are x servers available it uses x-1 of these) ------------------------------------------------------------------------------------------------------------ Key: JBREM-1105 URL: https://jira.jboss.org/jira/browse/JBREM-1105 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.2.SP10 Environment: JBoss EAP 4.3.0, Windows XP, Java 1.6.0_11 Reporter: Mikael Thorman Invalid use of the Random nextInt function in class: org.jboss.remoting.transporter.DefaultLoadBalancer function: selectServer Current code: index = new Random().nextInt(size - 1); Should be: index = new Random().nextInt(size); tested current code with 2 servers and it always chooses the first one until this is shut, first after this it uses the second one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-1120) Add a socket write timeout facility

by Ron Sigal (JIRA)

Add a socket write timeout facility ----------------------------------- Key: JBREM-1120 URL: https://jira.jboss.org/jira/browse/JBREM-1120 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP11, 2.5.1 (Flounder) Reporter: Ron Sigal Fix For: 2.2.2.SP12, 2.5.2 (Flounder) The timeout parameter of Java sockets applies only to reading. But a write to a bad connection will hang until the underlying TCP implementation detects the problem. A timer that monitors blocked write operations would be useful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

1
8
0 / 0

[JBoss JIRA] Created: (JBREM-1077) Fix problem in CompressingMarshaller

by Ron Sigal (JIRA)

Fix problem in CompressingMarshaller ------------------------------------ Key: JBREM-1077 URL: https://jira.jboss.org/jira/browse/JBREM-1077 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 3.0.0.GA In org.jboss.remoting.marshal.compress.CompressingMarshaller.write(), gzos.finish(); oos.flush(); should be oos.flush(); bos.flush(); gzos.flush(); gzos.finish(); as it is on the 2.x branch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
14
0 / 0

[JBoss JIRA] Created: (JBREM-1121) Client SocketFactory should be configurable by InvokerLocator

by Ron Sigal (JIRA)

Client SocketFactory should be configurable by InvokerLocator ------------------------------------------------------------- Key: JBREM-1121 URL: https://jira.jboss.org/jira/browse/JBREM-1121 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP11, 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12, 2.5.2 (Flounder) org.jboss.remoting.RemoteClientInvoker, which creates the client invoker's SocketFactory, uses only the parameters passed in the configuration map (except for looking in the InvokerLocator for org.jboss.remoting.SOCKET_FACTORY_CLASS_NAME (actual value "socketFactoryClassName"), which was introduced in JBREM-1014 "Support injection of socket factory class name into AbstractInvoker"). There should be a configurable option to use all parameters from the InvokerLocator. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues June 2009