2015-05-28 10 views
5

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

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

समस्या यह है कि एमक्यू पर 10,000+ दैनिक रिकॉर्डों में से केवल 700 या उससे अधिक (सटीक संख्या प्रत्येक बार अलग होती है) आमतौर पर आइटमप्रोसेसर में लॉग इन होती है। सभी रिकॉर्ड सफलतापूर्वक कतार से खींचा जाता है। लॉग इन रिकॉर्ड्स की संख्या हर बार अलग होती है और ऐसा लगता है कि कोई पैटर्न नहीं है। एमक्यू में रिकॉर्ड्स की सूची के खिलाफ लॉग फाइलों की तुलना करके, हम देख सकते हैं कि रिकॉर्ड के प्रतीत होता है कि यादृच्छिक सबसेट हमारे काम से "संसाधित" हो रहा है। पहला रिकॉर्ड उठाया जा सकता है, फिर 50 छोड़ दिए जाते हैं, फिर 5 पंक्ति में इत्यादि। और जब भी नौकरी चलती है तो पैटर्न अलग होता है। कोई अपवाद लॉग इन नहीं है।

स्थानीयहोस्ट में एक ही ऐप चलाते समय और उसी डेटा सेट का उपयोग करके परीक्षण करते समय, सभी 10,000+ रिकॉर्ड सफलतापूर्वक पुनर्प्राप्त और आइटमप्रोसेसर द्वारा लॉग इन किए जाते हैं। यह काम उत्पादन में 20 से 40 सेकेंड के बीच चलता है (स्थिर भी नहीं), लेकिन परीक्षण और स्थानीय में इसे पूरा करने में कई मिनट लगते हैं (जो स्पष्ट रूप से समझ में आता है क्योंकि यह बहुत अधिक रिकॉर्ड प्रबंधित कर रहा है)।

तो यह समस्या निवारण के लिए उन कठिन मुद्दों में से एक है क्योंकि हम इसे फिर से नहीं बना सकते हैं। सब अब हम जानते हैं यह है कि केवल रिकॉर्ड के सबसेट ItemProcessor द्वारा नियंत्रित किया जा रहा है - एक विचार हमारे अपने ItemReader को लागू करने और अतिरिक्त लॉगिंग जोड़ने अगर रिकॉर्ड पाठक से पहले या पाठक के बाद खो रहा है कर रहे हैं ताकि हम देख सकते हैं करने के लिए है। लेकिन यहां तक ​​कि इससे हमारी समस्या का समाधान नहीं होगा, और यह लागू करने के लिए कुछ हद तक समय पर होगा क्योंकि यह समाधान भी नहीं है।

क्या किसी और ने इस तरह कोई मुद्दा देखा है? किसी भी संभावित विचार या समस्या निवारण सुझावों की बहुत सराहना की जाएगी। यहां कुछ जार संस्करण संख्याएं हैं जिनका हम संदर्भ के लिए उपयोग कर रहे हैं।

  • स्प्रिंग - 3.0.5.RELEASE
  • स्प्रिंग एकता - 2.0.3.RELEASE
  • वसंत बैच - 2.1.7.RELEASE
  • सक्रिय MQ - 5.4.2
  • Websphere MQ - 7.0.1

आपके इनपुट के लिए अग्रिम धन्यवाद।

संपादित करें:

public SMSReminderRow process(Message message) throws Exception { 

    SMSReminderRow retVal = new SMSReminderRow(); 
    LOGGER.debug("Converting JMS Message to ClaimNotification"); 
    ClaimNotification notification = createClaimNotificationFromMessage(message); 

    retVal.setShortCode(BatchCommonUtils 
      .parseShortCodeFromCorpEntCode(notification.getCorpEntCode())); 
    retVal.setUuid(UUID.randomUUID().toString()); 
    retVal.setPhoneNumber(notification.getPhoneNumber()); 
    retVal.setMessageType(EventCode.SMS_CLAIMS_NOTIFY.toString()); 

    DCRContent content = tsContentHelper.getTSContent(Calendar 
      .getInstance().getTime(), 
      BatchCommonConstants.TS_TAG_CLAIMS_NOTIFY, 
      BatchCommonConstants.TS_TAG_SMSTEXT_TYP); 

    String claimsNotificationMessage = formatMessageToSend(content.getContent(), 
      notification.getCorpEntCode()); 

    retVal.setMessageToSend(claimsNotificationMessage); 
    retVal.setDateTimeToSend(TimeUtils 
      .getGMTDateTimeStringForDate(new Date())); 

    LOGGER.debug(
      "Finished processing claim notification for {}. Writing row to file.", 
      notification.getPhoneNumber()); 
    return retVal; 
} 

