Magento 1.9.1 ईमेल कतार काम नहीं कर रही है / छोटी गाड़ी - कैसे समस्या निवारण और सबसे अच्छा पैच माना जाता है?

Question

सबसे पहले हां, यह 1.9.1 ईमेल कतार के बारे में एक और सवाल / विषय है। लेकिन यह किसी भी क्रॉन समस्याओं के बारे में नहीं है (जैसे कि यह या यह ) या नई कतार की सुविधा के बारे में नहीं है (जैसे यह )।

हमारे मामले में हमें समस्या थी, कि कतार ( core_email_queueऔर core_email_queue_recipients) को नए ऑर्डर या ऑर्डर अपडेट पर कोई ईमेल नहीं मिलेगा और इसलिए कोई भी ईमेल संबंधित आदेश के लिए बाहर नहीं भेजा गया, क्रोन भी पूरी तरह से काम कर रहा है और मैन्युअल रूप से ईमेल जोड़ रहा है कतार काम करती है और वे बाहर भेजे जाते हैं।

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

जैसा कि हम इस समस्या का पता नहीं लगा सकते थे, लेकिन फिर से काम करने के लिए ईमेल की जरूरत थी ताकि हम एक और कोर ओवरराइड के लिए गए। में Mage_Core_Model_Email_Template_Mailer(निश्चित रूप से एक प्रति में local) हमने लाइन 76 पर टिप्पणी की: ->setQueue($this->getQueue())
यह कतार को बायपास करने के लिए लगता है और सभी मेलों को फिर से पुराने तरीके से भेजा जाता है।

हालाँकि, जैसा कि हम चाहते हैं कि कोर ओवरराइड्स की संख्या न्यूनतम रखी जाए और हम अभी यह भी नहीं बता सकते हैं कि क्या हम किसी अन्य दुष्प्रभावों, मैग्नेटो कोड और गहरी समझ वाले लोगों के किसी अन्य सुझाव या समाधान का सामना करेंगे। ईमेल कतार की सराहना की जाएगी।

1.9.2 के लिए अद्यतन: 1.9.2 के उन्नयन पर हमें ई-मेल कतार में फिर से करीब से देखा और समस्या को पुन: उत्पन्न करने में सक्षम नहीं थे। लेकिन जैसा कि हमारे पास अभी भी कोई वास्तविक सुराग नहीं है कि 1.9.1 के साथ समस्या क्या थी और जैसा कि ओवरराइडिंग Mage_Core_Model_Email_Template_Mailer::send()अभी भी यहां वर्णित तरीके से काम करता है हम अभी भी कतार का उपयोग नहीं कर रहे हैं। इस तरह हम उम्मीद करते हैं कि उत्पादन में कुछ समय बाद फिर से उसी समस्या में नहीं चलेंगे।

tl; dr: ईमेल कतार 1.9.1 में काम नहीं कर रही है Mage_Core_Model_Email_Template_Mailer। ईमेल कतार और डाक को बायपास करने में लाइन 76 पर टिप्पणी करते हुए फिर से भेजा जाता है लेकिन यह एक अच्छा समाधान नहीं लगता है। इसे बेहतर तरीके से कैसे हल किया जा सकता है?

Comments

पहले कुछ ही मिनटों के दौरान आपके द्वारा कितने लाइव लेन-देन की तुलना में आपने कितने परीक्षण लेनदेन चलाए? क्या यह पुराने संस्करण से अपग्रेड था और कुछ फाइलें गायब हैं या अनुचित अनुमति हैं? कैसे exception.logया संभवत system.log:, वहाँ कोई सुराग है?

— pspahn 2

यह 1.9.0.1 से एक अपग्रेड था और इसे कनेक्ट-मैनेजर के माध्यम से नहीं किया गया था, लेकिन मैगेंटो कोड बेस से इसलिए मुझे संदेह है कि हमारे पास फाइलें गायब हैं (हम भी coreअलग हैं जो सब कुछ सुनिश्चित करने के लिए है जो कि अनुकूलित या विस्तार नहीं है और unmodified और यह है)। अनुमतियाँ पुराने सेट अप से मेल खाती हैं और लॉग / रिपोर्ट साफ हैं।

— Jey DWork

क्या क्रोन समान है?

— pspahn

