मैं इसे हटाए बिना किसी वेबस्पेयर एमक्यू संदेश को कैसे ब्राउज़ करूं?

Question

मैं एक .NET विंडोज फॉर्म एप्लिकेशन लिख रहा हूं जो एक वेबस्पेयर एमक्यू कतार में एक संदेश पोस्ट करेगा और फिर प्रतिक्रिया के लिए एक अलग कतार मतदान करेगा। यदि कोई प्रतिक्रिया वापस आती है, तो आवेदन वास्तविक समय में प्रतिक्रिया को आंशिक रूप से संसाधित करेगा। लेकिन प्रतिक्रिया को कतार में रहने की जरूरत है ताकि एक दैनिक बैच नौकरी, जो प्रतिक्रिया कतार से भी पढ़ती है, शेष प्रक्रिया कर सकती है।

मुझे संदेश पढ़ने के लिए मिल गया है। जो मैं समझ नहीं पा रहा हूं वह इसे हटाने के बिना इसे कैसे पढ़ा जाए।

यहां तक ​​कि मुझे अब तक क्या मिला है। मैं एक एमक्यू नौसिखिया हूँ, इसलिए किसी भी सुझाव की सराहना की जाएगी। और सी # में जवाब देने के लिए स्वतंत्र महसूस करें।

Public Function GetMessage(ByVal msgID As String) As MQMessage 
    Dim q = ConnectToResponseQueue() 
    Dim msg As New MQMessage() 
    Dim getOpts As New MQGetMessageOptions() 
    Dim runThru = Now.AddMilliseconds(CInt(ConfigurationManager.AppSettings("responseTimeoutMS"))) 
    System.Threading.Thread.Sleep(1000) 'Wait for one second before checking for the first response' 
    While True 
     Try 
      q.Get(msg, getOpts) 
      Return msg 
     Catch ex As MQException When ex.Reason = MQC.MQRC_NO_MSG_AVAILABLE 
      If Now > runThru Then Throw ex 
      System.Threading.Thread.Sleep(3000) 
     Finally 
      q.Close() 
     End Try 
    End While 
    Return Nothing 'Should never reach here' 
End Function 

नोट: मैं सत्यापित नहीं किया है कि मेरे कोड वास्तव में संदेश को हटा। लेकिन इस तरह मैं काम करने के लिए एमक्यू को समझता हूं, और ऐसा लगता है कि क्या हो रहा है। कृपया मुझे सही करें यदि यह डिफ़ॉल्ट व्यवहार नहीं है।

Answer 1

आपको MQOO_BROWSE विकल्प के साथ कतार खोलने की आवश्यकता है। फिर अपने पहले पढ़ने पर आप MQGMO_BROWSE_FIRST विकल्प का उपयोग करके एक GET करते हैं। अंत में, आपके बाद के जीईटी को MQGMO_BROWSE_NEXT विकल्प का उपयोग करना चाहिए।

नोट: एमक्यूओ एमक्यू ओपन विकल्प है और एमक्यूजीएमओ एमक्यू संदेश विकल्प प्राप्त करें।

Answer 2

आपको वास्तव में अलग-अलग कतारों के साथ ऐसा करना चाहिए। दिन प्रसंस्करण के अंत में अपनी खुद की कतार होना चाहिए। संदेश के अपने हिस्से को संसाधित करने के बाद, आप इसे ईओडी कतार में भेजते हैं।

ब्राउज़ विकल्प के साथ आपको यह पता चलाना होगा कि आप किस संदेश को पहले ही संसाधित कर चुके हैं।

इसके अलावा, आप जीईटी पर प्रतीक्षा समय निर्धारित कर सकते हैं। तो आपको कतार की जांच करने से पहले 1 सेकंड प्रतीक्षा करने की आवश्यकता नहीं है "। जैसा कि अभी लिखा गया है, आप कोई संदेश उपलब्ध नहीं कर सकते हैं क्योंकि आपने संदेश संदेश में NOWAIT सेट नहीं किया है।

Answer 3

वंशावली के लिए, यहां एक (मुझे लगता है) मम्बोकिंग और jmucchiello के उत्तरों के आधार पर विधि का एक बेहतर संस्करण है।

Public Function GetMessage(ByVal correlID As Byte()) As MQMessage 
    Dim waitInterval = CInt(ConfigurationManager.AppSettings("responseTimeoutMS")) 
    Dim q As MQQueue = Nothing 
    Try 
     Dim msg As New MQMessage() 
     Dim getOpts As New MQGetMessageOptions() 
     q = ConnectToResponseQueue() 
     msg.MessageId = MQC.MQMI_NONE 
     msg.CorrelationId = correlID 
     getOpts.MatchOptions = MQC.MQMO_MATCH_CORREL_ID 
     getOpts.WaitInterval = waitInterval 
     getOpts.Options = MQC.MQGMO_BROWSE_FIRST Or MQC.MQGMO_WAIT 
     q.Get(msg, getOpts) 
     Return msg 
    Finally 
     If q IsNot Nothing AndAlso q.IsOpen() Then q.Close() 
    End Try 
