Magento 1.9.1 Email Queue ไม่ทำงาน / บั๊กกี้ - วิธีแก้ปัญหาและแพทช์ที่ดีที่สุดคืออะไร?


35

ก่อนอื่นใช่นี่เป็นคำถาม / หัวข้ออื่นเกี่ยวกับคิวอีเมล 1.9.1 แต่มันไม่เกี่ยวกับปัญหา cron ใด ๆ (เช่นนี้หรือสิ่งนี้ ) หรือเกี่ยวกับคุณสมบัติของคิวใหม่ที่ไม่ได้ใช้งาน (เช่นนี้ )

ในกรณีของเราเราพบปัญหาว่าคิว ( core_email_queueและcore_email_queue_recipients) จะไม่ได้รับอีเมลใด ๆ เกี่ยวกับคำสั่งซื้อใหม่หรือการปรับปรุงคำสั่งซื้อและดังนั้นจึงไม่มีอีเมลที่ส่งออกไปสำหรับสิ่งที่เกี่ยวข้องกับการสั่งซื้ออีกด้วย cron ยังทำงานได้อย่างสมบูรณ์ คิวทำงานและพวกมันก็ถูกส่งออกไป

สิ่งที่แปลกคือในสภาพแวดล้อมการทดสอบของเราทุกอย่างทำงานได้ แม้ว่าเราจะมีชีวิตอยู่ในวันนี้ในนาทีแรกอีเมลทั้งหมดได้รับการดำเนินการ แต่หลังจากผ่านไปไม่กี่นาที (โดยไม่ต้องมีการแก้ไขเพิ่มเติมใด ๆ ในระบบถ่ายทอดสดของหลักสูตร) ​​ไม่มีอีเมลใหม่เพิ่มเข้ามาในคิวเลย ดูเหมือนว่าจะเกิดขึ้น (แต่ฉันไม่สามารถบอกได้อย่างแน่นอน) เมื่อลูกค้ารายแรกใช้ PayPal Express ซึ่งเราไม่ได้ทดสอบมาก่อน: - และแน่นอนว่าเราใช้การแทนที่แบบกำหนดเองในตรรกะ PayPal Express ด้วย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 แสดงความคิดเห็นบรรทัดที่ 76 ในการMage_Core_Model_Email_Template_Mailerข้ามคิวอีเมลและอีเมลที่ได้รับอีกครั้ง แต่มันก็ไม่ได้เป็นทางออกที่ดี สิ่งนี้จะแก้ไขได้ดีขึ้นอย่างไร


1
คุณได้ทดสอบการทำธุรกรรมกี่รายการเทียบกับจำนวนการทำธุรกรรมจริงภายในไม่กี่นาทีแรก? นี่เป็นการอัปเกรดจากเวอร์ชั่นเก่ากว่าและบางไฟล์หายไปหรือมีการอนุญาตที่ไม่เหมาะสมหรือไม่? วิธีการเกี่ยวกับexception.logหรืออาจsystem.logจะมีเบาะแสใด ๆ มี?
pspahn

มันเป็นการอัพเกรดจาก 1.9.0.1 และมันไม่ได้ทำผ่าน Connect-Manager แต่จากรหัสวีโอไอพีดังนั้นฉันสงสัยว่าเรามีไฟล์ที่ขาดหายไป (เรายังกระจายไฟล์coreอื่น ๆ เพื่อให้มั่นใจว่าทุกอย่างที่ไม่ได้กำหนดเองหรือมีนามสกุลอยู่ ไม่ได้แก้ไขและเป็น) สิทธิ์ตรงกับการตั้งค่าเก่าและบันทึก / รายงานสะอาด
Jey DWork

cron ตั้งค่าเหมือนกันหรือไม่?
pspahn

เมื่อเราเห็นการเปลี่ยนแปลงอีเมลในบันทึกการเปลี่ยนแปลงเราเปลี่ยน cron ให้ทำงานทุก ๆ นาทีจากทุก ๆ 5 นาทีก่อน (เนื่องจากเราเข้าใจการเปลี่ยนแปลงดังนั้นมิฉะนั้นในกรณีที่เลวร้ายที่สุดลูกค้าจะต้องรอถึง 5 นาทีสำหรับอีเมลยืนยันของพวกเขา) นอกเหนือจากนั้นไม่มีการเปลี่ยนแปลงและดังที่กล่าวไว้ก่อนหน้านี้และเราเห็นจากงานอื่น cron ทำงานโดยไม่มีปัญหา // แก้ไข: ฉันอาจจะเพิ่มที่เราใช้ (และใช้เสมอ) Aoe_Scheduler ที่เราตั้งcore_email_queue_send_allให้ทำงานทุกนาทีและจากที่เราเห็นว่ามันถูกเรียกใช้จริง
Jey DWork

ไตรมาสที่ 4 ปี 2015 และฉันมีปัญหาเดียวกันฉันสามารถยืนยันได้ว่าตารางคิวนั้นไม่มีรายการสำหรับคำสั่งซื้อทั้งหมดเป็นสัญญาณที่ชัดเจนในการยืนยันรายงานว่าไม่มีการรับอีเมล น่าเสียดายที่การบันทึกถูกปิดในกรณีของฉันดังนั้นฉันไม่มีข้อผิดพลาดในการค้นหา คุณได้เรียนรู้สิ่งใหม่ตั้งแต่เริ่มโพสต์ซึ่งอาจเป็นประโยชน์ในการเพิ่มหรือไม่
Rick Buczynski

