[JBoss JIRA] (WFLY-3852) EJB @Schedule interleaves timer calls with @AccessTimeout(0)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3852?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3852:
--------------------------------------
I'm saying that the current behaviour is silly. If you want no concurrent access + immediate timeout the spec should require WRITE+AccessTimeout(0), it should not (IMHO) change the behaviour of a read lock if the timeout is set to zero (the whole point of a READ lock is that it does allow concurrent access from multiple threads as long as the WRITE lock is not held).
I am going to find out if this was actually the intention of the expert group, or if the current version of the spec is just badly worded.
> EJB @Schedule interleaves timer calls with @AccessTimeout(0)
> ------------------------------------------------------------
>
> Key: WFLY-3852
> URL: https://issues.jboss.org/browse/WFLY-3852
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 8.1.0.Final
> Environment: Win 7 x64 / i7
> Reporter: Tibor Digana
> Assignee: David Lloyd
> Priority: Critical
>
> Note: The value in @AccessTimeout(value = 0) is not a real timeout. It's a marker skipping scheduler on concurrent Thread.
> Actual:
> The scheduled method is annotated with @AccessTimeout(0) and @Lock(READ). Very long calls interleave concurrently.
> Expected:
> The calls should not interleave if and only if @AccessTimeout(0) is used. Does not matter which LockType is used.
> According to the Javadoc
> "A value of 0 means concurrent access is not permitted."
> In other words the timer should give it up on concurrent Thread.
> The timer should not wait for read/write lock due to the value in the annotation is not -1.
> In the internal implementation of TomEE server the timer skips scheduling if Lock.tryLock() returns false in this usecase. This can be Read or Write lock - does not matter.
> Don't be confused with WFLY-3430.
> I think the fix in WFLY-3430 should only go with the annotation @AccessTimeout(0) with whatever LockType. If this annotation is not used then the next call should be concurrent / blocked depending on READ / WRITE LockType, respectively.
> My code:
> @Startup
> @Singleton
> @Lock(READ)
> public class MyTimer {
> @Schedule(minute = "*", hour = "*", persistent = false, info = "My Timer")
> @AccessTimeout(0)
> public void updateByMinutes() {}
> }
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3722) IOException: Broken pipe thrown when using RichFaces with Atmosphere 2.2.0
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3722?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3722.
----------------------------------
Fix Version/s: 9.0.0.Alpha1
Resolution: Done
> IOException: Broken pipe thrown when using RichFaces with Atmosphere 2.2.0
> --------------------------------------------------------------------------
>
> Key: WFLY-3722
> URL: https://issues.jboss.org/browse/WFLY-3722
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Brian Leathem
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> While working on RF-13753 I upgraded the RichFaces Atmosphere dependency from 1.0.x to 2.2.0. All is functional after the upgrade except an IOException is thrown when I navigate away from a page using Atmosphere (via the RichFaces push component).
> The stacktrace looks like:
> {code}
> 16:35:27,083 ERROR [stderr] (default task-39) Exception in thread "default task-39" java.lang.RuntimeException: java.io.IOException: Broken pipe
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527)
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:294)
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:432)
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:517)
> 16:35:27,084 ERROR [stderr] (default task-39) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 16:35:27,084 ERROR [stderr] (default task-39) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 16:35:27,084 ERROR [stderr] (default task-39) at java.lang.Thread.run(Thread.java:745)
> 16:35:27,084 ERROR [stderr] (default task-39) Caused by: java.io.IOException: Broken pipe
> 16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> 16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> 16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> 16:35:27,085 ERROR [stderr] (default task-39) at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> 16:35:27,085 ERROR [stderr] (default task-39) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487)
> 16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:531)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:256)
> 16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> 16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:625)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
> 16:35:27,086 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
> 16:35:27,086 ERROR [stderr] (default task-39) ... 6 more
> {code}
> There are no richfaces not atmosphere classes in the stacktrace, so I'm not sure how to narrow the problem down.
> A reproducer can be found by building RichFaces from the branch:
> https://github.com/richfaces/richfaces/tree/RF-13753-upgrade-atmosphere
> and deploying the showcase. The push component sample triggers the error when you navigate away from the page:
> http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=push&s...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3758) Unable to run JSF applications deployed to "/"
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3758?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3758.
----------------------------------
Fix Version/s: 9.0.0.Alpha1
Resolution: Done
> Unable to run JSF applications deployed to "/"
> -----------------------------------------------
>
> Key: WFLY-3758
> URL: https://issues.jboss.org/browse/WFLY-3758
> Project: WildFly
> Issue Type: Bug
> Components: JSF, Web (Undertow)
> Affects Versions: 9.0.0.Alpha1
> Environment: WildFly master at 50a830205c, JDK 1.7
> Reporter: Ken H
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> I don't think the patch in pull request 6338 is right. I experienced the issue defined in WLFY-3448 on 8.1.0.Final, then built master at 50a830205c and the new behavior is different but still broken. Now requests to http://host/login throws a Not Found, the server is expecting http://host//login (which explodes because it isn't valid). If I hit http://host then the redirect is generated to http://host//welcome because httpServletRequest.getContextPath() is returning "/" (when it was returning an empty string in 7.x).
> From web.xml:
> {code}
> <welcome-file-list>
> <welcome-file>/</welcome-file>
> </welcome-file-list>
> {code}
> From jboss-web.xml:
> {code}
> <jboss-web>
> <context-root>/</context-root>
> </jboss-web>
> {code}
> My app is packaged as a war, so no application.xml exists to define context-root.
> I would say this is a regression caused by the resolution to WLFY-3448
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3765) Runtime modifications in static files of exploded WARs of exploded EARs aren't reflected.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3765?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3765.
----------------------------------
Fix Version/s: 9.0.0.Alpha1
Resolution: Done
> Runtime modifications in static files of exploded WARs of exploded EARs aren't reflected.
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-3765
> URL: https://issues.jboss.org/browse/WFLY-3765
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: OS: Xubuntu 14.04 64-bit (Linux)
> JDK: 1.8.0 Update 20
> Reporter: Avor Nadal
> Assignee: Stuart Douglas
> Labels: deployment, exploded, undertow
> Fix For: 9.0.0.Alpha1
>
>
> If you put a exploded WAR in $WILDFLY/standalone/deployments/ and modify a static file once the application is deployed and running, such as an HTML or JPEG file, the changes are reflected in the output to the client. However, if the exploded WAR is contained at the same time in a exploded EAR, they aren't.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3852) EJB @Schedule interleaves timer calls with @AccessTimeout(0)
by Tibor Digana (JIRA)
[ https://issues.jboss.org/browse/WFLY-3852?page=com.atlassian.jira.plugin.... ]
Tibor Digana commented on WFLY-3852:
------------------------------------
Hi Stuart,
The @AccessTimeout(0) is an exceptional status in the behavior of Write/Read lock, where 0 does not mean timeout.
The Javadoc in annotation AccessTimeout does not say anything about any lock.
This means that @AccessTimeout(0) != (Read or Write) lock.
Here the point is that the timer's method should not be called if some other thread is currently in it.
>> The current wording in the spec basically implies that @AccessTimeout(0) turns a READ lock into a WRITE lock
If you do it like that, then it's another bug. The idea behind @AccessTimeout(0) is different. No need to interchange the locks.
The @AccessTimeout(0) is not supposed to set concurrent Thread to BLOCKED status in Write lock.
Simply just use tryLock() method instead of lock() if @AccessTimeout(0) is used on the timer's method.
That's all we need to do.
When you observe false from tryLock(), then you should ignore calling timer's method because other thread is currently executing it; Otherwise (returned true) you have observed lock pretty much like with the lock() method on ReentrantReadWriteLock.
> EJB @Schedule interleaves timer calls with @AccessTimeout(0)
> ------------------------------------------------------------
>
> Key: WFLY-3852
> URL: https://issues.jboss.org/browse/WFLY-3852
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 8.1.0.Final
> Environment: Win 7 x64 / i7
> Reporter: Tibor Digana
> Assignee: David Lloyd
> Priority: Critical
>
> Note: The value in @AccessTimeout(value = 0) is not a real timeout. It's a marker skipping scheduler on concurrent Thread.
> Actual:
> The scheduled method is annotated with @AccessTimeout(0) and @Lock(READ). Very long calls interleave concurrently.
> Expected:
> The calls should not interleave if and only if @AccessTimeout(0) is used. Does not matter which LockType is used.
> According to the Javadoc
> "A value of 0 means concurrent access is not permitted."
> In other words the timer should give it up on concurrent Thread.
> The timer should not wait for read/write lock due to the value in the annotation is not -1.
> In the internal implementation of TomEE server the timer skips scheduling if Lock.tryLock() returns false in this usecase. This can be Read or Write lock - does not matter.
> Don't be confused with WFLY-3430.
> I think the fix in WFLY-3430 should only go with the annotation @AccessTimeout(0) with whatever LockType. If this annotation is not used then the next call should be concurrent / blocked depending on READ / WRITE LockType, respectively.
> My code:
> @Startup
> @Singleton
> @Lock(READ)
> public class MyTimer {
> @Schedule(minute = "*", hour = "*", persistent = false, info = "My Timer")
> @AccessTimeout(0)
> public void updateByMinutes() {}
> }
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3852) EJB @Schedule interleaves timer calls with @AccessTimeout(0)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3852?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3852:
--------------------------------------
This wording in the spec seems really odd to me, I am going to ask the EG what the actual intention was. If you only have a read lock you will never fail to acquire the lock, so I would not expect the timeout to have any effect. The current wording in the spec basically implies that @AccessTimeout(0) turns a READ lock into a WRITE lock, which just seems plain wrong to me.
> EJB @Schedule interleaves timer calls with @AccessTimeout(0)
> ------------------------------------------------------------
>
> Key: WFLY-3852
> URL: https://issues.jboss.org/browse/WFLY-3852
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 8.1.0.Final
> Environment: Win 7 x64 / i7
> Reporter: Tibor Digana
> Assignee: David Lloyd
> Priority: Critical
>
> Note: The value in @AccessTimeout(value = 0) is not a real timeout. It's a marker skipping scheduler on concurrent Thread.
> Actual:
> The scheduled method is annotated with @AccessTimeout(0) and @Lock(READ). Very long calls interleave concurrently.
> Expected:
> The calls should not interleave if and only if @AccessTimeout(0) is used. Does not matter which LockType is used.
> According to the Javadoc
> "A value of 0 means concurrent access is not permitted."
> In other words the timer should give it up on concurrent Thread.
> The timer should not wait for read/write lock due to the value in the annotation is not -1.
> In the internal implementation of TomEE server the timer skips scheduling if Lock.tryLock() returns false in this usecase. This can be Read or Write lock - does not matter.
> Don't be confused with WFLY-3430.
> I think the fix in WFLY-3430 should only go with the annotation @AccessTimeout(0) with whatever LockType. If this annotation is not used then the next call should be concurrent / blocked depending on READ / WRITE LockType, respectively.
> My code:
> @Startup
> @Singleton
> @Lock(READ)
> public class MyTimer {
> @Schedule(minute = "*", hour = "*", persistent = false, info = "My Timer")
> @AccessTimeout(0)
> public void updateByMinutes() {}
> }
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JBMESSAGING-1955) Deadlock on failover with client lease
by Doug Grove (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1955?page=com.atlassian.jira.... ]
Doug Grove updated JBMESSAGING-1955:
------------------------------------
Description:
JBoss is configured as an 8 node cluster. This cluster is for JMS messaging only. Other JBoss instances host MDBs. When failover occurs in the 8 node cluster, a deadlock is seen on the JBoss instances that host the MDBs.
{code}
Found one Java-level deadlock:
=============================
"Thread-177":
waiting to lock monitor 0x4c561e18 (object 0x7c3dfdb0, a java.lang.Object),
which is held by "Thread-130"
"Thread-130":
waiting to lock monitor 0x08aea1a4 (object 0x81dde148, a java.lang.Object),
which is held by "Timer-18"
"Timer-18":
waiting to lock monitor 0x4c561e18 (object 0x7c3dfdb0, a java.lang.Object),
which is held by "Thread-130"
Java stack information for the threads listed above:
===================================================
"Thread-177":
at org.jboss.remoting.Client.removeConnectionListener(Client.java:599)
- waiting to lock <0x7c3dfdb0> (a java.lang.Object)
at org.jboss.jms.client.remoting.JMSRemotingConnection.removeConnectionListener(JMSRemotingConnection.java:565)
- locked <0x7f589740> (a org.jboss.jms.client.remoting.JMSRemotingConnection)
at org.jboss.jms.client.container.ConnectionAspect.handleClose(ConnectionAspect.java:183)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientConnectionDelegate.close(ClientConnectionDelegate.java)
at org.jboss.jms.client.JBossConnection.close(JBossConnection.java:132)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardownConnection(JmsActivation.java:635)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardown(JmsActivation.java:376)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.handleFailure(JmsActivation.java:275)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.onException(JmsActivation.java:312)
at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:120)
- locked <0x7f320410> (a java.lang.Object)
- locked <0x7f5899a0> (a org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener)
at org.jboss.remoting.ConnectionValidator$3.run(ConnectionValidator.java:524)
"Thread-130":
at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:507)
- waiting to lock <0x81dde148> (a java.lang.Object)
at org.jboss.remoting.Client.setupClientLease(Client.java:2056)
- locked <0x7c3dfdb0> (a java.lang.Object)
at org.jboss.remoting.Client.connect(Client.java:1918)
at org.jboss.remoting.Client.connect(Client.java:737)
at org.jboss.jms.client.remoting.JMSRemotingConnection$1.run(JMSRemotingConnection.java:374)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:368)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:175)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeTarget(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:80)
at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateConnectionDelegate_25018031.invoke(StateCreationAspect_z_handleCreateConnectionDelegate_25018031.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
at org.jboss.jms.client.container.ClusteringAspect.handleCreateConnectionDelegate(ClusteringAspect.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.createConnectionDelegate(ClientClusteredConnectionFactoryDelegate.java)
at org.jboss.jms.client.FailoverCommandCenter.failureDetected(FailoverCommandCenter.java:129)
at org.jboss.jms.client.container.ConnectionFailureListener.handleConnectionException(ConnectionFailureListener.java:62)
at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:84)
- locked <0x813598d0> (a org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener)
at org.jboss.remoting.ConnectionValidator$3.run(ConnectionValidator.java:524)
"Timer-18":
at org.jboss.remoting.Client.notifyListeners(Client.java:1873)
- waiting to lock <0x7c3dfdb0> (a java.lang.Object)
at org.jboss.remoting.LeasePinger.stopPing(LeasePinger.java:134)
at org.jboss.remoting.MicroRemoteClientInvoker.terminateLease(MicroRemoteClientInvoker.java:434)
- locked <0x81dde148> (a java.lang.Object)
at org.jboss.remoting.ConnectionValidator$WaitOnConnectionCheckTimerTask.run(ConnectionValidator.java:1081)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Found 1 deadlock.
{code}
was:
JBoss is configured as an 8 node cluster. This cluster is for JMS messaging only. Other JBoss instances host MDBs. When failover occurs in the 8 node cluster, a deadlock is seen on the JBoss instances that host the MDBs.
{quote}
Found one Java-level deadlock:
=============================
"Thread-177":
waiting to lock monitor 0x4c561e18 (object 0x7c3dfdb0, a java.lang.Object),
which is held by "Thread-130"
"Thread-130":
waiting to lock monitor 0x08aea1a4 (object 0x81dde148, a java.lang.Object),
which is held by "Timer-18"
"Timer-18":
waiting to lock monitor 0x4c561e18 (object 0x7c3dfdb0, a java.lang.Object),
which is held by "Thread-130"
Java stack information for the threads listed above:
===================================================
"Thread-177":
at org.jboss.remoting.Client.removeConnectionListener(Client.java:599)
- waiting to lock <0x7c3dfdb0> (a java.lang.Object)
at org.jboss.jms.client.remoting.JMSRemotingConnection.removeConnectionListener(JMSRemotingConnection.java:565)
- locked <0x7f589740> (a org.jboss.jms.client.remoting.JMSRemotingConnection)
at org.jboss.jms.client.container.ConnectionAspect.handleClose(ConnectionAspect.java:183)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientConnectionDelegate.close(ClientConnectionDelegate.java)
at org.jboss.jms.client.JBossConnection.close(JBossConnection.java:132)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardownConnection(JmsActivation.java:635)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardown(JmsActivation.java:376)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.handleFailure(JmsActivation.java:275)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.onException(JmsActivation.java:312)
at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:120)
- locked <0x7f320410> (a java.lang.Object)
- locked <0x7f5899a0> (a org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener)
at org.jboss.remoting.ConnectionValidator$3.run(ConnectionValidator.java:524)
"Thread-130":
at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:507)
- waiting to lock <0x81dde148> (a java.lang.Object)
at org.jboss.remoting.Client.setupClientLease(Client.java:2056)
- locked <0x7c3dfdb0> (a java.lang.Object)
at org.jboss.remoting.Client.connect(Client.java:1918)
at org.jboss.remoting.Client.connect(Client.java:737)
at org.jboss.jms.client.remoting.JMSRemotingConnection$1.run(JMSRemotingConnection.java:374)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:368)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:175)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeTarget(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:80)
at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateConnectionDelegate_25018031.invoke(StateCreationAspect_z_handleCreateConnectionDelegate_25018031.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
at org.jboss.jms.client.container.ClusteringAspect.handleCreateConnectionDelegate(ClusteringAspect.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.createConnectionDelegate(ClientClusteredConnectionFactoryDelegate.java)
at org.jboss.jms.client.FailoverCommandCenter.failureDetected(FailoverCommandCenter.java:129)
at org.jboss.jms.client.container.ConnectionFailureListener.handleConnectionException(ConnectionFailureListener.java:62)
at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:84)
- locked <0x813598d0> (a org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener)
at org.jboss.remoting.ConnectionValidator$3.run(ConnectionValidator.java:524)
"Timer-18":
at org.jboss.remoting.Client.notifyListeners(Client.java:1873)
- waiting to lock <0x7c3dfdb0> (a java.lang.Object)
at org.jboss.remoting.LeasePinger.stopPing(LeasePinger.java:134)
at org.jboss.remoting.MicroRemoteClientInvoker.terminateLease(MicroRemoteClientInvoker.java:434)
- locked <0x81dde148> (a java.lang.Object)
at org.jboss.remoting.ConnectionValidator$WaitOnConnectionCheckTimerTask.run(ConnectionValidator.java:1081)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Found 1 deadlock.
{quote}
> Deadlock on failover with client lease
> --------------------------------------
>
> Key: JBMESSAGING-1955
> URL: https://issues.jboss.org/browse/JBMESSAGING-1955
> Project: JBoss Messaging
> Issue Type: Feature Request
> Components: Messaging Core Distributed Support
> Affects Versions: 1.4.8.SP5
> Environment: JBoss EAP 5.1.2
> Reporter: Doug Grove
>
> JBoss is configured as an 8 node cluster. This cluster is for JMS messaging only. Other JBoss instances host MDBs. When failover occurs in the 8 node cluster, a deadlock is seen on the JBoss instances that host the MDBs.
> {code}
> Found one Java-level deadlock:
> =============================
> "Thread-177":
> waiting to lock monitor 0x4c561e18 (object 0x7c3dfdb0, a java.lang.Object),
> which is held by "Thread-130"
> "Thread-130":
> waiting to lock monitor 0x08aea1a4 (object 0x81dde148, a java.lang.Object),
> which is held by "Timer-18"
> "Timer-18":
> waiting to lock monitor 0x4c561e18 (object 0x7c3dfdb0, a java.lang.Object),
> which is held by "Thread-130"
> Java stack information for the threads listed above:
> ===================================================
> "Thread-177":
> at org.jboss.remoting.Client.removeConnectionListener(Client.java:599)
> - waiting to lock <0x7c3dfdb0> (a java.lang.Object)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.removeConnectionListener(JMSRemotingConnection.java:565)
> - locked <0x7f589740> (a org.jboss.jms.client.remoting.JMSRemotingConnection)
> at org.jboss.jms.client.container.ConnectionAspect.handleClose(ConnectionAspect.java:183)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate.close(ClientConnectionDelegate.java)
> at org.jboss.jms.client.JBossConnection.close(JBossConnection.java:132)
> at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardownConnection(JmsActivation.java:635)
> at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardown(JmsActivation.java:376)
> at org.jboss.resource.adapter.jms.inflow.JmsActivation.handleFailure(JmsActivation.java:275)
> at org.jboss.resource.adapter.jms.inflow.JmsActivation.onException(JmsActivation.java:312)
> at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:120)
> - locked <0x7f320410> (a java.lang.Object)
> - locked <0x7f5899a0> (a org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener)
> at org.jboss.remoting.ConnectionValidator$3.run(ConnectionValidator.java:524)
> "Thread-130":
> at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:507)
> - waiting to lock <0x81dde148> (a java.lang.Object)
> at org.jboss.remoting.Client.setupClientLease(Client.java:2056)
> - locked <0x7c3dfdb0> (a java.lang.Object)
> at org.jboss.remoting.Client.connect(Client.java:1918)
> at org.jboss.remoting.Client.connect(Client.java:737)
> at org.jboss.jms.client.remoting.JMSRemotingConnection$1.run(JMSRemotingConnection.java:374)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:368)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:175)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeTarget(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:80)
> at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateConnectionDelegate_25018031.invoke(StateCreationAspect_z_handleCreateConnectionDelegate_25018031.java)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> at org.jboss.jms.client.container.ClusteringAspect.handleCreateConnectionDelegate(ClusteringAspect.java:134)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.createConnectionDelegate(ClientClusteredConnectionFactoryDelegate.java)
> at org.jboss.jms.client.FailoverCommandCenter.failureDetected(FailoverCommandCenter.java:129)
> at org.jboss.jms.client.container.ConnectionFailureListener.handleConnectionException(ConnectionFailureListener.java:62)
> at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:84)
> - locked <0x813598d0> (a org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener)
> at org.jboss.remoting.ConnectionValidator$3.run(ConnectionValidator.java:524)
> "Timer-18":
> at org.jboss.remoting.Client.notifyListeners(Client.java:1873)
> - waiting to lock <0x7c3dfdb0> (a java.lang.Object)
> at org.jboss.remoting.LeasePinger.stopPing(LeasePinger.java:134)
> at org.jboss.remoting.MicroRemoteClientInvoker.terminateLease(MicroRemoteClientInvoker.java:434)
> - locked <0x81dde148> (a java.lang.Object)
> at org.jboss.remoting.ConnectionValidator$WaitOnConnectionCheckTimerTask.run(ConnectionValidator.java:1081)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> Found 1 deadlock.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month