February 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

15 years

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

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

15 years, 6 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

15 years, 6 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

15 years, 7 months

2
4
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-1088) MicroSocketClientInvoker(InvokerLocator locator, Map configuration) ctor - not propagating exceptions (only message is wrapped)

by Developer JBoss (JIRA)

MicroSocketClientInvoker(InvokerLocator locator, Map configuration) ctor - not propagating exceptions (only message is wrapped) ------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-1088 URL: https://jira.jboss.org/jira/browse/JBREM-1088 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.4.0.SP1 (Pinto) Environment: Windows Reporter: Developer JBoss Priority: Minor During org.jboss.remoting.Client.connect() call, if server "hostname" DNS mapping is not available at client, org.jboss.remoting.transport.socket.MicroSocketClientInvoker.setup() getAddressByName throws : java.net.UnknownHostException: <hostname> However, calling method: org.jboss.remoting.transport.socket.MicroSocketClientInvoker(InvokerLocator locator, Map configuration) catches this exception and wraps it as new RuntimeException(ex.getMessage()). This looses rootcause exception stack. It is difficult for caller client code to understand the cause of the exception (UnknownHostException). -- 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

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues February 2009