คำตอบ:


8

ฉันเดาว่าการตั้งค่า cron.php เพื่อให้ทำงานทุกนาทีทำให้หลายสิ่งหลายอย่างต้องยืนอยู่บนกันและกันเช่นไม่จบก่อนงานต่อไปที่มีลักษณะเดียวกันหรือคล้ายกันจะถูกดำเนินการ เนื่องจากทั้ง cron.php จะไม่ได้รับรู้ถึงแต่ละรัฐ สามารถพยายามบันทึกเดียวกันซ้ำสองครั้งทำให้เกิดข้อยกเว้นแปลก ๆ ที่ส่งอีเมลคิว

ด้วยที่กล่าวว่ามีอยู่Mage::Logในข้อยกเว้นของ Queue Mailer ดังนั้นให้แน่ใจว่าการเปิดใช้งานการบันทึกจะเป็นขั้นตอนที่ดีที่สุดเพื่อช่วยในการตรวจสอบว่ามีข้อยกเว้นใด ๆ ก็ควรที่จะแค่วิ่งphp -f cron.phpจาก CLI เพื่อดูว่ามันมีการขว้างข้อยกเว้นใด ๆ หรือไม่คุณอาจไม่เห็นมันวิ่งไปตามฉากหลัง

ฉันจะเริ่มด้วยการmail()ทดสอบPHP อย่างง่าย ๆเพื่อให้แน่ใจว่าคุณไม่ได้ใช้นโยบายสแปมหรือสิ่งใด ๆ เพียงเพื่อให้แน่ใจว่าไม่ใช่สิ่งที่ต่ำกว่าในสแต็กที่ทำให้เกิดปัญหา

แค่การเก็งกำไรหวังว่ามันจะช่วยได้!

* แก้ไข *

ใช้cron.shแทนที่จะcron.phpทำgrep psเพื่อดูว่ากระบวนการก่อนหน้านี้ทำงานอยู่หรือไม่


ขอบคุณสำหรับการป้อนข้อมูล แต่ปัญหาเหล่านี้ค่อนข้างแน่ใจว่าจะถูกยกเว้น เพียงเพราะงาน cron ระบบจริงทำงานทุกนาทีไม่ได้หมายความว่างาน cron คุณภาพเยี่ยมทั้งหมด ในกรณีของเราอีเมลเท่านั้นที่ถูกตั้งค่าให้ทำงานทุกนาทีและจากบันทึก cron Magentos เราจะเห็นว่างาน cron ทั้งหมดเสร็จเรียบร้อยแล้ว - แม้ในนาที "เครียด" (เช่นทุกชั่วโมงหรือมากกว่านั้นเมื่อทำงานมากขึ้นในครั้งเดียวและไม่ใช่แค่อีเมล ) การบันทึกยังเปิดใช้งานและข้อยกเว้นจะไม่ถูกโยนทิ้งเลย การทำงานเป็นตัวกรองสแปมสามารถยกเว้นได้เช่นเดียวกับหลังจากการแก้ไขปัญหาที่ฉันโพสต์อีเมลทั้งหมดจะเข้าถึงลูกค้าทุกคน
Jey DWork

คุณอาจต้องการลองและเปิดใช้งานโหมดผู้พัฒนาเพื่อดูว่าช่วยสร้างข้อยกเว้นใด ๆ ที่ไม่ได้บันทึก ระวังให้ดีถ้ามันยังทำงานอยู่ นอกจากนี้ยังมีบันทึกเว็บเซิร์ฟเวอร์ที่สัมพันธ์กัน?
B00MER

2
@JeyDWork คุณใช้Aoe_Scheduler แล้วหรือยัง สิ่งนี้สามารถให้ทัศนวิสัยที่ดี
benmarks

2
ต้องการดูการอัปเดต คิวอีเมลพิสูจน์แล้วว่าเป็นสิ่งที่ท้าทายสำหรับหลาย ๆ คน
benmarks

1
สำหรับฉันฉันใช้มาตรฐาน paypal ซึ่งต้องการ IPN (การแจ้งการชำระเงินทันที) ส่งคืนข้อมูลจากเพย์พาลเพียงเพื่อยืนยันการชำระเงินสำเร็จและเปลี่ยนสถานะการสั่งซื้อเป็นการประมวลผล / เสร็จสมบูรณ์และสุดท้ายส่งอีเมล .. แต่ฉันไม่ได้ตั้งค่าโดเมนจริง สำหรับเซิร์ฟเวอร์และ vhosts ของฉันในการเข้าถึงนั่นคือเหตุผลที่ paypal ไม่สามารถโพสต์ข้อมูล IPN ไปยังวีโอไอพี คุณสามารถตรวจสอบประวัติ IPN ได้ในโปรไฟล์บัญชี paypal Paypal แสดงข้อมูลที่คาดว่าจะส่งออกจริง ๆ แล้วและสถานะคือ "ลองใหม่" ..
Zaw

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.