8:32 a.m.
Radoslav Husar created AS7-3811:
-----------------------------------
Summary: Implement a timeout on EJB client invocations
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:03 p.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
Stuart Douglas commented on AS7-3811:
-------------------------------------
Is there any easy way to reproduce these clients getting stuck?
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:07 p.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
Stuart Douglas commented on AS7-3811:
-------------------------------------
It looks like a remote invocation could potentially get stuck if parameter or attachment
unmarshaling fails on the server, although that is probably not what is happening here.
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8 p.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
jaikiran pai commented on AS7-3811:
-----------------------------------
That exception stacktrace might even mean a genuine wait where the client is waiting for a
result from the server. I'm looking at the perf setup currently with regards to a
couple of other JIRAs around this and that might help understand what the problem is.
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:12 p.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
Dimitris Andreadis updated AS7-3811:
------------------------------------
In order to cherrypick this in the EAP ER2 build, we would need a resolution by Feb/27th.
Is this doable?
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Labels: eap6_LA
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:26 p.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
jaikiran pai commented on AS7-3811:
-----------------------------------
I believe this one is a side effect of some other issues reported in different JIRAs. I
personally would like to first fix those real issues and only if there's a real need,
introduce the timeout.
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Labels: eap6_LA
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:06 p.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
Stuart Douglas commented on AS7-3811:
-------------------------------------
I agree with Jaikiran, I don't think a timeout by default would be a good option.
If an end user really does need a timeout for a particular method they have the option of
using async methods anyway.
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Labels: eap6_LA
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:33 p.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
David Lloyd commented on AS7-3811:
----------------------------------
Yeah we do not want timeouts on invocation. Invocations taking a long time is not an
indication of failure.
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Labels: eap6_LA
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:41 a.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
Radoslav Husar commented on AS7-3811:
-------------------------------------
The default behaviour can remain as is, but I strongly disagree with not supporting
timeout on invocations at all.
You cannot have a justification for a 3-days-long invocations. You should use a different
pattern to achieve this (polling, push, etc). [Moreover the default limit on transaction
in the AS is 5 minutes (if i hear correctly) so the chances that the response will be in
any way valid are also limited.]
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Labels: eap6_LA
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:47 p.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
Dimitris Andreadis commented on AS7-3811:
-----------------------------------------
I agree with Rado on this one. You cannot just block a client forever on any synchronous
call and you shouldn't force a switch to asynchronous mode just to get a timeout
facility.
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Labels: eap6_LA
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:18 p.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
Radoslav Husar updated AS7-3811:
--------------------------------
Priority: Major (was: Critical)
Here is a Jira for the actual problem that invocations are getting stuck: AS7-3975.
Lets keep this Jira for tracking whether the timeout should be implemented or not,
needless to say the above Jira needs to be fixed first. If we ensure that client always
gets a response, then we might not need a timeout. (But thats probably a whishful
thinking.)
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Labels: eap6_LA
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:41 a.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
Darran Lofthouse commented on AS7-3811:
---------------------------------------
This issue reads very similar to something I am looking to solve for Remoting JMX for long
running JMX invocations - one thing I am considering there is enhancing the protocol to
allow the client to check with the server that a request is still being processed.
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Labels: eap6_LA
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:45 a.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
Radoslav Husar commented on AS7-3811:
-------------------------------------
@Darran, that does sound like a solution to this problem, however we would also have to
ensure that even a stuck request is indeed not interpreted as being processed.
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Labels: eap6_LA
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:51 a.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
Darran Lofthouse commented on AS7-3811:
---------------------------------------
With the management capabilities that we have I do also wonder if we should provide mgmt
ops to both view and attempt to cancel running requests or at the very least mark a
request as stalled so an error can be sent to the client.
For other servers it is common to have some mechanism to view the requests currently being
handled - could also be a very useful debug tool i.e. I can see a stuck thread now track
back how that threads current request was initiated.
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Labels: eap6_LA
Fix For: 7.1.1.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:39 a.m.
[
https://issues.jboss.org/browse/AS7-3811?page=com.atlassian.jira.plugin.s...
]
Jason Greene updated AS7-3811:
------------------------------
Fix Version/s: 7.1.2.Final
(was: 7.1.1.Final)
Implement a timeout on EJB client invocations
---------------------------------------------
Key: AS7-3811
URL: https://issues.jboss.org/browse/AS7-3811
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Labels: eap6_LA
Fix For: 7.1.2.Final
IMHO a client must support a timeout. Very often when things go wrong the clients get
stuck indefinitely.
Maybe this problem go even deeper, something on the server failed but didnt reply to the
client. This is often encoutered during failover undeploy test (50 of 200 clients got
stuck :-) ).
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait()
[0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
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:68)
at
org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5169
days inactive
5191
days old
14 comments
7 participants
participants (7)
-
Darran Lofthouse (JIRA) -
David Lloyd (JIRA)
-
Dimitris Andreadis (JIRA)
-
jaikiran pai (JIRA)
-
Jason Greene (JIRA)
-
Radoslav Husar (JIRA)
-
Stuart Douglas (JIRA)