Błąd wywoływania limitu czasu dla timera - nie można uzyskać blokady w ciągu 5 minut w EJB 3 timerservice

Question

Mam aplikację uruchomioną na jboss 6.1, która definiuje wiele timerów dinamyc przy starcie (np. Coś co minutę) na podstawie informacji już utrwalonych na Baza danych. Liczniki są tworzone programowo na podstawie następujących informacji:

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

Dziś stwierdziłem, że utworzony timer "co minutę" nie działa. Sprawdzanie dziennika Wczoraj znalazłem ten dziwny błąd (pełna śladu Strack poniżej)

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@4036a060 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] 

Głównym problemem nie jest to błąd na jednym wykonaniu, ale po tym problemem timer przestaje działać, a jedynie uruchamia się ponownie, jeśli jboss zostaje zrestartowany. Ktoś zna sposób na uniknięcie tego zachowania? Wyjątek wspomina o 5-minutowym limicie czasu, ale nie widzę, gdzie to zmienić.

Z góry dziękuję.

Answer 1

Oto co mówi na temat specyfikacji tego wyjątku

4.8.5.5.1 równoczesnego dostępu Timeouts

współbieżne próba że nie może od razu nabyć odpowiednią blokadę dostępu jest zablokowany, aż może uczynić naprzód postęp. @AccessTimeout służy do określenia czasu, w którym próba dostępu powinna zostać zablokowana przed przekroczeniem limitu czasu. Przerwy w dostępie mają zastosowanie tylko do metod kwalifikujących się do współbieżności blokowania w komponencie bean Singleton z współbieżnością zarządzaną przez kontener. Jeśli upłynie limit czasu próby dostępu, kontener rzuci klienta javax.ejb.ConcurrentAccessTimeoutException. @AccessTimeout można określić dla metody biznesowej lub dla klasy komponentu bean (lub super klasy). Wartość @AccessTimeout określona dla klasy powoduje zastosowanie limitu czasu dostępu do wszystkich metod biznesowych tej klasy . Jeśli parametr @AccessTimeout jest określony zarówno w klasie, jak i w metodzie biznesowej tej klasy, pierwszeństwo ma adnotacja na poziomie metody . Wartość @AccessTimeout równa się -1 oznacza, że ​​żądanie klienta zostanie zablokowane na czas nieokreślony, dopóki nie można wykonać postępu. Wartość @AccessTimeout równa 0 wskazuje, że dostęp współbieżny jest niedozwolony. próby dostępu na metod o wartości limitu czasu od 0 skutkować javax.ejb.ConcurrentAccessException

Więc, po prostu wliczone limitu czasu dostępu, aby rozwiązać mój problem (czyli 5 minut domyślny czas jest specyficzny sprzedawca).

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

Answer 2

W moim przypadku problem był związany z ostatnim niespodziewanym wyłączeniem. Usunąłem liczniki pod numerem wildfly/standalone/data/timer-service-data i ponownie wdrożyłem.