January 2009 - jboss-remoting-issues

[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

15 years

2
5
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

15 years, 3 months

2
14
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

15 years, 6 months

2
6
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, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1082) Allow ConnectionValidator to access InvokerLocator parameters

by Ron Sigal (JIRA)

Allow ConnectionValidator to access InvokerLocator parameters ------------------------------------------------------------- Key: JBREM-1082 URL: https://jira.jboss.org/jira/browse/JBREM-1082 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) When org.jboss.remoting.Client.addConnectionListener() creates an org.jboss.remoting.ConnectionValidator, it passes in a reference to itself and the ConnectionValidator accesses the Client's configuration map. However, the Client's configuration map doesn't include (without some action on the part of the calling application) the InvokerLocator parameters. It follows that parameters configured on the server side (e.g., in a *-service.xml or *-beans.xml file in the context of the Application Server) don't get passed to the ConnectionValidator. -- 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, 7 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1084) Allow CallbackPoller to access Client and InvokerLocator parameters

by Ron Sigal (JIRA)

Allow CallbackPoller to access Client and InvokerLocator parameters ------------------------------------------------------------------- Key: JBREM-1084 URL: https://jira.jboss.org/jira/browse/JBREM-1084 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.SP2 (Flounder) When org.jboss.remoting.Client.addListener() creates an org.jboss.remoting.callbackCallbackPoller, it passes in a reference to itself and a metadata map. Currently, the CallbackPoller accesses parameters only in the metadata map, which means that the Client's configuration map and InvokerLocator parameters (which might be configured declaratively on the server side) are not used. -- 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, 7 months

1
7
0 / 0

[JBoss JIRA] Created: (JBREM-1083) Each Client creates a new invokerDestructionTimer

by Ron Sigal (JIRA)

Each Client creates a new invokerDestructionTimer ------------------------------------------------- Key: JBREM-1083 URL: https://jira.jboss.org/jira/browse/JBREM-1083 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) When the parameter "invokerDestructionDelay" is greater than 0, org.jboss.remoting.Client.disconnect() creates a new TImer. There should be one static Timer. -- 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, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1076) SocketServerInvoker.processInvocation() should return if running == false

by Ron Sigal (JIRA)

SocketServerInvoker.processInvocation() should return if running == false ------------------------------------------------------------------------- Key: JBREM-1076 URL: https://jira.jboss.org/jira/browse/JBREM-1076 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.0.SP3 (Flounder) The while(worker == null && running) loop can end with worker == null, in which case processRequest() should return instead of proceeding. -- 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, 7 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1081) Fix NPE in ServerInvokerCallbackHandler

by Ron Sigal (JIRA)

Fix NPE in ServerInvokerCallbackHandler ---------------------------------------- Key: JBREM-1081 URL: https://jira.jboss.org/jira/browse/JBREM-1081 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 Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) When org.jboss.remoting.callback.ServerInvokerCallback is shut down by a call to ServerInvokerCallbackHandler.destroy(), the variables callBackClient and callbackStore are set to null. If ServerInvokerCallbackHandler.handleCallback() is called subsequently (which can happen if destroy() is called by ServerInvokerCallbackHandler.handleConnectionException() and the application has not yet been informed about a connection failure), then, since callbackClient == null, it looks like pull callbacks are configured, but, since callbackStore == null, a NullPointerException is thrown in ServerInvokerCallbackHandler.persistCallback(). -- 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, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1085) Reduce log level of ServerSocketWrapper.close() log messages

by Ron Sigal (JIRA)

Reduce log level of ServerSocketWrapper.close() log messages ------------------------------------------------------------ Key: JBREM-1085 URL: https://jira.jboss.org/jira/browse/JBREM-1085 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) The log messages "wrote CLOSING" and "unable to writing CLOSING byte" in org.jboss.remoting.transport.socket.ServerSocketWrapper.close() are too noisy and should be reduced to TRACE level. -- 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, 8 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues January 2009