ejb 3.1 में टाइमर सेवा - शेड्यूल कॉलिंग टाइमआउट समस्या

Question

मैंने @Singleton, @Schedule और @Timeout एनोटेशन के साथ सरल उदाहरण बनाया है ताकि वे मेरी समस्या का समाधान कर सकें या नहीं।

परिदृश्य यह है: ईजेबी प्रत्येक 5 सीकंडों को 'चेक' समारोह कहते हैं, और यदि कुछ शर्तों को पूरा किया जाता है तो यह एकल एक्शन टाइमर बनाएगा जो असीमित फैशन में कुछ लंबी चल रही प्रक्रिया का आह्वान करेगा। (यह कतार कार्यान्वयन प्रकार की तरह है)। यह तब जांचना जारी रखता है, लेकिन लंबी चल रही प्रक्रिया होने पर यह एक और शुरू नहीं होगा।

नीचे कोड है जिसके साथ मैं आया था, लेकिन यह समाधान काम नहीं करता है, क्योंकि ऐसा लगता है कि मैं बना रहा हूं एसिंक्रोनस कॉल वास्तव में मेरी @ शेड्यूल विधि को अवरुद्ध कर रहा है।

@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 नवीनतम निर्माण के साथ परीक्षण - का उल्लेख

Answer 1

डिफ़ॉल्ट @ConcurrencyManagement एकमात्र के लिए LockType.WRITE के डिफ़ॉल्ट @Lock साथ ConcurrencyManagementType.CONTAINER है भूल गया। असल में, इसका मतलब है कि प्रत्येक विधि (जेनररपोर्ट सहित) को सिंक्रनाइज़ किए गए कीवर्ड के साथ प्रभावी रूप से चिह्नित किया जाता है, जिसका अर्थ यह है कि उत्पन्न होने पर चेकक्यूयूस्ट ब्लॉक अवरुद्ध होगा।

ConcurrencyManagement (ConcurrencyManagementType.BEAN) या @ लॉक (LockType.READ) का उपयोग करने पर विचार करें। अगर कोई सुझाव मदद नहीं करता है, तो मुझे संदेह है कि आपको ग्लासफ़िश बग मिला है।

एक तरफ के रूप में, आप शायद लगातार = झूठी चाहते हैं क्योंकि आपको शायद यह गारंटी देने की आवश्यकता नहीं है कि चेकक्यूयूस्ट विधि आपके सर्वर ऑफ़लाइन होने पर भी हर 5 सेकंड में आग लगती है। दूसरे शब्दों में, जब आप अपने सर्वर को ऑनलाइन वापस लाते हैं तो आपको शायद "पकड़ने" को आग लगाने के लिए कंटेनर की आवश्यकता नहीं होती है।