Problémy při pokusu o ingest většího počtu dokumentů v jedné dávce (ingest routine)

jbil7 commented 4 years ago

Při pokusu o ingest většího počtu dokumentů (158) v jedné dávce se při prvním otevření daného ingest workflow ukázala tato chyba:

500 Error org.springframework.dao.CannotAcquireLockException: could not execute statement; SQL [n/a]; nested exception is org.hibernate.exception.LockAcquisitionException: could not execute statement

V též chybě skončil také ingest několika dokumentů obsažených v dávce. Některé dokumenty zůstaly se statusem "New", aniž by byly v řadě dále odbavovány.

Balíky jsem posílal se zmenšenými obrázky.

yantom commented 4 years ago

Opraveno, oprava nasazena, průběžně testováno a lazeno na testovacím srvru. Z chyby v předposlední dávce http://inqooltest-arclib.libj.cas.cz/ingest-batches/397eda41-f284-498a-8a21-c213deffca81 už se po opravě podařilo zotavit, poslední dávka běží právě nyní a ta by již měla sběhnout bez chyby od začátku do konce: http://inqooltest-arclib.libj.cas.cz/ingest-batches/f234ef68-6d33-4720-90fe-7eb971035219. Testovací data byly ponechána ve složce /opt/arclib/fileStorage/prod1/issue_63

yantom commented 3 years ago

Kromě již vyřešených problémů zůstává jeden nevyřešený a to timeout BPM tasku. Defaultně je 5 min a i když je možné ho prodloužit v konfiguraci, není to doporučováno. Dlouhoběžící task který zabíjí proces IW je v tomto případě antivirus. V případě původní testované dávky od @jbil7 o CCA 160 balících malé velikosti jeden neprošel. Následně jsem si všiml dalších selhání u dávky od @kerschfilip, kde byl počet balíků výrazně nižší (jednotky), zato velikost v jednotkách GB. Prozatím se pokusíme vyřešit problém změnou konfigurace - nebudeme však prodlužovat timeout tasku, pouze omezíme BPM engine na jedno vlákno a pustíme obě chybové dávky znovu. V případě že to nepomůže, nebo se to v budoucnu bude jevit jako nedostatečné můžeme dále zvážit následující možnosti:

zvýšit serverové zdroje
optimalizovat task antiviru (nejsem si jist zda je v současnosti volán antivirový daemon (což by byla ta rychlejší varianta) nebo spouštěna CLAM AV binárka)
přepsat task antiviru - tak aby jeho zpracování probíhalo mimo BPM engine a ten byl následně pouze notifikován (tento přístup je nový, tedy implementačně náročnejší)
zvýšit timeout BPM tasku - dle diskuzí na fórech může místy způsobit deadlock, doporučení od Camunda teamu je nezvyšovat a když ano ujistit se že transakční timeout je vyšší než timeout BPM tasku. Nicméně za pokus to stojí, v nejhorším případě pouze selže ingest, což je stávající stav

yantom commented 3 years ago

Zvýšili jsme timeout BPM tasku a snížili počet vláken BPM enginu, problém je tímto vyřešen, napoprvé již byla zpracována i dávká s balíčky GB velikostí http://inqooltest-arclib.libj.cas.cz/ingest-batches/9a885c50-b406-45a2-a9e3-aa12b7fa05fc . Je možné testovat.

kerschfilip commented 3 years ago

Vyzkoušel jsem ingest 8 SIP o celkové velikosti cca 30 GB (největší balíček měl necelých 9 GB). Zpracování proběhlo bez problému, zdá se, že problém je vyřešen, děkuji

yantom commented 3 years ago

Dnes reportován další problém spojený s dávkovým zpracováním:

Ve snaze otestovat hromadné ingesty (issue 63) jsem spustil ingest routine se 45 balíčky. Až v průběhu ingestu jsem si uvědomil, že balíčky obsahují problematická administrativní metadata s premis odkazy na více agentů z jedné události, v důsledku čehož začaly postupně padat všechny do incidentů. Celou dávku jsem tedy zrušil, importní složku promazal. Předpokládám, že ingesty se statusem „NEW“ nijak nepřekáží. U většiny balíčků nastal rollback, nicméně jeden zůstal viset v processing. Obdobně „visící“ balíček je i v dávce 27a7617c-63b5-434e-926a-c4754e680298, kterou posílala kolegyně a až na tuto jednu výjimku se celá dávka dokončila.

Problémem je, že z fronty se nyní neodbavují žádné další balíčky. Nově zadané ingesty (např. ingest-batch 542bbb6a-4fdc-461d-a9b7-e8c59b27e71d) se dostanou pouze do stavu „processing“, dále už nikoli, nové eventy se nezakládají (usuzuji dle hodinového čekání). Z logů jsem toho příliš moc nevyčetl a zatím jsem nepřišel na to, jak to z frontendu opravit. Odhaduji, že fronta je ucpaná uvíznutými balíčky

yantom commented 1 year ago

Problém z komentáře výše (26.11.2020) se mi v stávající verzi ARCLib nepodařilo zreprodukovat. Logy z téhož data na serveru již bohužel nejsou. @jbil7 mohu Vás poprosit o retest posledního scénáře i z Vaší strany? Pokud projde úspěšně, navrhuji ticket uzavřít.

yantom commented 1 year ago

Odhalili a opravili jsme příčinu bugu z komentáře 26.11.2020. Ticket navhruji uzavřít.

LIBCAS / ARCLib

Problémy při pokusu o ingest většího počtu dokumentů v jedné dávce (ingest routine) #63