[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, 4 months
[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, 4 months
[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, 4 months
[JBoss JIRA] Created: (JBCACHE-1165) Endless loop in PessimisticLockInterceptor
by Jacek Halat (JIRA)
Endless loop in PessimisticLockInterceptor
------------------------------------------
Key: JBCACHE-1165
URL: http://jira.jboss.com/jira/browse/JBCACHE-1165
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.1.SP4
Environment: Windows XP, Sun jdk150_06
Solaris 10
Reporter: Jacek Halat
Assigned To: Manik Surtani
When 2 Threads are simulatanous putting/removing values from this same node TreeCache hang's up and goes into endless loop.
Main loop looks like:
for (int x = 0; x < 1000; x++) {
tm.begin();
System.out.println("R" + Thread.currentThread().getName());
//inside transaction
cache.remove("/a");
System.out.println("AR" + Thread.currentThread().getName());
tm.commit();
//outside transaction
System.out.println("P" + Thread.currentThread().getName());
cache.put("/a/b/c/d", "text"+x,"b");
System.out.println("AP" + Thread.currentThread().getName());
}
--
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, 4 months