Symfony APC кэширует неправильный контент

Question

Hy,

поэтому я унаследовал приложение symfony 1.3.8 с использованием APC в качестве механизма кеширования. Даже я отключил кэширование с помощью

default: 
    enabled:  false 
    with_layout: false 
    lifetime: 86400 

запись с ключом *.symfony.routing.data все еще сохраняются.

Everytime I открыть ссылку предписывающей в PDF документ $host/$app/erhebung/13398/ausweise.pdf Я генерируемый с помощью плагина, то второй раз я открываю эту ссылку я получаю сообщение об ошибке:

Action "erhebung/13398" does not exist., referer: … 

Кэш делает - после первого звонка - containt сериализованное значение

array(2) { 
    'parse_/erhebung/13398/ausweise.pdf_b0d96fa30dcf0130d6a4b26f14f44bfb' => 
    array(3) { 
    'name' => 
    string(7) "default" 
    'pattern' => 
    string(18) "/:module/:action/*" 
    'parameters' => 
    array(3) { 
     'module' => 
     string(8) "erhebung" 
     'action' => 
     string(5) "13398" 
     'ausweise.pdf' => 
     bool(true) 
    } 
    } 
    'generate__4d783133e9aa851733d16cf1d1750ad5_b0d96fa30dcf0130d6a4b26f14f44bfb' => 
    string(1) "/" 
} 

, который, как представляется, неправильный шаблон маршрутизации, он должен быть:

erhebung_ausweise: 
    url: /erhebung/:id/ausweise.pdf 
    param: { module: erhebung, action: ausweise } 
    requirements: { id: \d+ } 

вместо:

default: 
    url: /:module/:action/* 

Когда очистить кэш APC вручную можно создавать и открывать PDF еще раз.

Answer 1

Okey, мне потребовалось несколько дней, чтобы решить эту проблему, я использовал xhprof, так как другие инструменты, такие как xdebug и print_debug_backtrace, не работают.

Опишу, что привело к этой проблеме.

Тот же URL-адрес был перенаправлен дважды. Сначала для запуска правильного обработчика запроса и второго по ошибке. Мой предшественник использует домашнюю функцию cross_app_url, которая будет читать конфигурацию маршрутизации другого приложения. Во время этого процесса uri снова анализировался, и результат (ничего не найденный с использованием маршрута по умолчанию) был кэширован (снова). Следовательно, во второй раз uri назывался первой маршрутизацией обработчика запроса faild и, следовательно, ошибки.

Я надеюсь, что если кто-нибудь столкнется с тем же вопросом, он найдет это легче, чем я.