调用计时器超时的错误 - 在EJB 3 timerservice下无法在5MINUTES内获取锁定 [英] Error invoking timeout for timer - could not obtain lock within 5MINUTES at EJB 3 timerservice

查看:132
本文介绍了调用计时器超时的错误 - 在EJB 3 timerservice下无法在5MINUTES内获取锁定的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个运行在jboss 6.1上的应用程序,它基于数据库上已经存在的信息,在启动时定义了很多dinamyc定时器(例如每分钟几分钟)。定时器是基于这些信息以编程方式创建的:

  TimerConfig timerConfig = new TimerConfig(); 
timerConfig.setInfo(info);
timerConfig.setPersistent(false);
定时器定时器= timerService.createCalendarTimer(scheduleExpression,
timerConfig);

今天我发现创建的每分钟计时器不再工作了。检查昨天的日志,我发现这个奇怪的错误(完整的strack跟踪在下面)

 调用超时时间的错误:[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(以毫秒为单位)= 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
并发访问超时[suggestedMethod = 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]
- 无法获取锁定在5MINUTES
在org.jboss.ejb3.concurrency.aop.interceptor.ContainerMana gedConcurrencyInterceptor.invoke(ContainerManagedConcurrencyInterceptor.java:176)[:1.0.0-alpha-4]
在org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)[jboss-aop.jar: 2.2.2.GA]
在org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)[jboss-aop.jar:2.2.2.GA]
在org.jboss .ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)[:1.7.21]
在org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)[jboss-aop.jar:2.2 .2.GA]
在org.jboss.ejb3.tx.StatelessBMTInterceptor.handleInvocation(StatelessBMTInterceptor.java:100)[:1.0.4]
在org.jboss.ejb3.tx.BMTInterceptor.invoke (BMTInterceptor.java:57)[:1.0.4]
在org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)[jboss-aop.jar:2.2.2.GA]
在org.jboss.ejb3.tx2.aop.NoOpInterceptor.invoke(NoOpInterceptor.java:45)[:0.0.2]
在org.jboss.aop.joinp oint.MethodInvocation.invokeNext(MethodInvocation.java:102)[jboss-aop.jar:2.2.2.GA]
在org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)[: 1.0.0.GA]
在org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)[jboss-aop.jar:2.2.2.GA]
在org.jboss .ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)[:1.7.21]
在org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)[jboss-aop.jar:2.2 .2.GA]
在org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)[:1.7.21]
在org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation .java:102)[jboss-aop.jar:2.2.2.GA]
在org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47)[:1.7.21]
在org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)[ jboss-aop.jar:2.2.2.GA]
在org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)[:1.0.1]
在org.jboss。 aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)[jboss-aop.jar:2.2.2.GA]
在org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86) [:1.7.21]
在org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)[jboss-aop.jar:2.2.2.GA]
在org.jboss .ejb3.singleton.aop.impl.AOPBasedInterceptorRegistry.intercept(AOPBasedInterceptorRegistry.java:111)[:1.0.2]
在org.jboss.ejb3.singleton.impl.container.SingletonContainer.invoke(SingletonContainer.java: 206)[:1.0.2]
在org.jboss.ejb3.singleton.aop.impl.AOPBasedSingletonContainer.callTimeout(AOPBasedSingletonContainer.java:888)[:1.0.2]
在org.jboss。 ejb3.singleton.aop.impl.AOPBasedSingletonContainer.callTimeout(AOPBasedSingletonContainer.java:837)[:1.0.2]
在org.jboss.ejb3.timerservice.mk2.task.CalendarTimerTask.callTimeout(CalendarTimerTask.java:84)[:1.0.0-alpha-13]
在org.jboss.ejb3.timerservice。 mk2.task.TimerTask.run(TimerTask.java:127)[:1.0.0-alpha-13]
在java.util.concurrent.Executors $ RunnableAdapter.call(Executors.java:441)[:1.6 .0_24]
在java.util.concurrent.FutureTask $ Sync.innerRun(FutureTask.java:303)[:1.6.0_24]
在java.util.concurrent.FutureTask.run(FutureTask.java :138)[:1.6.0_24]
在java.util.concurrent.ScheduledThreadPoolExecutor $ ScheduledFutureTask.access $ 301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_24]
在java.util.concurrent。 ScheduledThreadPoolExecutor $ ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_24]
在java.util.concurrent.ThreadPoolExecutor $ Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_24]
在java.util.concurrent.ThreadPoolExecutor $ Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_24]
在java.l ang.Thread.run(Thread.java:662)[:1.6.0_24]

主要问题不是单次执行中的错误,但是在此问题之后,定时器停止工作,如果jboss重新启动,则仅重新开始运行。任何人都知道如何防止这种行为?例外提到了一个5分钟的超时时间,但我看不到在哪里更改。



提前感谢

解决方案

下面是关于此异常的规范说明


4.8.5.5.1并发访问超时

不能立即获取相应锁的并发访问尝试被阻止,直到
向前推进。 @AccessTimeout用于指定访问尝试
在超时之前被阻止的时间量。访问超时仅适用于符合并发性的
的方法锁定在具有容器管理并发性的Singleton bean上。如果访问尝试超时,容器将向客户端抛出javax.ejb.ConcurrentAccessTimeoutException。可以在业务方法或bean类(或超类)上指定
@AccessTimeout。在类上指定的
@AccessTimeout将访问超时应用于
类的所有业务方法。如果在类和业务方法上指定了@AccessTimeout,则
方法级注释的优先级。
@AccessTimeout值为-1表示客户端请求将无限期阻止,直到可以进行
进度。
@AccessTimeout值为0表示不允许并发访问。超时值为$ 0的
方法的访问尝试导致javax.ejb.ConcurrentAccessException


所以,我刚刚包含访问超时来解决我的问题(默认5分钟是供应商特定的)。

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


I have an application running on jboss 6.1 that defines a lot of dinamyc timers at the startup (e.g doSomething every minute) based on informations already persisted on the database. The timers are created programmatically based on these informations:

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

Today i found that the "every minute" timer created was not working anymore. Checking yesterday log, i found this strange error (full strack 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@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]

The main problem is not the error on a single execution, but that after this problem the timer stops working and only starts running again if the jboss is restarted. Anyone knows a way to prevent this behaviour? The exception mentions a 5 minute timeout but i dont see where to change this.

Thanks in advance.

解决方案

Here's what the specification says about this exception

4.8.5.5.1 Concurrent Access Timeouts

A concurrent access attempt that can not immediately acquire the appropriate lock is blocked until it can make forward progress. @AccessTimeout is used to specify the amount of time the access attempt should be blocked before timing out. Access timeouts only apply to methods eligible for concurrency locks on a Singleton bean with container managed concurrency. If an access attempt times out, the container throws a javax.ejb.ConcurrentAccessTimeoutException to the client. @AccessTimeout can be specified on a business method or on a bean class (or super-class). An @AccessTimeout specified on a class applies the access timeout to all business methods of that class. If @AccessTimeout is specified on both a class and on a business method of that class, the method-level annotation takes precedence. An @AccessTimeout value of -1 indicates that the client request will block indefinitely until forward progress can be made. An @AccessTimeout value of 0 indicates that concurrent access is not allowed. Access attempts on methods with a timeout value of 0 result in a javax.ejb.ConcurrentAccessException

So, I just included access timeout to solve my issue (that 5 minutes default time is vendor specific).

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

这篇关于调用计时器超时的错误 - 在EJB 3 timerservice下无法在5MINUTES内获取锁定的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