[JBoss JIRA] (WFLY-3852) EJB @Schedule interleaves timer calls with @AccessTimeout(0)
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-3852?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf commented on WFLY-3852:
-------------------------------------
Raised at https://java.net/projects/ejb-spec/lists/users/archive/2014-09/message/0
> 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
[JBoss JIRA] (WFCORE-98) Remoting is using the wrong protocol names
by David Lloyd (JIRA)
David Lloyd created WFCORE-98:
---------------------------------
Summary: Remoting is using the wrong protocol names
Key: WFCORE-98
URL: https://issues.jboss.org/browse/WFCORE-98
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Remoting
Reporter: David Lloyd
Assignee: Brian Stansberry
The Remoting protocol names are presently:
* remoting
* http-remoting
* https-remoting
They should be:
* remote
* remote+http
* remote+https
respectively.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1877:
--------------------------------
Searched the code base and code like the above does occur, but mostly using {{currentTimeMillis()}}. I'll change the important occurrences (excluding deprecated classes) of this to {{nanoTime()}}, then setting back the system clock won't have any effect.
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1877:
---------------------------
Priority: Major (was: Critical)
Downgraded; not as much impact as I thought, e.g.
{code:java}
long target_time=nanos() + timeout_ns;
while(...) {
wait_time=target_time - nanos();
if(wait_time <= 0)
break;
}
{code}
Var {{wait_time}} will always be positive !
What won't work is code like the following:
{code:java}
while(nanos() < target_time) {
...
}
{code}
Here, the current time could still be possitve while {{target_time}} could be negative. The correct code would be
{code:java}
while(target_time - nanos() > 0) {...}
{code}
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JBJCA-1214) XAResource statistics
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1214:
--------------------------------------
Summary: XAResource statistics
Key: JBJCA-1214
URL: https://issues.jboss.org/browse/JBJCA-1214
Project: IronJacamar
Issue Type: Task
Components: Core, Deployer
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.2.0.CR1
Attach it to the pool statistics instance
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[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 resolved JBMESSAGING-1955.
-------------------------------------
Resolution: Duplicate Issue
Duplicate of:
https://issues.jboss.org/browse/JBREM-1297
> 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
> Assignee: 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