Magento 1.9.1 E-posta Kuyruğu çalışmıyor / buggy - nasıl giderilir ve en iyi düzeltme eki nedir?


35

Her şeyden önce evet, bu 1.9.1 e-posta kuyruğu ile ilgili başka bir soru / konu. Ama öyle değil (gibi herhangi bir cron sorunlar hakkında ilgili bu ya bu ) veya (gibi kullanılmayan yeni kuyruk özelliği hakkında bu ).

Bizim durumumuzda, sorunun ( core_email_queueve core_email_queue_recipients) sıranın sadece yeni siparişlerde veya sipariş güncellemelerinde herhangi bir e-posta almaması ve bu nedenle ilgili herhangi bir sipariş için artık e-posta gönderilmemesi, cron'un e-postaları mükemmel ve manuel olarak eklemesi sıra çalışır ve gönderilir.

İşin garibi, test ortamımızda her şey çalıştı. Bugün ilk dakikalarda canlı yayına girsek bile, tüm e-postalar işlendi, ancak birkaç dakika sonra (tabii ki canlı sistemde herhangi bir değişiklik yapılmadan) sıraya yeni e-postalar eklenmedi. İlk müşteri, önceden test etmediğimiz PayPal Express'i kullandığında, böyle oldu (ama kesin olarak söyleyemem), eskiden beri PayPal Express mantığında bazı özel geçersiz kılmalar kullanıyorduk sendNewOrderEmail(). Ancak kullanmak için yama yaptıktan sonra bile e-postaları tekrar çalıştıramadık queueNewOrderEmail().
Dolayısıyla ilk soru, eski fonksiyonun 'kırılan' tutarsızlığı tetiklemesi mümkün olabilirdi. e-posta sırası? Yoksa bu sadece büyük bir tesadüf mü ve tamamen farklı bir açıklama mı var?

Sorunu bulamadığımız için ama elbette en kısa sürede tekrar çalışmak için e-postalara ihtiyaç duyduk. İçinde Mage_Core_Model_Email_Template_Mailer(elbette bir kopyasında local) 76 satırını yorumladık: ->setQueue($this->getQueue())
Bu kuyruğu atlıyor gibi görünüyor ve tüm postalar yine eski yoldan gönderiliyor.

Bununla birlikte, çekirdek geçersiz kılma sayısını en aza indirgemek istediğimizden ve şu anda başka herhangi bir yan etkiyle karşılaşacağımızı, magento kodunu ve e-posta kuyruğu takdir edilecektir.

1.9.2 güncellemesi: 1.9.2 güncellemesinde e-posta kuyruğuna tekrar daha yakından baktık ve sorunu tekrar oluşturamadık. Ancak, 1.9.1 ile ilgili sorunun ne olduğu hakkında hala hiçbir ipucumuz olmadığı için ve geçersiz kılmanın Mage_Core_Model_Email_Template_Mailer::send()hala burada tarif edilen şekilde çalıştığı gibi hala kuyruğu kullanmıyoruz. Bu şekilde, üretimde bir süre sonra tekrar aynı problemde yaşamamayı umuyoruz.

tl; dr: E-posta kuyruğu 1.9.1'de çalışmıyor, satır 76'daki Mage_Core_Model_Email_Template_Maileraçıklamaları e-posta kuyruğunu atlıyor ve postalar tekrar gönderiliyor ancak bu iyi bir çözüm gibi görünmüyor. Bu nasıl daha iyi çözülebilir?


1
İlk birkaç dakika içinde kaç canlı işlem gerçekleştirdiğinize kıyasla kaç test işlemi gerçekleştirdiniz? Bu eski bir sürümden yükseltme miydi ve bazı dosyalar eksik mi veya uygun olmayan izinlere sahip mi? Peki ya exception.logda muhtemelen system.logorada herhangi bir ipucu var mı?
pspahn

1.9.0.1’den bir yükseltme yapıldı ve Connect-Manager üzerinden değil, Magento kod tabanından coreyapılmamıştı. değiştirilmemiş ve öyle). İzinler eski ayarları eşleştirir ve günlükler / raporlar temizdir.
Jey DWork,

Cron aynı mı kuruldu?
pspahn

Değişiklik günlüğündeki e-posta değişikliğini gördüğümüzde, her 5 dakikada bir her dakika çalıştırmak üzere cron'u değiştirdik (değişikliği anlıyoruz, aksi halde en kötü durumda müşterilerin onay postaları için 5 dakika kadar beklemeleri gerekirdi). Bunun dışında hiçbir değişiklik yok ve daha önce de söylediğimiz gibi diğer işlerden de görüyoruz ki cron problemsiz çalışıyor. // edit: Muhtemelen core_email_queue_send_allher dakikayı da koştuğumuz ve gerçekte idam edildiğini gördüğümüz yerden Aoe_Scheduler kullandığımızı (ve her zaman kullandığımızı) eklemeliyim .
Jey DWork,