JMS config: अनुरोध, प्रोसेसर के लिए कोड प्रति

<?xml version="1.0" encoding="UTF-8"?> 
<beans xmlns="http://www.springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:context="http://www.springframework.org/schema/context" 
xmlns:tx="http://www.springframework.org/schema/tx" 
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd 
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd 
    http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd"> 
<bean id="claimsQueueConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean"> 
    <property name="jndiName" value="jms/SMSClaimNotificationCF" /> 
    <property name="lookupOnStartup" value="true" /> 
    <property name="cache" value="true" /> 
    <property name="proxyInterface" value="javax.jms.ConnectionFactory" /> 
</bean> 

<bean id="jmsDestinationResolver" 
    class="org.springframework.jms.support.destination.DynamicDestinationResolver"> 
</bean> 

<bean id="jmsJndiDestResolver" 
    class=" org.springframework.jms.support.destination.JndiDestinationResolver"/> 

<bean id="claimsJmsTemplate" class="org.springframework.jms.core.JmsTemplate"> 
    <property name="connectionFactory" ref="claimsQueueConnectionFactory" /> 
    <property name="defaultDestinationName" value="jms/SMSClaimNotificationQueue" /> 
    <property name="destinationResolver" ref="jmsJndiDestResolver" /> 
    <property name="pubSubDomain"> 
     <value>false</value> 
    </property> 
    <property name="receiveTimeout"> 
     <value>20000</value> 
    </property> 
</bean> 

+0

मुझे लगता है कि कोई भी आपकी मदद कर सकता है इससे पहले कि आपको कम से कम पुनरुत्पादित नमूना की आवश्यकता हो। इसके अलावा यह सब सिर्फ अनुमान है: कहीं अपवाद होना चाहिए या एक लॉग फ़ाइल जो अधिक जानकारी देगी। क्या वहां धागे हैं जो बार्फ़िंग कर रहे हैं, या क्या आपके पास ऑब्जेक्ट्स के वीक रेफरेंस हैं जो कचरा जा रहे हैं? मैं जीसी की तुलना "स्किप" के साथ कर सकता हूं ताकि यह देखने के लिए कि ऑब्जेक्ट्स को अपना काम पूरा करने से पहले एकत्र किया जा रहा है (विश्वास करना मुश्किल है कि यह मामला होगा लेकिन एक लायक है)। क्या आप उत्पादन में नेटवर्क या अन्य टाइमआउट के खिलाफ चल रहे हैं? – mttdbrd

+0

इनपुट @mttdbrd के लिए धन्यवाद। मुझे पता है कि यह अंधेरे में एक शॉट है, लेकिन हमारे पास जाने के लिए बहुत अधिक जानकारी नहीं है। मैं उम्मीद कर रहा था कि किसी ने पहले समान व्यवहार देखा होगा और मुझे सही दिशा में इंगित कर सकता है। हमारा सबसे अच्छा अनुमान वेबस्पेयर, स्प्रिंग बैच और/या एमक्यू के बीच कुछ प्रकार की संगतता समस्या है। अब तक हमें हमारे किसी भी उत्पादन लॉग में किसी भी प्रकार के अपवाद या त्रुटियां नहीं मिली हैं, लेकिन कचरा संग्रह के साथ समस्याओं के किसी भी संकेत के लिए मैं कुछ अतिरिक्त शोध करूँगा। उत्पादन में टाइमआउट का कोई संकेत नहीं है। –

+0

क्या आप अपनी वसंत बैच कॉन्फ़िगरेशन और प्रोसेसर को – Palcente

उत्तर

1

http://activemq.apache.org/jmstemplate-gotchas.html देखें।

जेएमएसटीप्लेट का उपयोग करने में समस्याएं हैं। जब मैंने अपने हार्डवेयर को अपग्रेड किया और अचानक एक पूर्व-मौजूदा दौड़ की स्थिति का खुलासा किया तो मैं केवल इन मुद्दों में भाग गया।

