जेएमएस कतार पूर्ण है

Question

मेरा जावा ईई एप्लिकेशन लगातार जेएम को कतार में भेजता है, लेकिन कभी-कभी जेएमएस उपभोक्ता अनुप्रयोग ने जेएमएस प्राप्त करना बंद कर दिया। यह जेएमएस कतार को भी बहुत बड़ा बनाता है, जो सर्वर को ध्वस्त करता है। मेरा सर्वर जेबॉस या वेबस्पेयर है। क्या एप्लिकेशन सर्वर "टाइमआउट" जेएमएस संदेशों को हटाने के लिए रणनीति प्रदान करते हैं?

बड़ी जेएमएस कतार को संभालने की रणनीति क्या है? धन्यवाद!

Answer 1

किसी भी एसिंक्रोनस मैसेजिंग के साथ आपको "तेज निर्माता/धीमी उपभोक्ता" समस्या से निपटना होगा। इससे निपटने के कई तरीके हैं।

1. उपभोक्ताओं को जोड़ें। वेबस्पियर एमक्यू के साथ आप गहराई के आधार पर एक कतार ट्रिगर कर सकते हैं। कुछ दुकानें क्यूई गहराई बढ़ने के रूप में नए उपभोक्ता उदाहरण जोड़ने के लिए इसका उपयोग करती हैं। फिर कतार की गहराई में गिरावट शुरू होती है, अतिरिक्त उपभोक्ता मर जाते हैं। इस तरह, उपभोक्ताओं को बदलते भार को समायोजित करने के लिए स्वचालित रूप से स्केल करने के लिए बनाया जा सकता है। अन्य दलालों में आम तौर पर समान कार्यक्षमता होती है।
2. कतार और अंतर्निहित फ़ाइल सिस्टम वास्तव में बड़ा बनाएं। यह विधि पूरी तरह से कतार में वर्कलोड में चोटियों को अवशोषित करने का प्रयास करती है। यह सब कुछ बाद में कतारबद्ध करने के लिए डिजाइन किया गया था। समस्या यह है कि यह अच्छी तरह से स्केल नहीं करता है और आपको डिस्क आवंटित करनी होगी कि 99% समय लगभग खाली होगा।
3. पुराना संदेश निकालें। अगर संदेशों का समापन सेट होता है तो आप उन्हें साफ कर सकते हैं। कुछ जेएमएस ब्रोकर स्वचालित रूप से ऐसा करेंगे जबकि अन्य लोगों पर आपको समाप्त होने वाले संदेशों को हटाने के लिए कतार ब्राउज़ करने की आवश्यकता हो सकती है। इसके साथ समस्या यह है कि सभी संदेश उनके व्यापार मूल्य को खो देते हैं और समाप्ति के लिए योग्य बन जाते हैं। अधिकांश अग्निशमन और संदेश (लेखा परीक्षा लॉग इत्यादि) इस श्रेणी में आते हैं।
4. निर्माता को वापस थ्रोटल करें। जब कतार भर जाती है, तो कुछ भी नए संदेश नहीं डाल सकता है। वेबस्पियर एमक्यू में उत्पादक अनुप्रयोग में फिर एक रिटर्न कोड प्राप्त होता है जो दर्शाता है कि कतार पूर्ण है। यदि आवेदन घातक और क्षणिक त्रुटियों के बीच अंतर करता है, तो यह रोक सकता है और पुनः प्रयास कर सकता है।

इनमें से किसी भी को सफलतापूर्वक कार्यान्वित करने की कुंजी यह है कि आपके सिस्टम को "सॉफ्ट" त्रुटियां प्रदान करने की अनुमति दी जाएगी जो एप्लिकेशन का जवाब देंगे। उदाहरण के लिए, पहली बार क्यूएफयूएलएल स्थिति प्राप्त करने पर कई दुकानें कतार के MAXDEPTH पैरामीटर को बढ़ाएंगी। यदि कतार गहराई अंतर्निहित फ़ाइल सिस्टम के आकार से अधिक है तो परिणाम यह है कि एक "मुलायम" त्रुटि के बजाय जो एक कतार को प्रभावित करता है, फ़ाइल सिस्टम भरता है और पूरा नोड प्रभावित होता है। आप सिस्टम को ट्यून करने से बहुत बेहतर हैं ताकि कतार फ़ाइल सिस्टम भरने से पहले MAXDEPTH को अच्छी तरह से हिट करे लेकिन फिर किसी भी तरीके से पूर्ण कतार पर प्रतिक्रिया करने के लिए ऐप या अन्य प्रक्रियाओं का भी वाद्य यंत्र।

कोई फर्क नहीं पड़ता कि आप और क्या करते हैं, ऊपर विकल्प # 4 अनिवार्य है। इससे कोई फर्क नहीं पड़ता कि आप कितनी डिस्क आवंटित करते हैं या आप कितने उपभोक्ता उदाहरण तैनात करते हैं या आप संदेशों को कितनी जल्दी समाप्त करते हैं, वहां हमेशा एक संभावना है कि आपका उपभोक्ता संदेश उत्पादन के साथ नहीं रहेगा। जब ऐसा होता है तो आपके निर्माता एप को पीछे हटना चाहिए, या अलार्म उठाएं और लटका या मरने के अलावा कुछ भी रोकें या करें। असिंक्रोनस मैसेजिंग केवल उस बिंदु तक असीमित है कि आप संदेशों को कतारबद्ध करने के लिए स्थान से बाहर हो जाते हैं। उसके बाद आपके ऐप्स तुल्यकालिक हैं और उस स्थिति को गहन रूप से संभालना चाहिए, भले ही इसका मतलब है (गर्वपूर्वक) बंद करें।

Answer 2

ज़रूर!

http://download.oracle.com/docs/cd/E17802_01/products/products/jms/javadoc-102a/index.html Message#setJMSExpiration(long) वही करता है जो आप चाहते हैं।