Problemas de cache SUPEE-6788 (possível)

Desde que aplicamos o patch SUPEE-6788 no site de um cliente, uma vez por dia o site foi desativado e a única coisa que parece trazê-lo de volta é limpar o cache. Examinamos os logs e vários deles parecem incluir "O controlador frontal atingiu 100 iterações de correspondência do roteador". Esse problema não estava ocorrendo antes da aplicação do patch. Alguém tem alguma idéia do que poderia estar causando isso? Algumas pessoas dizem que poderia ser um bug de cache no magento, mas não sei dizer. Qualquer entrada seria útil!

Algumas notas adicionais:

• Não houve nenhuma carga pesada no servidor quando ele caiu, então isso não é um fator.
• Sim, todos os patches anteriores foram aplicados com sucesso.
• Estamos usando o memcache para armazenar o cache.

Eu e outro desenvolvedor tivemos um problema semelhante, no entanto, parece que o resolvemos aplicando o patch presente neste GitHub: https://github.com/AmpersandHQ/magento-ce-ee-config-corruption-bug

A causa parece ser algum tipo de condição de corrida em que o cache é limpo por um processo enquanto é instanciado por outro. Consegui reproduzi-lo seguindo as etapas também listadas no GitHub.

Abri um tíquete de suporte com o Magento para esse problema e tenho minhas suspeitas sobre o que começou a causar isso desde o patch, mas estou aguardando resposta.

Você pode ler mais sobre isso na seguinte pergunta: Problemas com página não estilizada, caminhos incorretos, perda da configuração do layout após a aplicação do patch SUPEE-6788 .

Temos o mesmo problema com 3 sites versão 1.8.1. Começou a aparecer após o SUPEE 6788. A correção acima não resolveu o problema. Na verdade, parece que há alguma mudança. Antes da correção, os sites estavam travando duas vezes por dia, agora a última falha passava de dois dias. Mas pode ser que esteja relacionado à carga. Os 3 sites são pequenos e não muito carregados. Esse problema não aparece em um site grande, com a versão 1.6.2 e SUPEE 6788 aplicadas. Todos os sites estão no mesmo servidor - o 3 com a versão 1.8.1 e o grande com a versão 1.6.2

Mudamos o cache do site de memcache para Redis e adicionamos um cronjob para despejar o cache a cada 12 horas. Passou de uma vez por dia para 4 a 5 dias antes de cair novamente. Em seguida, ajustamos o cronjob para despejar a cada 6 horas e ele não diminuiu desde (faz cerca de 3-4 dias desde). Nem nós nem a empresa de hospedagem podemos rastrear o problema real, mas isso parece ser uma correção de trabalho para nós. Espero que ajude alguém.

Adicionei o código de depuração AmpersandHQ hoje de manhã e agora a exceção "Controlador frontal atingiu 100 iterações de correspondência do roteador" aconteceu cerca de 75 vezes em um período de 2 minutos. Mas desta vez, presumivelmente por causa do código de depuração não ter salvo a entrada de cache corrompida, o site ainda está funcionando sem que todos obtenham exceções (não limpei o cache).

Ainda não investiguei isso para investigar, mas o cache-corrompido.log contém:

2015-11-22T03:42:42+00:00 DEBUG (7):
#0 app/code/core/Mage/Core/Model/App.php(1147): Mage_Core_Model_Cache->save('<admin><design>...', 'config_global_s...', Array, NULL)
#1 app/code/core/Mage/Core/Model/Config.php(552): Mage_Core_Model_App->saveCache('<admin><design>...', 'config_global_s...', Array, NULL)
#2 app/code/core/Mage/Core/Model/Config.php(474): Mage_Core_Model_Config->_saveCache('<admin><design>...', 'config_global_s...', Array, NULL)
#3 app/code/core/Mage/Core/Model/App.php(421): Mage_Core_Model_Config->saveCache()
#4 app/code/core/Mage/Core/Model/App.php(343): Mage_Core_Model_App->_initModules()
#5 app/Mage.php(683): Mage_Core_Model_App->run(Array)
#6 index.php(87): Mage::run('', 'store')
#7 {main}

Isso está no Magento 1.7.0.2 com cache Redis e o patch SUPEE-4755 do AmpersandHQ já aplicado.

Atualização de 2 de dezembro de 2015: Aqui está outro erro com o rastreamento de pilha completo:

2015-12-02T20:02:27+00:00 DEBUG (7):
#0 app/code/local/Mage/Core/Model/App.php(1156): save('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#1 app/code/local/Mage/Core/Model/Config.php(552): saveCache('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#2 app/code/local/Mage/Core/Model/Config.php(474): _saveCache('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#3 app/code/local/Mage/Core/Model/App.php(430): saveCache()
#4 app/code/local/Mage/Core/Model/App.php(343): _initModules()
#5 app/Mage.php(683): run(Array)
#6 index.php(87): run('', 'store')

Estamos enfrentando o mesmo problema há semanas, com vários sites Magento CE. No entanto, nenhuma das sugestões postadas aqui ajudou. Após várias sessões frustrantes de depuração ao longo de várias semanas, finalmente conseguimos definir isso.

Em resumo, descobrimos que o problema ocorreu devido a uma combinação do patch SUPEE-6788, Magento <1.9.2.0 e PHP> = 5.5.22, com invasores em potencial ou até scanners de segurança capazes de derrubar os sites sob demanda. Publicamos detalhes completos, incluindo uma correção, em nosso blog . Eu realmente espero que isso ajude outras almas pobres que sofrem com o mesmo problema.

Estamos enfrentando esse problema e nossos sites desde que lançamos o SUPEE6788 e parece que chamadas fraudulentas para serviços da web xmlrpc podem ser responsáveis ​​por corrupção de cache.

Estamos bloqueando as chamadas de serviço da Web de nossos servidores frontais, uma vez que não as usamos + aplicando o SUPEE 4755, manteremos você informado.