2013-10-21 40 views
0

我想在計劃時間(英國東部時間23點59分和英國西部時間8點)執行兩項任務。我創建了一個保持這些方法的EJB單例bean:Java EE單例計劃任務執行兩次

@Singleton 
public class OfferManager { 

    @Schedule(hour = "23", minute = "59", timezone = "CET") 
    @AccessTimeout(value = 0) // concurrent access is not permitted 
    public void fetchNewOffers() { 
     Logger.getLogger(OfferManager.class.getName()).log(Level.INFO, "Fetching new offers started"); 

     // ... 

     Logger.getLogger(OfferManager.class.getName()).log(Level.INFO, "Fetching new offers finished"); 
    } 

    @Schedule(hour="8", minute = "0", timezone = "CET") 
    public void sendMailsWithReports() { 
     Logger.getLogger(OfferManager.class.getName()).log(Level.INFO, "Generating reports started"); 

     // ... 

     Logger.getLogger(OfferManager.class.getName()).log(Level.INFO, "Generating reports finished"); 
    } 
} 

問題是兩個任務都執行了兩次。服務器是WildFly Beta1,在UTC時間配置。

這裏有一些服務器日誌,這可能是有用的:

2013-10-20 11:15:17,684 INFO [org.jboss.as.server] (XNIO-1 task-7) JBAS018559: Deployed "crawler-0.3.war" (runtime-name : "crawler-0.3.war") 
2013-10-20 21:59:00,070 INFO [com.indeed.control.OfferManager] (EJB default - 1) Fetching new offers started 
.... 
2013-10-20 22:03:48,608 INFO [com.indeed.control.OfferManager] (EJB default - 1) Fetching new offers finished 
2013-10-20 23:59:00,009 INFO [com.indeed.control.OfferManager] (EJB default - 2) Fetching new offers started 
.... 
2013-10-20 23:59:22,279 INFO [com.indeed.control.OfferManager] (EJB default - 2) Fetching new offers finished 

什麼可能是這種行爲的原因是什麼?

+0

檢查是否有其他'@ Schedule'可以在'21:59:00'上運行。您顯示的代碼此時應該*不*運行。 – 2013-10-21 09:53:37

+0

這些是使用'@ Schedule'註釋的唯一方法 – Khozzy

+0

第二種方法也執行兩次。在計劃的時間之前2小時,然後正確 – Khozzy

回答

1

我解決了指定與服務器時間(UTC)的預定時間的問題。 所以

@Schedule(hour = "23", minute = "59", timezone = "CET") 

被替換:

@Schedule(hour = "21", minute = "59") 

我不知道這樣beahaviour的原因,也許Wildfly的提前釋放的問題。

0

我與TomEE羽流7.0.4有同樣的問題。在我的情況下,解決方案是將@Singleton更改爲@Stateless