एक धीमी ActiveMQ उपभोक्ता अन्य उपभोक्ताओं को धीमा होने के कारण

Question

मैं एक अजीब मुद्दे के बारे में मदद की तलाश में हूं जहां एक कतार में धीमी उपभोक्ता अन्य सभी उपभोक्ताओं को उसी कतार पर 30 सेकंड अंतराल पर संदेश लेने शुरू करने का कारण बनता है। यह सब उपभोक्ता है लेकिन धीमी गति से उपभोक्ता संदेश जितना तेज़ नहीं हो सकता है, इसके बजाय वे उपभोग करने से पहले कुछ जादुई 30s बाधा की प्रतीक्षा करते हैं।

अपने आवेदन के बुनियादी प्रवाह इस प्रकार है:

1. एक भी कतार पर उत्पादकों जगह संदेशों की एक संख्या। संदेश अलग JMSXGroupIDs
2. उपभोक्ताओं की एक संख्या है कि एक कतार
मानक अभ्यास के रूप में
3. JMSXGroupIDs कुछ बिंदु उपभोक्ताओं में से एक धीमी हो जाती है और संदेश संसाधित नहीं कर सकता पर उपभोक्ताओं
4. भर में वितरित पर संदेशों को सुन हो सकता है बहुत जल्दी
5. धीमी गति से उपभोक्ता दलाल पर इसके प्रीफ़ेच बफर भरने समाप्त होता है और AMQ स्वीकार करता है कि यह (डिफ़ॉल्ट व्यवहार) उस बिंदु पर
6. धीमी है - या कुछ 'यादृच्छिक' लेकिन पास समय बाद - धीमी छोड़कर सभी उपभोक्ताओं एक ही 30 के अंतराल पर संदेशों का उपभोग करने के लिए शुरू होता है
7. यदि धीमी गति से उपभोक्ता हो जाता है तेजी से फिर से फिर बातें बहुत जल्दी सामान्य ऑपरेशन करने के लिए वापस और 30 बाधा कृपया दूर

मैं क्या इस मुद्दे का कारण हो सकता के लिए एक नुकसान में हूँ, या यह कैसे तय करने के लिए, चला जाता है मदद।

अधिक पृष्ठभूमि और निष्कर्ष

• मैं, मज़बूती से AMQ 5.8.0, 5.9.0 (जहां इस मुद्दे को मूल रूप से देखा गया था) और 5.9.1 पर इस समस्या का पुन: पेश करने प्रबंधित किया है ताजा इंस्टॉल पर और मौजूदा ओप-प्रबंधित इंस्टॉल और विभिन्न मशीनों पर कुछ वीएम और कुछ नहीं। सभी लिनक्स इंस्टॉल, विभिन्न ओएस और जावा संस्करण।
• यह किसी भी prefetch से संबंधित प्रभावित नहीं होता है, यह है: prefetch मान को 1 से 10 से 1000 तक बदलना इस समस्या को
• [लाल हेरिंग?] पर डीबग लॉग सक्षम करना बंद नहीं करता है एमएमएसी उदाहरण उन संदेशों के आवधिक चेक से संबंधित लॉग दिखाता है जिन्हें समाप्त किया जा सकता है। कतार में कोई समाप्ति नीति नहीं है, इसलिए मैं केवल यह सोच सकता हूं कि निर्धारित expireMessagesPeriod समय बस इस तरह से बढ़ रहा है कि यह गैर धीमी उपभोक्ताओं को संदेश भेजता है।
• यदि 30s मोड दर्ज किया गया है तो बाएं फिर सेकंड में प्रवेश किया जाता है-पिछले-मिनट का समय हमेशा समान होता है, उदाहरण के लिए मिनट के 14 और 44 के दशक में। यह सभी उपभोक्ताओं और उन उपभोक्ताओं को होस्ट करने वाली सभी मशीनों में सच है। उन अवरोध बिंदु amq के पुनरारंभ के बाद बदलते हैं।

Answer 1

सख्ती से समस्या का समाधान नहीं होने पर, आगे की जांच ने इस मुद्दे के मूल कारण को उजागर कर दिया है।

टी एल; डॉ - यह व्यवहार में जाना जाता है और इससे पहले कि Apollo

अधिक जानकारी

अंततः इस maxPageSize संपत्ति और तथ्य यह है कि AMQ केवल चयन लागू होगी के कारण होता है तय नहीं की जाएगी स्मृति में संदेशों के मानदंड। आम तौर पर ये संदेश चयनकर्ता (property = value) हैं, लेकिन मेरे मामले में वे JMSXGroupID=>Consumer असाइनमेंट हैं।

