क्वार्ट्ज और वसंत - क्लस्टर्ड लेकिन लगातार नहीं?

Question

मेरे वसंत आवेदन में मैं क्वार्ट्ज के साथ एकीकृत करने के लिए SchedulerFactoryBean का उपयोग कर रहा हूं। हम टॉमकैट उदाहरणों को क्लस्टर करने जा रहे हैं, और इस प्रकार मैं क्लस्टर्ड क्वार्ट्ज पर्यावरण चाहता हूं, ताकि एक ही नौकरियां अलग-अलग वेब सर्वरों पर एक ही समय में न चलें।

यह मेरा app-context.xml इस प्रकार है करने के लिए,:

<bean class="org.springframework.scheduling.quartz.SchedulerFactoryBean"> 
    <property name="triggers"> 
     <list> 
      <ref bean="cronTrigger"/> 
      <ref bean="simpleTrigger" /> 
     </list> 
    </property> 
    <property name="dataSource" ref="dataSource"/> 
    <property name="overwriteExistingJobs" value="true"/> 
    <!-- found in applicationContext-data.xml --> 
    <property name="applicationContextSchedulerContextKey" value="applicationContext"/> 
    <property name="quartzProperties"> 
     <props> 
      <prop key="org.quartz.scheduler.instanceName">SomeBatchScheduler</prop> 
      <prop key="org.quartz.scheduler.instanceId">AUTO</prop> 
      <prop key="org.quartz.jobStore.misfireThreshold">60000</prop> 
      <!--<prop key="org.quartz.jobStore.class">org.quartz.simpl.RAMJobStore</prop>--> 
      <prop key="org.quartz.jobStore.class">org.quartz.impl.jdbcjobstore.JobStoreTX</prop> 
      <prop key="org.quartz.jobStore.driverDelegateClass">org.quartz.impl.jdbcjobstore.StdJDBCDelegate</prop> 
      <prop key="org.quartz.jobStore.tablePrefix">QRTZ_</prop> 
      <prop key="org.quartz.jobStore.isClustered">true</prop> 
      <prop key="org.quartz.threadPool.class">org.quartz.simpl.SimpleThreadPool</prop> 
      <prop key="org.quartz.threadPool.threadCount">25</prop> 
      <prop key="org.quartz.threadPool.threadPriority">5</prop> 
     </props> 
    </property> 
</bean> 

सब कुछ अच्छी तरह से काम करता है, सिवाय इसके कि जब मैं एक ट्रिगर हटाने या बदलने के लिए, तो मेरे एप्लिकेशन को पुनः प्रारंभ करने का प्रयास, पुराने चलाता अभी भी कायम कर रहे हैं डीबी, और अभी भी भागो। मुझे यह नहीं चाहिए, मैं बस उन्हें हटाना चाहता हूं जब ऐप बंद हो जाता है (या फिर से शुरू किया जाता है)। मैंने overwriteExistingJobs संपत्ति का मान सही होने के लिए सेट किया है, क्योंकि मैंने सोचा था कि यह वही है।

कोई विचार? मैं डीबी का उपयोग क्लस्टरिंग के लिए करना चाहता हूं, इससे परे किसी भी प्रकार की दृढ़ता नहीं।

Answer 1

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

Answer 2

यह एक पुरानी पोस्ट है, लेकिन उन लोगों के लाभ के लिए जिन्हें समाधान की आवश्यकता है, यहां यह है। संपत्ति "overwriteExistingJobs" के लिए "सत्य" निर्दिष्ट करें। आपको अपने सर्वर को पुनरारंभ करना होगा और हर बार जब आप पुनरारंभ करेंगे, पुरानी नौकरियां हटा दी जाएंगी। मुझे नहीं पता कि यह क्वार्ट्ज-शेड्यूलर के पुराने संस्करणों में संभव था, मैं 2.1.7

Answer 3

क्लस्टर क्वार्ट्ज 2 के साथ एक समान समस्या में भाग गया। मैं ऊंट नहीं चला रहा था, लेकिन यह वही समस्या है।

1) वसंत संदर्भ xml से नौकरियों/ट्रिगर्स को हटाकर मैंने क्लस्टर्ड वातावरण में नौकरियों को हटाने का कोई तरीका नहीं देखा है।

2) क्योंकि डेटाबेस नौकरी/ट्रिगर जानकारी संग्रहीत करता है, यदि आप नौकरियां जोड़ रहे हैं या संशोधित कर रहे हैं तो सर्वर पर रोलिंग तैनाती समस्याग्रस्त हो जाती है। जब तक आप अपने परिवर्तनों को तैनात करने से पहले सभी सर्वरों को नीचे नहीं ले लेते हैं, तब तक सर्वर ऐप सर्वर पर नौकरी कार्यान्वयन को तैनात करने से पहले नौकरियां चलाने शुरू कर सकते हैं।

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