जैसा कि हमने परिवर्तन लॉग में ईमेल परिवर्तन को देखा, हमने हर 5 मिनट पहले से हर मिनट चलाने के लिए क्रोन को बदल दिया (जैसा कि हम परिवर्तन को समझते हैं ताकि अन्यथा सबसे खराब स्थिति में ग्राहकों को उनके पुष्टिकरण मेल के लिए 5 मिनट तक इंतजार करना पड़े)। इसके अलावा कोई बदलाव नहीं है और जैसा कि पहले कहा गया था और हम अन्य नौकरियों से देखते हैं क्रॉन बिना किसी समस्या के चलता है। // संपादित करें: मुझे संभवतः यह जोड़ना चाहिए कि हम (और हमेशा इस्तेमाल किए जाने वाले) Aoe_Scheduler का उपयोग करते हैं जहां हम core_email_queue_send_allहर मिनट भी चलाते हैं और जहां से हम देखते हैं कि यह वास्तव में निष्पादित होता है।

— Jey DWork

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

— रिक बुक्जेंस्की

Answer 1

मेरा अनुमान है कि हर मिनट चलने के लिए cron.php की स्थापना से बहुत सारी चीजें एक-दूसरे के ऊपर खड़ी हो जाती हैं, यानी अगले कार्य को उसी प्रकृति या इसी तरह निष्पादित होने से पहले पूरा नहीं किया जाता है। चूंकि दोनों cron.php प्रत्येक राज्य के बारे में नहीं जानते होंगे। एक ही रिकॉर्ड दो बार प्रयास किया जा सकता है, जिससे कुछ विषम अपवाद कतार ईमेल भेजता है।

इसके साथ ही कहा कि Mage::Logक्यू मेलर के अपवाद हैं, इसलिए यह सुनिश्चित करना कि लॉगिंग सक्षम है किसी भी अपवाद को निर्धारित करने में मदद करने के लिए सबसे अच्छा कदम होगा। यह समझदारी भी हो सकती है कि php -f cron.phpसीएलआई से केवल यह देखने के लिए कि क्या यह किसी अपवाद को भी फेंक रहा है, आप इसे दृश्यों के पीछे भागते हुए नहीं देख सकते हैं।

• https://github.com/OpenMage/magento-mirror/blob/magento-1.9/app/code/core/Mage/Core/Model/Email/Queue.php#L246

मैं यह भी mail()सुनिश्चित करने के लिए एक सरल PHP परीक्षण के साथ शुरू करूँगा कि आप किसी भी स्पैम नीतियों या इस तरह से नहीं चल रहे हैं। बस यह सुनिश्चित करने के लिए कि समस्या के कारण स्टैक में कुछ कम नहीं है।

• Magento के ई-मेल भेजने से काम नहीं चलता

बस कुछ अटकलें, आशा है कि यह मदद करता है!

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

cron.shइसके बजाय उपयोग करें cron.phpक्योंकि यह grep psदेखने के लिए करेगा कि क्या पिछली प्रक्रिया पहले से चल रही है।

• https://github.com/OpenMage/magento-mirror/blob/magento-1.9/cron.sh#L46

Comments

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

— Jey DWork

आप यह देखने के लिए डेवलपर मोड को आज़माने और सक्षम करने का प्रयास कर सकते हैं कि क्या यह किसी अपवाद को लॉग इन नहीं होने में मदद करता है। हालांकि इसके उत्पादन में चल रहा है, लेकिन इसके बारे में सतर्क रहें। भी किसी भी सहसंबंधी वेब सर्वर लॉग?

— B00MER

@JeyDWork ने क्या आपने Aoe_Scheduler को लागू किया है ? यह अच्छी दृश्यता दे सकता है।

— बॉनमार्क

एक अद्यतन देखना चाहते हैं। ईमेल कतार कई लोगों के लिए एक चुनौती साबित हो रही है।

— 16

मेरे लिए मैं paypal मानक का उपयोग कर रहा था जिसे भुगतान की पुष्टि करने के लिए paypal से IPN (झटपट भुगतान अधिसूचना) डेटा रिटर्न की आवश्यकता थी, सफलता थी और ऑर्डर की स्थिति को प्रसंस्करण / पूर्ण करने और अंत में ईमेल भेजने के लिए बदल दिया था .. लेकिन मेरे पास वास्तविक डोमेन सेट अप नहीं था मेरे सर्वर और vhosts तक पहुँचने के लिए यही कारण था कि पेपल आईपीएन डेटा को मैगनेटो में पोस्ट नहीं कर सकता था। आप पेपैल व्यापार खाता प्रोफ़ाइल में आईपीएन इतिहास की जांच कर सकते हैं। पेपैल ने वास्तव में डेटा को बाहर भेजने के लिए मान लिया था और स्थिति "पुनः प्रयास कर रही थी" ..

— zaw

Answer 2

जांचें कि क्या core_email_queue और core_email_queue_recipients में AUTO_INCREMENT है। यदि उन तालिका में AI सक्षम नहीं है तो यह नई प्रविष्टियां नहीं लेगा।