Tipos de bloco inválidos


9

Estou recebendo a seguinte mensagem de erro algumas vezes por dia, e meu conhecimento do funcionamento interno do Magento CE 1.9.0.1 é pequeno o suficiente para que eu não saiba se isso é normal, um comportamento consultivo do Magento ou se está dizendo eu tenho um problema grave.

Aqui está a mensagem:

Um ou mais tipos de cache são invalidados: Bloqueia a saída HTML. Clique aqui para acessar o Gerenciamento de cache e atualizar os tipos de cache.

Atualizar esse cache específico faz com que o problema desapareça por algumas horas.

No momento, não estou editando layouts, produtos etc., nada.

O que está errado e como posso corrigi-lo?


Recebo isso todos os dias quando acordo e inicio sessão no Magento v1.9.2.2 - Um ou mais tipos de cache são invalidados: Bloqueia a saída HTML. Clique aqui para acessar o Gerenciamento de cache e atualizar os tipos de cache. Eu nunca costumava fazer isso em versões anteriores, a menos que estivesse realmente fazendo alguma coisa. Isso é algum tipo de bug?
Neal Hart

Respostas:


6

Primeiro, é importante entender que isso não é um erro, é apenas uma notificação.

Pode haver uma infinidade de razões pelas quais um cache de bloco é invalidado de atualizações de produtos, alterações de regras de preços de catálogo e extensões de terceiros. A execução de cronjobs também pode invalidar os caches de bloco.

Existem algumas extensões de comunidade disponíveis (listadas abaixo) que atualizarão seus blocos à medida que forem invalidados.

https://github.com/tomasinchoo/Inchoo_InvalidatedBlockCacheFix

https://github.com/mklooss/Loewenstark_InvalidCache


2

Isso é um erro.

Há um problema no trabalho do CRON (pós 1.9.?) Que executa e invalida o cache em HTML, o que produz problemas (por exemplo, no meu caso, falha ao transferir o desconto de preço para o carrinho de compras - portanto, o cliente recebe uma quantia errada).

Não precisamos executar uma extensão para corrigir um problema que foi introduzido!


Estou tendo exatamente o mesmo comportamento no CE 1.9.2.2, todas as manhãs a saída HTML dos blocos precisa ser atualizada e pensado em um problema de trabalho cron. @Brian, você poderia dar mais detalhes sobre essa tarefa cron?
Marc

Eu acho que você está pensando ao contrário: não foi que o "preço não foi transferido para a cesta", mas sim que o preço na página foi adicionado ao cache antes da atualização ser executada e, portanto, o cache estava errado , enquanto o preço correto é mostrado no carrinho. Para o comprador, eles provavelmente pensam que o preço mais baixo é o "correto".
Eric Seastrand

@ Brian, você poderia dar mais detalhes sobre a tarefa cron que estava invalidando seus blocos?
Haim

0

Esta é a operação padrão do Magento a partir da versão 1.6.xx e posterior. Algo está sempre causando uma invalidação aleatória do cache de bloco html.

Acabei de configurar um observador que dispara em um trabalho cron periódico, defina o intervalo que parecer apropriado.

Observer.php

<?php

/************************
 * Find invalidated cache types and refresh
 *
 * Set Cron Time for refresh in config.xml
 *
 */

class Fiasco_Rcache_Model_Observer {

    public function refreshCache() {

        try {

            $types = Mage::app()->getCacheInstance()->getInvalidatedTypes();

            foreach($types as $type) {

                Mage::app()->getCacheInstance()->cleanType($type->getId());

            }

            Mage::log('Invalid Cache Types Refreshed');

        } catch (Exception $e) {

            Mage::logException($e);

        }
    }
}

config.xml

<?xml version="1.0"?>
<config>
    <modules>
        <Fiasco_Rcache>
            <version>0.5.0</version>
        </Fiasco_Rcache>
    </modules>
    <global>
        <models>
            <refresh_cache>
                <class>Fiasco_Rcache_Model</class>
            </refresh_cache>
        </models>
    </global>
    <crontab>
        <jobs>
            <refresh_cache>
                <!-- Min Hour Day Month DoW -->
                <schedule><cron_expr>0 */3 * * *</cron_expr></schedule>
                <run><model>refresh_cache/observer::refreshCache</model></run>
            </refresh_cache>
        </jobs>
    </crontab>
</config>

0

Esse indicador de cache invalidado provavelmente está relacionado ao cron dailyCatalogUpdate. É responsável por aplicar / atualizar as regras do catálogo.

Uma vez por dia, ele liga Mage::getSingleton('catalogrule/rule')->applyAll();.

Dentro do código desse método, há uma chamada para $this->_invalidateCache(), que por sua vez chama $this->_app->getCacheInstance()->invalidateType()o block_htmlcache.

O problema é que ele invalida o cache sem fazer nenhuma verificação para determinar se ele ainda pode ser válido. Para mim, é melhor do que não invalidar o cache, porque você pode pelo menos saber que ele pode ser inválido e usar algo como o que o Fiasco Labs sugeriu para liberar os dados em cache (potencialmente) inválidos.

Torna-se então uma decisão sobre se você deseja erro do lado de:

A) Mostrando aos clientes o preço errado, mas mantendo o cache e, portanto, tendo menos carga no servidor

ou

B) Mostrando o preço correto, mas com mais falhas de cache e, portanto, maior carga do servidor.

Há duas coisas difíceis na ciência da computação: nomear coisas e invalidação de cache .


0

veja aqui a solução: https://magento.stackexchange.com/a/72687

Altere basicamente a função dailyCatalogUpdate de app / code / local / Mage / CatalogRule / Model / Observer.php para

        $collection = Mage::getResourceModel('catalogrule/rule_collection')
        ->addFieldToFilter('is_active', array('neq' => 0));
    if ($collection->getSize() == 0) {
        return $this;
    }
    parent::dailyCatalogUpdate($observer);
    $types = Mage::getConfig()->getNode('global/catalogrule/related_cache_types')->asArray();
    foreach (array_keys($types) as $type) {
        Mage::app()->getCacheInstance()->cleanType($type);
    }
    return $this;
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.