संक्षिप्त रूप यह है कि डिजाइन और इरादे से जेएमएस टेम्पलेट खुलता है और प्रत्येक Invocaton पर कनेक्शन बंद कर देता है। यह इसके निर्माण से पुराने संदेश नहीं देखेगा। उच्च मात्रा और/या उच्च थ्रूपुट परिदृश्य में, यह कुछ संदेशों को पढ़ने में विफल रहेगा।

+0

हमारी टीम के एक अन्य डेवलपर ने इसे परीक्षण और त्रुटि के माध्यम से समझ लिया - लेकिन यह वही है जो उसे इस मुद्दे को भी मिला। मैंने इसे समाधान के रूप में चिह्नित किया क्योंकि आपने कुछ अतिरिक्त विवरणों के साथ एक उपयोगी लिंक प्रदान किया था। –

2

एक नियम के रूप में, MQ संदेशों जब ठीक से विन्यस्त नहीं खो देंगे। प्रश्न तब "ठीक से कॉन्फ़िगर" जैसा दिखता है?

आम तौर पर, खो गए संदेशों गैर हठ या गैर लेन-देन हो जाता है के कारण होता है।

यदि गैर-लगातार संदेश QMgr-to-QMgr चैनलों को घुमा रहे हैं और NPMSPEED(FAST) सेट है तो एमक्यू खो जाने पर त्रुटियों को लॉग नहीं करेगा। यही वह विकल्प है जिसका उपयोग करने के लिए किया जाना चाहिए ताकि कोई त्रुटि अपेक्षित न हो।

फिक्स: QMgr-to-QMgr चैनल पर NPMSPEED(NORMAL) सेट करें या संदेश लगातार बनाए रखें।

यदि ग्राहक सिंकपॉइंट के बाहर संदेश प्राप्त कर रहा है, तो संदेश खो जा सकते हैं। यह विशेष रूप से एमक्यू के साथ कुछ भी नहीं है, यह सामान्य कामों में मैसेजिंग है। यदि आप कतार से विनाशकारी संदेश प्राप्त करने के लिए एमक्यू को बताते हैं और यह उस संदेश को रिमोट एप्लिकेशन पर वितरित नहीं कर सकता है तो एमक्यू को वापस रोल करने का एकमात्र तरीका यह है कि अगर संदेश सिंकपॉइंट के तहत पुनर्प्राप्त किया गया था।

फिक्स: एक ट्रांज़ेक्टेड सत्र का उपयोग करें।

अनुभव से बाहर कुछ अतिरिक्त नोट्स हैं।

  • हर कोई संदेश दृढ़ता से शपथ लेता है कि वह क्या सोचता है। लेकिन जब मैं एप्लिकेशन को रोकता हूं और मैन्युअल रूप से संदेशों का निरीक्षण करता हूं तो बहुत अक्सर अपेक्षा की जाती है। यह सत्यापित करना आसान है इसलिए मान लें।
  • यदि कोई संदेश कतार पर वापस घुमाया जाता है, तो यह तब तक नहीं होगा जब तक अनाथ चैनल से एमक्यू या टीसीपी बार नहीं हो जाता है, यह 2 घंटे तक हो सकता है ताकि चैनल कोम और टीसीपी कोटाइव को कम करने के लिए इसे ट्यून किया जा सके।
  • वापस रोलिंग लेनदेन के बारे में संदेशों को देखने के लिए एमक्यू के त्रुटि लॉग (QMgr पर क्लाइंट नहीं) की जांच करें।
  • यदि आप अभी भी यह निर्धारित नहीं कर सकते कि संदेश कहां जा रहे हैं, तो SupportPac MA0W के साथ ट्रेसिंग करने का प्रयास करें। यह निशान एक निकास के रूप में चलता है और यह अत्यंत कॉन्फ़िगर करने योग्य है। आप एक ही कतार और केवल उस कतार पर सभी GET संचालन का पता लगा सकते हैं। आउटपुट मानव-पठनीय रूप में है।
+0

मुझे इन सुझावों की समीक्षा करने के लिए हमारे एमक्यू लड़के से पूछना होगा टी। रोब। वर्तमान में सभी रिकॉर्ड एमक्यू से वितरित एमक्यू में स्थानांतरित किए जाते हैं, जहां हम रिकॉर्ड्स खींचते हैं। –

संबंधित मुद्दे