4. Çeyrek 2015 ve aynı sorunu yaşıyorum, bazı siparişler için sıra tablolarının tamamen eksik olduğunu onaylayabiliyorum, hiçbir e-posta alınmadığına dair raporları doğrulayan bir işaret var. Benim durumumda maalesef günlüğe kaydetme kapatıldı, bu nedenle henüz aramam gereken hiçbir hata yok. Eklemenizde yardımcı olabilecek yeni bir şey öğrendiniz mi?
Rick Buczynski,

Yanıtlar:


8

Tahminim, her dakika çalıştırmak için cron.php'nin ayarlanması, birçok şeyin birbirinin üzerinde durmasına neden oldu, yani aynı yapıya veya benzerine planlanan bir sonraki görevin yerine getirilmesinden önce bitmedi. Her iki cron.php her bir durumun farkında olmayacağından beri. Aynı rekor iki kez denenebilir;

Bununla birlikte Mage::Log, Queue Mailer'in istisnaları içinde bulunduğunu, bu nedenle günlüğe kaydetmenin etkinleştirildiğinden emin olmak, herhangi bir istisna olup olmadığını belirlemeye yardımcı olacak en iyi adım olacağını söyledi. php -f cron.phpİstisnaları da atıp atmadığını görmek için sadece CLI'den koşmak akıllıca olabilir, sahnelerin ardında çalıştığını görmüyor olabilirsiniz.

Ayrıca mail(), herhangi bir Spam politikasına maruz kalmamanızdan emin olmak için basit bir PHP testi ile başlardım. Sadece soruna neden olan yığında daha düşük bir şey olmadığından emin olmak için.

Sadece bazı spekülasyonlar, yardımcı olacağını umuyorum!

* DÜZENLE *

Kullanım cron.shyerine cron.phpo yapacak şekilde grep psbir önceki işlem zaten yayınlanmakta olup olmadığını görmek için bakmak.


Girişiniz için teşekkürler, ancak bu sorunlar kesinlikle dışlanabilir. Gerçek sistem cron işi her dakika çalıştığı için tüm Magento cron işleri yapmak anlamına gelmez. Bizim durumumuzda her dakika sadece bir e-posta da kuruluyordu ve Magentos cron günlüğünden tüm cron işlerinin başarıyla bittiğini görebiliyoruz - "stresli" dakikalarda bile (örneğin, her saat veya daha fazla iş aynı anda e-posta ile değilken ). Günlük kaydı da etkindir ve istisnalar hiçbir şekilde atılmaz. Spam filtreleriyle çalışmak, tüm e-postaların tüm müşterilere ulaştığını belirttiğim geçici çözümden sonra da hariç tutulabilir.
Jey DWork

Kaydedilmemiş istisnalar oluşturmaya yardımcı olup olmadığını görmek için geliştirici modunu denemek ve etkinleştirmek isteyebilirsiniz. Ancak üretimde çalışıyorsa dikkatli olun. Ayrıca ilişkili herhangi bir web sunucusu günlükleri?
B00MER

2
@JeyDWork, Aoe_Scheduler kullandınız mı? Bu iyi görünürlük sağlayabilir.
Ocak'ta 15:15

2
Bir güncelleme görmek istiyorum. E-posta kuyruğu birçokları için zorlayıcıdır.
benmarks

1
Benim için, ödemenin başarılı olduğunu onaylamak ve sipariş durumunu işleme almak / tamamlamak ve son olarak e-posta göndermek için sipariş durumunu değiştirmek için son olarak geri gönderen IPN (Anında Ödeme Bildirimi) verisine ihtiyaç duyan paypal standardını kullanıyordum .. ama gerçek etki alanı ayarlamamıştım. benim sunucum ve vhosts için erişmek için paypal magento IPN veri gönderemedi nedeni oldu. IPN geçmişini paypal ticari hesap profilinde kontrol edebilirsiniz. Paypal aslında göndermesi beklenen verileri gösterdi ve durum "yeniden deneniyordu" ..
zaw

0

Core_email_queue ve core_email_queue_recipients'ın AUTO_INCREMENT olup olmadığını kontrol edin. Eğer bu tabloda AI etkin değilse, yeni girişler yapılmaz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.