End Function 

Answer 4

मुझे एहसास है कि मैं इस चर्चा में थोड़ा देर से आ रहा हूं और आप शायद पहले से ही इस ऐप को कोड कर चुके हैं। यदि आपको कभी भी इसे संशोधित करने की आवश्यकता होती है या किसी और के लिए जो कुछ ऐसा करने की आवश्यकता हो सकती है, तो मेरे पास कुछ अवलोकन हैं।

सबसे पहले, यदि आप इसे v7 QMgr और v7 WMQ क्लाइंट के साथ कर सकते हैं तो यह पसंदीदा समाधान होगा। V7 में, .NET समर्थन को समर्थन उत्पाद से बेस उत्पाद के हिस्से में स्थानांतरित कर दिया गया है। काफी नई कार्यक्षमता है, कुछ बग फिक्स और बेहतर प्रदर्शन है। इसके अलावा, v7 पर आप पब-सब का उपयोग कर सकते हैं ... जो मुझे मेरे दूसरे अवलोकन में लाता है।

मूल पोस्ट में विवरण के आधार पर, मैंने इसे पब-सब में किया होगा। ऐप जो संदेश को रखता है केवल एक को रखता है और इसे किसी विषय पर डालने की भी आवश्यकता नहीं होती है। आप वास्तव में किसी विषय पर उपनाम डाल सकते हैं जो इसे संदेश निर्माता को कतार की तरह दिखता है। आपके उपभोक्ता ऐप्स या तो सब्सक्राइब कर सकते हैं या आप दो प्रशासनिक सदस्यता बना सकते हैं ताकि प्रकाशित संदेश आपके द्वारा निर्दिष्ट दो कतारों पर जा सकें। आपके ऐप्स में प्रत्येक के पास एक समर्पित कतार है और निर्माता और बैच ऐप के लिए कोई कोडिंग परिवर्तन शामिल नहीं है, यह केवल कॉन्फ़िगरेशन है। बेशक लेनदेन को चलाने वाले ऐप को वास्तव में उन्हें ब्राउज़ करने के बजाय संदेशों का उपभोग करने की आवश्यकता होगी।

यहाँ फायदे कई हैं: कतार संदेशों से भर

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

यहां कुछ पूरी तरह से अलग-अलग मुद्दे भी हैं। इनमें से एक क्विज़िंग विकल्प अगर विफलता का उपयोग करना है। इसका उद्देश्य यह है कि जब QMgr साफ़ रूप से बंद हो जाता है तो यह विकल्प आपके एपीआई कॉल को रिटर्न कोड के साथ समाप्त करने का कारण बनता है जो कि QMgr बंद हो रहा है। यदि आप इस विकल्प को शामिल नहीं करते हैं तो दो या अधिक कनेक्टेड ऐप्स के साथ यह संभव है कि QMgr कभी भी साफ़ रूप से बंद न हो और मजबूर होना चाहिए या इसकी प्रक्रियाओं को ब्रूट फोर्स के साथ मार डालना चाहिए। एक नियम के रूप में, अगर समर्थन करते हैं तो सभी एपीआई कॉल पर क्विज़िंग करते समय हमेशा विफलता का उपयोग करें। इसका कारण यह है कि उन लोगों के लिए जो XA लेनदेन की आवश्यकता रखते हैं लेकिन किसी कारण से इसका उपयोग नहीं कर सकते हैं। इस परिदृश्य में, कनेक्टेड और पहला जीईटी या पुट कॉल विफलता का उपयोग करता है अगर क्विज़िंग सेट और उसके बाद जीईटी या पीयूटी ऑपरेशंस नहीं होते हैं। यह QMgr को पूरा करने के लिए GET/PUT कॉल के पूरे सेट की प्रतीक्षा करने का कारण बनता है, लेकिन फिर अगला कनेक्ट या GET/PUT विफल होने पर विफलता का उपयोग करता है ताकि QMgr को आवश्यक होने पर बंद करने का मौका मिले।

अन्य अवलोकन यहां है कि यहां कोड में कोई पकड़ नहीं है। मुझे लगता है कि कॉल स्टैक आगे बढ़ने के लिए एक है? हमेशा एक अपवाद से डब्लूएमक्यू रिटर्न कोड मुद्रित करने की सलाह दी जाती है ताकि आप मूल कारण को ट्रैक कर सकें। परामर्श संलग्नियों पर मैं हमेशा ग्राहकों को सलाह देता हूं कि रिटर्न कोड (या जेएमएस/एक्सएमएस कोड के लिए लिंक अपवाद) मुद्रित करने में विफलता एक शोस्टॉपर है जो किसी ऐप को उत्पादन में प्रचार को रोकना चाहिए। यह वास्तव में महत्वपूर्ण है। भले ही आपके पास कोड में कैच है जो getMessage() को कॉल करता है, यहां तक ​​कि उदाहरण कोड स्निपेट का पुन: उपयोग करने वाला कोई व्यक्ति यह महसूस नहीं कर सकता कि यह महत्वपूर्ण टुकड़ा गुम है।