Jak správně smazat Configurator cache po deployi?

F.Vesely napsal(a):

My to děláme tak, že nová verze jde do jiné složky, pak provedeme composer install, migrace, atd. a nakonec se přehodí link.

Díky, tomu bych se ale rád vyhnul, ten proces už je pak dost zdlouhavý a ohledně aktualizace composeru to máme nastavené trochu jinak.

Každopádně to vypadá, že to ve výsledku s configuratorem nesouvisí, špatně jsem si to vyložil. Schválně jsem včera to automatické promazávání zrušil a chyba se objevila znovu. Ale hlavně ve chvíli, kdy neprobíhal žádný deploy.

Vždy to zřejmě nastává při načítání cache, která má nastavenou expiraci na 5 minut. Na disku je pak zamčený prázdný cache soubor… Opravdu mi nejde do hlavy, co by to mohlo mít za příčinu.

Pavel Kravčík napsal(a):

Jestli je to možné – zkus upgrade na vyšší verze. U většího partnera se nám tohle dělo nárazově na Nette2.4 párkrát za měsíc. V Nette3 bez problémů.

Je to jak píšete – dříve se to asi stávalo třeba jednou do měsíce. To mě tolik netrápilo, protože se o to postaral autoscaling a škody byly zanedbatelné. Nyní se to ale začalo z ničeho nic dít prakticky každý den, což už je docela problém. Na Nette 3 ale jedeme. Čeká nás nyní větší aktualizace vč. PHP 8.3, tak si to třeba sedne.

Marek Bartoš napsal(a):

Když se invaliduje cache, tak se vytvoří zámek a všechny requesty požadující danou cache čekají, než ji request, který vytvořil zámek vygeneruje.
To při velkém množství requestů může aplikaci zasekat.
Zkuste cache udělat permanentní a místo při requestu ji aktualizovat skrze cron job.

Jasně, zasekat bych pochopil. Tady ale něco selhává úplně, protože se to cache nevytvoří vůbec, ale všechny procesy na to donekonečna čekají. Navíc, v tomto případě to cache v zásadě obaluje asi 3 dotazy na databázi, které zjišťují nastavení projektu před generováním rout, což je otázka max několika milisekund. Tj. nejedná se o nic, co by ty requesty mělo blokovat dlouho.

A nemyslím, že by problém měl být v kódu, jedná se o standardní cache load:

$value = $cache->load($key, function (&$dependencies) {
	$dependencies[Cache::Expire] = '5 minutes';
	...
});

Naivně předpokládám, že i kdyby došlo k erroru v tom kódu při generování cache, tak se proces ukončí, flock se tím automaticky uvolní a pokusí se ji vygenerovat další proces v pořadí (což se neděje).

Každopádně děkuji všem za pomoc při odhalení viníka, po odstranění této cache se to zatím zdá být v pořádku.