Antes de tudo, sim, essa é mais uma pergunta / tópico sobre a fila de emails 1.9.1. Mas não se trata de nenhum problema do cron (como este ou deste ) ou sobre o novo recurso de fila que não está sendo usado (como este ).
No nosso caso, tivemos o problema, que a fila ( core_email_queuee core_email_queue_recipients) simplesmente não recebia e-mails sobre novos pedidos ou atualizações de pedidos e, portanto, não foram mais enviados e-mails para nada relacionado a pedidos, também o cron está funcionando perfeitamente e adicionando manualmente e-mails a a fila funciona e eles são enviados.
O estranho é que, em nosso ambiente de teste, tudo funcionou. Mesmo quando entramos no ar hoje nos primeiros minutos, todos os emails foram processados, mas após alguns minutos (sem nenhuma modificação adicional no sistema ao vivo, é claro), nenhum novo email foi adicionado à fila. Parece que isso aconteceu (mas não posso ter certeza) quando o primeiro cliente usou o PayPal Express, que não testamos anteriormente: - / De fato, estávamos usando algumas substituições personalizadas na lógica do PayPal Express com a sendNewOrderEmail()função antiga . Mas não foi possível fazer com que os e-mails funcionassem novamente, mesmo depois de corrigi-los queueNewOrderEmail().
Portanto, a primeira pergunta seria: é possível que a função antiga tenha disparado alguma inconsistência que 'quebrou' a fila de email? Ou isso tudo é apenas uma grande coincidência e há uma explicação totalmente diferente?
Como não conseguimos encontrar o problema, mas é claro que precisamos de e-mails para trabalhar novamente o mais cedo possível, optamos por outra substituição principal. Em Mage_Core_Model_Email_Template_Mailer(é claro, em uma cópia local), comentamos a linha 76: ->setQueue($this->getQueue())
Isso parece ignorar a fila e todos os e-mails são enviados da maneira antiga novamente.
No entanto, como gostaríamos de manter o número mínimo de substituições principais e também não podemos dizer agora se enfrentaremos outros efeitos colaterais, outras dicas ou soluções de pessoas com uma compreensão mais profunda do código magento e do código magento. fila de e-mail seria apreciada.
Atualização para 1.9.2: Na atualização para 1.9.2, examinamos mais de perto a fila de emails e não conseguimos reproduzir o problema. Mas como ainda não temos nenhuma pista real sobre o problema do 1.9.1 e como a substituição Mage_Core_Model_Email_Template_Mailer::send()ainda funciona da maneira descrita aqui, ainda não estamos usando a fila. Dessa forma, esperamos não voltar a executar o mesmo problema depois de algum tempo na produção.
tl; dr: A fila de email não está funcionando no 1.9.1, comentando a linha 76 Mage_Core_Model_Email_Template_Mailerignora a fila de email e os emails são enviados novamente, mas isso não parece uma boa solução. Como isso pode ser resolvido melhor?
fonte
exception.logou possivelmentesystem.log, existem pistas?coreetc para garantir tudo o que não é personalizado ou existe uma extensão e não modificado e é). As permissões correspondem à configuração antiga e os logs / relatórios estão limpos.core_email_queue_send_allpara executar também a cada minuto e de onde vemos que ele realmente é executado.Respostas:
Meu palpite é que a configuração do cron.php para executar a cada minuto fez com que muitas coisas fiquem em cima umas das outras, ou seja, não terminem antes que a próxima tarefa agendada da mesma natureza ou similar seja executada. Como o cron.php não estaria ciente de cada estado. O mesmo registro pode ser tentado duas vezes, causando uma exceção estranha que interrompe o envio de emails da fila.
Com isso dito, há
Mage::Logas exceções do Queue Mailer, portanto, garantir que o log esteja ativado seria a melhor etapa para ajudar a determinar se há alguma exceção. Pode ser aconselhável também executar apenas aphp -f cron.phppartir da CLI para ver se ela também está lançando alguma exceção; talvez você não esteja vendo isso sendo executado nos bastidores.Eu também começaria com um
mail()teste PHP simples para garantir que você não esteja executando nenhuma política de spam ou algo assim. Só para ter certeza de que não é algo mais baixo na pilha que está causando o problema.Apenas algumas especulações, espero que ajude!
* EDIT *
Use em
cron.shvez decron.phpcomo serágrep pspara verificar se um processo anterior já está em execução.fonte
Verifique se core_email_queue e core_email_queue_recipients possuem AUTO_INCREMENT. Se essas tabelas não tiverem AI ativada, não serão necessárias novas entradas.
fonte