January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-760) Change port for shutdown tests.

by Ron Sigal (JIRA)

Change port for shutdown tests. ------------------------------- Key: JBREM-760 URL: http://jira.jboss.com/jira/browse/JBREM-760 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.4.0.Beta1 (Pinto) The descendants of org.jboss.test.remoting.shutdown.ShutdownTestParent are failing because the port used by the server is in use. The port number should be changed. -- 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

18 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-786) stale sockets can be gotten from pool even with current rety logic

by james ahlborn (JIRA)

stale sockets can be gotten from pool even with current rety logic ------------------------------------------------------------------ Key: JBREM-786 URL: http://jira.jboss.com/jira/browse/JBREM-786 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 1.4.6.GA Reporter: james ahlborn The retry logic in SocketClientInvoker.transport attempts to ensure that the invoker does not get a stale socket on the last attempt by flushing the pool. however, this only discards any currently unused scokets. a second invoker could return a stale socket after the flush, causing the first invoker to fail again on the last retry (with an EOFException). while this seems like an edge case, we can hit it reliably under load with many connections to the same destination. i've patched this class so that the last call to getConnection will never return a pooled connection. we never got the EOFException after applying this fix. -- 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

18 years, 5 months

2
8
0 / 0

[JBoss JIRA] Created: (JBREM-701) add timeout config per client invocation for transports not descended from socket transport

by Ron Sigal (JIRA)

add timeout config per client invocation for transports not descended from socket transport ------------------------------------------------------------------------------------------- Key: JBREM-701 URL: http://jira.jboss.com/jira/browse/JBREM-701 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 3.0.0.Alpha1 (Otter) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 3.0.0.Alpha1 (Otter) For JBREM-598 per invocation timeouts were implemented for socket, sslsocket, bisocket, and sslbisocket. It's not clear how to implement per invocation timeouts for http and rmi, but it would be good to do, if possible. -- 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

18 years, 5 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-822) Avoid deadlock when Connector shuts down while callback client invoker is in handleConnect()

by Ron Sigal (JIRA)

Avoid deadlock when Connector shuts down while callback client invoker is in handleConnect() -------------------------------------------------------------------------------------------- Key: JBREM-822 URL: http://jira.jboss.com/jira/browse/JBREM-822 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP2, 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Clebert Suconic has experienced a deadlock while shutting down the Application Server. The thread dump shows that the AS has called Connector.stop(), which leads to a call to the synchronized method org.jboss.remoting.MicroRemoteClientInvoker.disconnect() on the callback org.jboss.remoting.transport.bisocket.BisocketClientInvoker. However, all this happens at the same time that a callback handler is being installed, which leads to a call to the synchronized method MicroRemoteClientInvoker.connect() on *the same* callback BisocketClientInvoker. The BisocketClientInvoker is in BisocketClientInvoker.handleConnect(), where it is waiting (with, in the case of JBossMessaging, a timeout of 0) to get a control socket. As a result, MicroRemoteClientInvoker.disconnect() is blocked and cannot execute. This situation needs careful study. Do MicroRemoteClientInvoker.connect() and MicroRemoteClientInvoker.disconnect() need to be fully synchronized? -- 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

18 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-807) Fix failing org.jboss.test.remoting.transport.<transport>.shutdown tests

by Ron Sigal (JIRA)

Fix failing org.jboss.test.remoting.transport.<transport>.shutdown tests ------------------------------------------------------------------------ Key: JBREM-807 URL: http://jira.jboss.com/jira/browse/JBREM-807 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) The org.jboss.test.remoting.transport.<transport>.shutdown tests were created for JBREM-674, to verify that no non-terminating non-daemon threads could prevent Remoting clients and servers from shutting down. Some of these tests have been failing. -- 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

18 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-821) JBoss Remoting fails under load

by Ovidiu Feodorov (JIRA)

JBoss Remoting fails under load ------------------------------- Key: JBREM-821 URL: http://jira.jboss.com/jira/browse/JBREM-821 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP1 Reporter: Ovidiu Feodorov Assigned To: Trustin Lee Priority: Blocker This is a duplicate of JBMESSAGING-1114 present here to remind Remoting people that Messaging has this urgent need. Phrasing belongs to Tim: JBoss Remoting fails with various different errors when under extreme load. To replicate this, set up two clustered server nodes, using a MySQL database. These can both be on the same machine, using ServiceBindingManager. On a second machine run Ovidiu's messkit toolki, first to send some messages: mess -stat send -size 10240 50000 And then to receive them back using 50 concurrent consumers: mess -stat -sessions 50 receive all You will notice that JBoss Remoting fails with errors: I believe this is due to remoting incorrectly thinking a connection has failed and shutting down the connection. Perhaps due to the load, the ping does not get through in time to refresh the lease? I would like a remoting solution that *does not ping* from server to client - for us this is unnecessary. It also seems remoting is continually timing out and recreating connections - this could also be a source of error. How do we configure remoting so it does not do this? -- 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

18 years, 5 months

3
14
0 / 0

[JBoss JIRA] Created: (JBREM-863) CLONE -Infinite loop in BisocketClientInvoker.createSocket

by Ron Sigal (JIRA)

