gpt4 book ai didi

java - ejb 3.1 中的计时器服务 - 安排调用超时问题

转载 作者:搜寻专家 更新时间:2023-10-31 08:30:29 24 4
gpt4 key购买 nike

我已经创建了带有@Singleton、@Schedule 和@Timeout 注释的简单示例,以尝试它们是否能解决我的问题。

场景是这样的:EJB 每 5 秒调用一次“检查”函数,如果满足某些条件,它将创建单 Action 计时器,以异步方式调用一些长时间运行的进程。 (这是一种队列实现类型)。然后它继续检查,但是当长时间运行的进程在那里时它不会启动另一个进程。

下面是我想出的代码,但这个解决方案不起作用,因为看起来我正在进行的异步调用实际上阻塞了我的@Schedule 方法。

@Singleton
@Startup
public class GenerationQueue {

private Logger logger = Logger.getLogger(GenerationQueue.class.getName());

private List<String> queue = new ArrayList<String>();

private boolean available = true;

@Resource
TimerService timerService;

@Schedule(persistent=true, minute="*", second="*/5", hour="*")
public void checkQueueState() {

logger.log(Level.INFO,"Queue state check: "+available+" size: "+queue.size()+", "+new Date());

if (available) {

timerService.createSingleActionTimer(new Date(), new TimerConfig(null, false));
}

}

@Timeout
private void generateReport(Timer timer) {

logger.info("!!--timeout invoked here "+new Date());

available = false;

try {

Thread.sleep(1000*60*2); // something that lasts for a bit

} catch (Exception e) {}

available = true;

logger.info("New report generation complete");

}

我在这里错过了什么,或者我应该尝试不同的方法吗?欢迎任何想法:)

使用 Glassfish 3.0.1 最新版本进行测试 - 忘记提及

最佳答案

单例的默认@ConcurrencyManagement 是ConcurrencyManagementType.CONTAINER,默认@Lock 是LockType.WRITE。基本上,这意味着每个方法(包括 generateReports)都有效地标记了 synchronized 关键字,这意味着 checkQueueState 将在 generateReport 运行时阻塞。

考虑使用 ConcurrencyManagement(ConcurrencyManagementType.BEAN) 或 @Lock(LockType.READ)。如果这两个建议都没有帮助,我怀疑您发现了 Glassfish 错误。

顺便说一句,您可能需要 persistent=false,因为您可能不需要保证 checkQueueState 方法每 5 秒触发一次,即使您的服务器处于离线状态。换句话说,当您将服务器重新联机时,您可能不需要容器触发“追赶”。

关于java - ejb 3.1 中的计时器服务 - 安排调用超时问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2691835/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com