Bug 901214 (JBPAPP6-1661)
| Summary: | Remote clients trapped in infinite loop | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Jitka Kozana <jkudrnac> | ||||
| Component: | Remoting | Assignee: | David M. Lloyd <david.lloyd> | ||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | |||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | urgent | ||||||
| Version: | 6.0.1 | CC: | david.lloyd, jkudrnac, lthon, pgier, rjanik, rsvoboda | ||||
| Target Milestone: | --- | Keywords: | Regression, TestBlocker | ||||
| Target Release: | EAP 6.0.1 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| URL: | http://jira.jboss.org/jira/browse/JBPAPP6-1661 | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-11-30 15:23:45 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Affects Testing: Added: Regression,Blocks Testing Looking at the commits and also bisecting on master (which is currently almost the same as the 3.2 branch) leads me to believe that {{dafe961d658ff9f996b9647ccc896335940399fe}} is the cause. Reverting it made the issue disappear. However, when I tried to do the same on the 3.2 branch (reverting {{c2b9e857bc1a4fcaea40c387d62d72713cafd5ca}}), the issue stays. I'm not sure about possible differences, will look into it more.
Bisecting on the 3.2 branch leads me to {{05ecf6598556c653ef3c0bd1a1d5eec4f42d9a9a}}, which looks totally unrelated. Will continue tomorrow.
I think there is a simple bug, not a regression per se; it's just that certain circumstances seem to exacerbate it. Working on a fix now. Link: Added: This issue Cloned to JBPAPP6-1662 Would it be possible to test this fix: https://github.com/dmlloyd/jboss-remoting/commit/3e065e2 - this should remove the hang. David, thank you for the quick action, please send me the whole jar. Jitka Attached the snapshot build at rev 3e065e28e3671d03654f3b0f405c8162d94d2d79 Attachment: Added: jboss-remoting-3.2.14.GA-SNAPSHOT.jar Thanks! Testing now. I patched my client with your jar and the test did successfully terminate all clients. But the jar you send me is build from master and we are using tag 3.2. Please merge the fix in the 3.2 tag and create me a new jar. Thank you, Jitka I don't know what you mean; this is a snapshot build of what would become 3.2.14.GA. Since it worked though, I will simply tag and release it. Sorry for the confusion. I was somewhat convinced the jar you sent me was built on master branch, even though in the name it says 3.2.14. Anyway, it fixes the problem. [~dmlloyd] Please add fix version and resolve this issue, thank you. Resolving, this should be fixed in EAP 6.0.1 ER4.1. Setting fix version to ER4 as we don't have ER4.1 added here. Point versions are really pain. Verified during EAP 6.0.1.ER4.1 runs, closing. |
project_key: JBPAPP6 At the end of our test case, we could not terminate some of our clients. The termination of our clients is done by setting a "stop" state to the clients. The client runs in an infinite loop and at the beginning of the loop checks its state. But some clients seemed to be trapped in infinite loop in IntIndexHashMap.doPut() and therefore did not pay attention to the changed state. Here is the output of the jstack: {code} "Runner - 1995" daemon prio=10 tid=0x00007ff068e9f800 nid=0x212e runnable [0x00007fef791c4000] java.lang.Thread.State: RUNNABLE at org.jboss.remoting3.remote.IntIndexHashMap.doPut(IntIndexHashMap.java:406) at org.jboss.remoting3.remote.IntIndexHashMap.putIfAbsent(IntIndexHashMap.java:154) at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:305) at org.jboss.ejb.client.remoting.ChannelAssociation.acquireChannelMessageOutputStream(ChannelAssociation.java:249) at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.processInvocation(RemotingConnectionEJBReceiver.java:196) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) at $Proxy0.getSerialAndIncrement(Unknown Source) at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:75) at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52) at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87) at java.lang.Thread.run(Thread.java:662) {code}