August 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-1146) Treat IOException("Connection reset by peer") as a retriable exception

by Ron Sigal (JIRA)

Treat IOException("Connection reset by peer") as a retriable exception ---------------------------------------------------------------------- Key: JBREM-1146 URL: https://jira.jboss.org/jira/browse/JBREM-1146 Project: JBoss Remoting Issue Type: Feature Request 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 org.jboss.remoting.transport.socket.MicroSocketClientInvoker uses the parameter "numberOfCallRetries" to determine the number of invocation attempts to make upon receiving java.net.SocketExceptions. For example, SocketException("Connection reset") will cause MicroSocketClientInvoker to get another socket and try again. However, if a connection is reset on the other side, then an IOException("Connection reset by peer") is thrown, which doesn't lead to a retry. It should be possible to configure the socket transport to treat an IOException("Connection reset by peer") as retriable. -- 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
4
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-1147) BisocketClientInvoker.createSocket() in callback mode should check for replaced control socket

by Ron Sigal (JIRA)

BisocketClientInvoker.createSocket() in callback mode should check for replaced control socket ---------------------------------------------------------------------------------------------- Key: JBREM-1147 URL: https://jira.jboss.org/jira/browse/JBREM-1147 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 When running as a callback client invoker, org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() creates a socket by writing a request on the control socket and waiting for the client side to connect to the secondary ServerSocket. If the control socket fails and is replaced, however, it may not be possible to write the request, or the written request might get lost. Therefore, createSocket() should periodically check if the control socket has been replaced, and, if it has been, the request to create a socket should be rewritten. -- 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
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues August 2009