July 2009 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-998) JBoss Serailization 1.0.3 does not work. Make sure a new Serializtion jar gets sent out with this fix with remoting.

by Jay Howell (JIRA)

JBoss Serailization 1.0.3 does not work. Make sure a new Serializtion jar gets sent out with this fix with remoting. --------------------------------------------------------------------------------------------------------------------- Key: JBREM-998 URL: http://jira.jboss.com/jira/browse/JBREM-998 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: serialization Affects Versions: 2.2.2.SP7 Reporter: Jay Howell Priority: Critical Jboss serialization is broken. We need to make sure that we fix http://jira.jboss.org/jira/browse/JBSER-108 and it gets out with future versions of remoting. -- 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, 11 months

2
1
0 / 0

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

15 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1140) Bisocket client cannot detect connection failure

by David Lloyd (JIRA)

Bisocket client cannot detect connection failure ------------------------------------------------ Key: JBREM-1140 URL: https://jira.jboss.org/jira/browse/JBREM-1140 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: transport Reporter: David Lloyd Assignee: David Lloyd Fix For: 2.2.3.SP1 The BisocketClientInvoker never reads from the control socket. Therefore, it might take a long time for it to notice that the control connection dies, causing confusion between the client and server (for example, the client may reuse a listener ID that the server considers extinct). By adding a ping reply mechanism, the client must both send and receive a ping for the connection to be known "good", which should help speed up the dead connection detection process. Since this change is protocol-incompatible, it should be enabled by a configuration option. I'm using Bisocket.ENABLE_PING_REPLY = "enablePingReply" for this purpose. -- 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, 2 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

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

15 years, 2 months

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-1143) CLONE [JBREM-877] - New Socket Connection is being Created for Every Client Request to the Server

by Ron Sigal (JIRA)

CLONE [JBREM-877] - New Socket Connection is being Created for Every Client Request to the Server ------------------------------------------------------------------------------------------------- Key: JBREM-1143 URL: https://jira.jboss.org/jira/browse/JBREM-1143 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.2.SP2 Environment: Linux os , Pentium duo Processor with 3.6 Ghz clock Speed, 4GB Ram in this Postgresql Database also Running Reporter: Kumarselvan Somasundaram Assignee: Ron Sigal Priority: Critical Fix For: 2.4.0.Beta2 (Pinto) whenever EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization, The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0 new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization. -- 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, 2 months

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

15 years, 3 months

1
8
0 / 0

[JBoss JIRA] Created: (JBREM-1141) HTTPUnMarshaller should test for "non-text" content-type instead of "binary" content-type

by Ron Sigal (JIRA)

HTTPUnMarshaller should test for "non-text" content-type instead of "binary" content-type ----------------------------------------------------------------------------------------- Key: JBREM-1141 URL: https://jira.jboss.org/jira/browse/JBREM-1141 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.3, 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder), 2.2.3.SP1 As an efficiency measure, org.jboss.marshal.http.HTTPUnMarshaller.read() incorporates special handling for strings to avoid serialization. However, there is a flaw in the logic. HTTPUnMarshaller.read() calls isBinaryData() and calls super.read() if the return value is true. If the return value is false, then it processes the input as String data. Originally, this distinction worked because the only two types recognized were org.jboss.remoting..transport.web.WebUtil.HTML ("text/html") and WebUtil.BINARY ("application/octet-stream"). However, JBREM-653 "allow user to set content-type for http responses" allows the introduction of other content types. Instead of testing for "application/octet-stream", HTTPUnMarshaller.read() should treat any content type that starts "text" as a String, and it should treat anything else as an object. -- 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

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues July 2009