चूंकि संदेश कतार द्वारा प्राप्त किए जाते हैं, इसलिए उन्हें स्मृति में पेज किया जाता है और एक संग्रह में रखा जाता है (स्रोत में pagedInPendingDispatch नामित)। संदेशों को प्रेषित करने के लिए एएमक्यू संदेशों की इस सूची के माध्यम से स्कैन करेगा और उपभोक्ता को खोजने का प्रयास करेगा जो इसे स्वीकार करेगा। इसमें समूह आईडी, संदेश चयनकर्ता और प्रीफेच बफर स्पेस की जांच शामिल है। हमारे उपयोग के मामले में हम संदेश चयनकर्ताओं का उपयोग नहीं कर रहे हैं लेकिन हम समूहों का उपयोग कर रहे हैं। यदि कोई उपभोक्ता संदेश नहीं ले सकता है तो यह संग्रह में छोड़ा गया है और अगले टिक में फिर से जांच की जाएगी।

pagedInPendingDispatch संग्रह को उपलब्ध सभी संसाधनों को खाने से संग्रह को रोकने के लिए maxPageSize संपत्ति के माध्यम से कॉन्फ़िगर इस कतार के आकार के लिए एक सुझाई गई सीमा है। यह संपत्ति वास्तव में अधिकतम नहीं है, यह एक संकेत है कि, सामान्य परिस्थितियों में, नए संदेश आगमन को स्मृति में या डिस्क पर पेजित किया जाना चाहिए।

जानकारी के इन दो टुकड़े और एक धीमी गति से उपभोक्ता यह पता चला है कि अंततः pagedInPendingDispatch संग्रह में सभी संदेशों को खत्म ही धीमी गति से उपभोक्ता द्वारा उपभोज्य किया जा रहा है, और इसलिए संग्रह प्रभावी रूप से अवरुद्ध हो जाता है और कोई अन्य संदेशों के साथ भेजा जाता है। यह बताता है कि धीमी उपभोक्ता 30 के अंतराल से क्यों प्रभावित नहीं हुआ था, इसमें maxPageSize संदेश पहले से ही वितरण की प्रतीक्षा कर रहे थे।

यह स्पष्ट नहीं करता है कि मैं हर 30 के दशक में गैर धीमी उपभोक्ताओं को संदेश क्यों प्राप्त कर रहा था। जैसा कि यह पता चला है, मेमोरी में संदेशों को पेजिंग में दो मोड हैं, सामान्य और मजबूर। आम तौर पर ऊपर उल्लिखित प्रक्रिया का पालन करता है जहां संग्रह के आकार की तुलना maxPageSize संपत्ति से की जाती है, जब मजबूर किया जाता है, हालांकि, संदेश हमेशा स्मृति में पजे हुए होते हैं। यह मोड आपको उन संदेशों के माध्यम से ब्राउज़ करने की अनुमति देता है जो स्मृति में नहीं हैं। जैसा कि ऐसा होता है, इस मजबूर मोड का उपयोग समाप्ति तंत्र द्वारा भी किया जाता है ताकि एएमक्यू को उन संदेशों को समाप्त करने की अनुमति मिल सके जो स्मृति में नहीं हैं।

तो अब हमारे पास स्मृति में संदेशों का संग्रह है जो सभी एक ही उपभोक्ता को प्रेषित करने के लिए लक्षित हैं, एक उपभोक्ता जो उन्हें स्वीकार नहीं करेगा क्योंकि यह धीमा या अवरुद्ध है। हमारे पास सभी उपभोक्ताओं को डिलीवरी का इंतजार करने वाले संदेशों का बैकलॉग भी है। प्रत्येक expireMessagesPeriod मिलीसेकंड एक कार्य चलाता है जो पृष्ठ पृष्ठों को मेमोरी में संदेश भेजता है ताकि यह जांच सके कि उन्हें समाप्त हो जाना चाहिए या नहीं। यह उन संदेशों को संग्रह में पृष्ठों पर जोड़ता है जिनमें धीमे उपभोक्ता और N किसी भी उपभोक्ता के लिए निर्धारित संदेशों के लिए maxPageSize संदेश शामिल हैं। वे संदेश वितरित हो जाते हैं।

QED।

संदर्भ

• Ticket referring to this issue but for message selectors instead
• Docs relating to the configuration properties
• Somebody else with this issue but for selectors