CLONE -Infinite loop in BisocketClientInvoker.createSocket ---------------------------------------------------------- Key: JBREM-863 URL: http://jira.jboss.com/jira/browse/JBREM-863 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.2.GA_CP01, 2.2.2.SP2 Reporter: Carlo de Wolf Assigned To: Ron Sigal Priority: Blocker Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.SP3 The following piece of code constitutes an infinite loop when timeout = 0: while (timeout == 0 || wait > 0) { try { sockets.wait(wait); break; } catch (InterruptedException e) { log.debug("unexpected interrupt"); if (timeout > 0) wait = timeout - (System.currentTimeMillis() - start); } } "Thread-41" prio=1 tid=0x00002aaaac3cd0b0 nid=0x2e87 in Object.wait() [0x0000000048fe3000..0x0000000048fe3d80] at java.lang.Object.wait(Native Method) - waiting on <0x00002b7156e2f410> (a java.util.HashSet) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket(BisocketClientInvoker.java:458) - locked <0x00002b7156e2f410> (a java.util.HashSet) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:815) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:525) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1634) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.remoting.Client.invokeOneway(Client.java:598) at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallback(ServerInvokerCallbackHandler.java:815) at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallbackOneway(ServerInvokerCallbackHandler.java:686) at org.jboss.jms.server.endpoint.ServerSessionEndpoint.performDelivery(ServerSessionEndpoint.java:1490) - locked <0x00002b71569e25e8> (a org.jboss.remoting.transport.bisocket.BisocketClientInvoker) at org.jboss.jms.server.endpoint.ServerSessionEndpoint.handleDelivery(ServerSessionEndpoint.java:1375) - locked <0x00002b71569dfd40> (a org.jboss.jms.server.endpoint.ServerSessionEndpoint) at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:307) - locked <0x00002b71569ed6b0> (a java.lang.Object) at org.jboss.messaging.core.impl.RoundRobinDistributor.handle(RoundRobinDistributor.java:119) at org.jboss.messaging.core.impl.MessagingQueue$DistributorWrapper.handle(MessagingQueue.java:582) at org.jboss.messaging.core.impl.ClusterRoundRobinDistributor.handle(ClusterRoundRobinDistributor.java:79) at org.jboss.messaging.core.impl.ChannelSupport.deliverInternal(ChannelSupport.java:476) at org.jboss.messaging.core.impl.MessagingQueue.deliverInternal(MessagingQueue.java:505) at org.jboss.messaging.core.impl.ChannelSupport.deliver(ChannelSupport.java:226) - locked <0x00002b71565d3d50> (a java.lang.Object) at org.jboss.jms.server.endpoint.ServerSessionEndpoint$2.run(ServerSessionEndpoint.java:1598) at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89) at java.lang.Thread.run(Thread.java:595) -- 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

18 years, 5 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-866) CLONE -Eliminate delay in MicroSocketClientInvoker.getConnection()

by Ron Sigal (JIRA)

CLONE -Eliminate delay in MicroSocketClientInvoker.getConnection() ------------------------------------------------------------------ Key: JBREM-866 URL: http://jira.jboss.com/jira/browse/JBREM-866 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.2.GA_CP01, 2.2.2.SP2 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.SP3 org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection() currently calls Thread.sleep(1000) after each unsuccessful attempt to retrieve a connection from the connection pool. This introduced an unnecessary delay in general, and, in particular, makes the use of a connection pool of size one impractical. -- 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

18 years, 5 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-868) CLONE -Update build.xml to allow jdk 1.5 compiler to target JVM version 1.4

by Ron Sigal (JIRA)

CLONE -Update build.xml to allow jdk 1.5 compiler to target JVM version 1.4 --------------------------------------------------------------------------- Key: JBREM-868 URL: http://jira.jboss.com/jira/browse/JBREM-868 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.2.GA_CP01 Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.SP3 Fernando has suggested updating build.xml so that the *-brew scripts can use the jdk 1.5 compiler to generate code that is compatible with a 1.4 JVM. This way we have a single version of jboss-remoting.jar in the repository which is (1) appropriate in the current versions of the Application Server, which are compiled with jdk 1.5, and (2) usable in a standalone context by clients built with a jdk 1.4 compiler. The changes should be applied to the following branches: - remoting_2_2_0_GA (for community AS) - remoting_2_2_2_GA_CP (for EAP 4.2 and 4.3) - remoting_2_x (for Remoting 2.4.0) -- 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

18 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-870) CLONE -MaxPoolSize value should be used in key to MicroSocketClientInvoker.connectionPools

by Ron Sigal (JIRA)

CLONE -MaxPoolSize value should be used in key to MicroSocketClientInvoker.connectionPools ------------------------------------------------------------------------------------------ Key: JBREM-870 URL: http://jira.jboss.com/jira/browse/JBREM-870 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.2.GA_CP01, 2.2.2.SP2 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.SP3 If two instances of org.jboss.remoting.Client are created, one with clientMaxPoolSize=1 and one with clientMaxPoolSize=30, they will still share the same connection pool because the key to the connection pools, org.jboss.remoting.transport.socket.ServerAddress, does not include the value of clientMaxPoolSize. ServerAddress.equals() and ServerAddress.hashCode() should be modified to include the value of clientMaxPoolSize. -- 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

18 years, 5 months

1
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008