Error while calling timeout for timer - failed to get lock for 5 MINUTES in EJB 3 timerservice

Question

I have an application running on jboss 6.1 that determines a lot of speaker timers on startup (like doSomething every minute) based on information already stored in the database. Timers are created programmatically based on this information:

TimerConfig timerConfig = new TimerConfig(); timerConfig.setInfo(info); timerConfig.setPersistent(false); Timer timer = timerService.createCalendarTimer(scheduleExpression, timerConfig); 

Today I found that the created "every minute" timer no longer works. Checking the log yesterday, I found this strange error (full trace below)

 Error invoking timeout for timer: [id=32b0902e-d1ee-4090-9938-98349a20340d timedObjectId=jboss.j2ee:ear=myear.ear,jar=myjar.jar,name=AppScheduler,service=EJB3 auto-timer?:false persistent?:false timerService=org.jboss.ejb3.timerservice.mk2.TimerServiceImpl@40 36a060 initialExpiration=Thu Jan 17 00:00:00 GMT-02:00 2013 intervalDuration(in milli sec)=0 nextExpiration=Sun Jan 20 06:06:00 GMT-02:00 2013 timerState=IN_TIMEOUT: javax.ejb.ConcurrentAccessTimeoutException: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on [advisedMethod=public void my.app.AppScheduler.process(javax.ejb.Timer), unadvisedMethod=public void my.app.AppScheduler.process(javax.ejb.Timer), metadata=null, targetObject=my.app.AppScheduler@97672ba , arguments=[Ljava.lang.Object;@3f661630] - could not obtain lock within 5MINUTES at org.jboss.ejb3.concurrency.aop.interceptor.ContainerManagedConcurrencyInterceptor.invoke(ContainerManagedConcurrencyInterceptor.java:176) [:1.0.0-alpha-4] at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86) [jboss-aop.jar:2.2.2.GA] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.2.GA] at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47) [:1.7.21] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.2.GA] at org.jboss.ejb3.tx.StatelessBMTInterceptor.handleInvocation(StatelessBMTInterceptor.java:100) [:1.0.4] at org.jboss.ejb3.tx.BMTInterceptor.invoke(BMTInterceptor.java:57) [:1.0.4] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.2.GA] at org.jboss.ejb3.tx2.aop.NoOpInterceptor.invoke(NoOpInterceptor.java:45) [:0.0.2] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.2.GA] at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) [:1.0.0.GA] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.2.GA] at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41) [:1.7.21] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.2.GA] at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67) [:1.7.21] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.2.GA] at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) [:1.7.21] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.2.GA] at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) [:1.0.1] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.2.GA] at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86) [:1.7.21] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.2.GA] at org.jboss.ejb3.singleton.aop.impl.AOPBasedInterceptorRegistry.intercept(AOPBasedInterceptorRegistry.java:111) [:1.0.2] at org.jboss.ejb3.singleton.impl.container.SingletonContainer.invoke(SingletonContainer.java:206) [:1.0.2] at org.jboss.ejb3.singleton.aop.impl.AOPBasedSingletonContainer.callTimeout(AOPBasedSingletonContainer.java:888) [:1.0.2] at org.jboss.ejb3.singleton.aop.impl.AOPBasedSingletonContainer.callTimeout(AOPBasedSingletonContainer.java:837) [:1.0.2] at org.jboss.ejb3.timerservice.mk2.task.CalendarTimerTask.callTimeout(CalendarTimerTask.java:84) [:1.0.0-alpha-13] at org.jboss.ejb3.timerservice.mk2.task.TimerTask.run(TimerTask.java:127) [:1.0.0-alpha-13] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_24] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_24] at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_24] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) [:1.6.0_24] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) [:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24] at java.lang.Thread.run(Thread.java:662) [:1.6.0_24] 

The main problem is not an error in one run, but that after this problem the timer stops working and starts again if jboss restarts. Does anyone know a way to prevent this behavior? The exception indicates a 5-minute timeout, but I do not see where to change it.

Thanks in advance.

Answer 1

Here is what the spec says about this exception

4.8.5.5.1 Concurrent Access Timeouts

A concurrent access attempt that cannot immediately obtain an appropriate lock is blocked until it can move forward. @AccessTimeout is used to indicate the time during which an access attempt should be blocked before the time expires. Access timeouts apply only to methods acceptable for concurrency blocking on a Singleton bean with a managed concurrency container. If the access attempt is disabled, the container throws a javax.ejb.ConcurrentAccessTimeoutException to the client. @AccessTimeout can be specified in the business method or in the bean class (or superclass). @AccessTimeout specified in the class applies the access timeout to all business methods of this class. If @AccessTimeout is specified for both the class and the business method of this class, the annotation of the level method takes precedence. A value of @AccessTimeout -1 indicates that the client’s request will block indefinitely until forwarding progress can be achieved. A value of @AccessTimeout 0 indicates that concurrent access is denied. Attempts to access methods with a timeout value of 0 result in javax.ejb.ConcurrentAccessException

So, I just turned on the access timeout to solve my problem (this 5-minute default time depends on the provider).

 @Timeout @AccessTimeout(value = 20, unit = TimeUnit.MINUTES) public void process(Timer timer) { //code here } 

Answer 2

In my case, the problem was related to the last sudden shutdown. I deleted the timers under wildfly/standalone/data/timer-service-data and turned around again.