March 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-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, 7 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, 7 months

2
6
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-1102) Make configuration map available to MarshalFactory

by Ron Sigal (JIRA)

Make configuration map available to MarshalFactory -------------------------------------------------- Key: JBREM-1102 URL: https://jira.jboss.org/jira/browse/JBREM-1102 Project: JBoss Remoting Issue Type: Feature Request 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) The methods public static Marshaller getMarshaller(InvokerLocator locator, ClassLoader classLoader) and public static UnMarshaller getUnMarshaller(InvokerLocator locator, ClassLoader classLoader) in org.jboss.remoting.marshal.MarshalFactory get a marshaller or unmarshaller, respectively, from either a "datatype" parameter or from fully qualified names of the marshaller and unmarshaller classes. However, they don't have access to parameters configured by way of the configuration map. This is a problem for JBossESB, in particular, org.jboss.soa.esb.listeners.gateway.JBossRemotingGatewayListener, which creates an org.jboss.remoting.transport.Connector from parameters configured in a jboss-esb.xml file. -- 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, 11 months

1
11
0 / 0

[JBoss JIRA] Created: (JBREM-1079) Port fixes to ServletServerInvoker from branch 2.x to branch 2.2

by Ron Sigal (JIRA)

Port fixes to ServletServerInvoker from branch 2.x to branch 2.2 ---------------------------------------------------------------- Key: JBREM-1079 URL: https://jira.jboss.org/jira/browse/JBREM-1079 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP11 Reporter: Ron Sigal Fix For: 3.0.0.GA The servlet transport is getting increased use, as demonstrated by JIRA issue JBPAPP-1274 "Fix JBoss Messaging and JBoss Remoting so that servlet transport can be used" and the current attention to JBMESSAGING-1131 "Add configuration for Remoting servlet transport". Some of the changes made for * JBREM-675 "Problems with Servlet invoker" * JBREM-838 "allow user to set content-type for http responses (part 2: ServletServerInvoker)" * JBREM-853 "ServletServerInvoker should not put null URL path in metadata map" should be ported to the 2.2 branch for the version of Remoting used in EAP 4.2/4.3. -- 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, 11 months

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-1100) Link ServerInvokerServlet instances to Connectors via MBean names rather than locator URLs

by Galder Zamarreno (JIRA)

Link ServerInvokerServlet instances to Connectors via MBean names rather than locator URLs ------------------------------------------------------------------------------------------ Key: JBREM-1100 URL: https://jira.jboss.org/jira/browse/JBREM-1100 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP10 Reporter: Galder Zamarreno Fix For: 2.2.2.SP12 Following instructions in http://www.jboss.org/community/docs/DOC-9632, you get the following warning messages when AS/EAP starts up: 11:41:29,289 WARN [Connector] jboss.remoting:service=invoker,transport=servlet is already registered with MBeanServer 11:41:29,290 WARN [Connector] jboss.remoting:service=invoker,transport=servlet is already registered with MBeanServer 11:41:29,291 WARN [Connector] jboss.remoting:service=invoker,transport=servlet is already registered with MBeanServer 11:41:29,292 WARN [Connector] jboss.remoting:service=invoker,transport=servlet is already registered with MBeanServer 11:41:29,293 WARN [Connector] jboss.remoting:service=invoker,transport=servlet is already registered with MBeanServer They come from the other servlet invokers trying to register the default invoker name in the MBeanServer. A better solution, and a way to avoid these WARN messages, would be for invokerName to work properly and point to the corresponding connectors rather than using locatorUrl which are prone to error. This was not possible when I started working on the unified http invokers. Ron/David, I think we might have discussed using MBean names rather than locator URLs in the past but can't find the email. -- 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, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-1106) CLONE [JBREM-851] - In LeasePinger and TimerUtil replace Timer if it has shut down

by Ron Sigal (JIRA)

CLONE [JBREM-851] - In LeasePinger and TimerUtil replace Timer if it has shut down ---------------------------------------------------------------------------------- Key: JBREM-1106 URL: https://jira.jboss.org/jira/browse/JBREM-1106 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.GA_CP01, 2.2.2.SP2, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) When all of the TimerTasks running in a java.util.TimerTask have shut down, the TImer will also shut down, at which point it will accept no more TimerTasks. There are places in Remoting where there should be a test which will create a new Timer the attempt to schedule a TimerTask results in an exception. Two places the problem exists: 1. org.jboss.remoting.LeasePinger, and 2. org.jboss.remoting.util.TimerUtil. A similar problem is described in JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" Reported by James on Remoting forum. -- 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

15 years

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1078) Remove reference to "numberOfRetries" parameter from Remoting Guide

by Ron Sigal (JIRA)

Remove reference to "numberOfRetries" parameter from Remoting Guide ------------------------------------------------------------------- Key: JBREM-1078 URL: https://jira.jboss.org/jira/browse/JBREM-1078 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12 The "numberOfRetries" parameter is no longer used by the socket transport. -- 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

15 years

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues March 2009