Quick-Event
Nestabilita při exportu live results
Při pořádání OŽ jsme testovali použití BlueBoxů a OResults, zároveň k tomu z toho stejného počítače běžel i export přes EmmaClient na Liveresultat. Souběh těchto dvou služeb pravděpodobně způsobuje nestabilitu QE, protože v průměru u každého 40-50 vyčtení v okamžiku strčení čipu do krabičky spadl. Po vypnutí EmmaClientu a exportu pouze na OResults již nespadl ani jednou
Ahoj, mam par doplnujicich otazek ...
- Jaka byla verze QE .. release nebo nejaka z Runs ?
- Vsechno ti jelo z jednoho PC a z jednoho QE ?
- Jakou DB jste pouzili Postgres nebo QBE soubor ?
Abychom se to mohli pokusit zreprodukovat
Ahoj,
verze QE byla 2.6.7 (Windows 11), jako databázi jsme použili Postgres (sesíťovaný přes mobilní hotspot), která běžela na druhém počítači (Linux, myslím Ubuntu), na obou zařízeních byl celou dobu QE spuštěný, ale vyčítání i tisk lístečků byly připojené pouze do mého počítače (Linux se nechtěl spřátelit s druhou tiskárnou na mezičasy), kde jsem měl puštěné obě ty exportní služby (OResults i EmmaClient).
Tady by asi nejvic pomohl log, nemate ho nahodou? Taky by me zajimalo, jestli to neni nahodou jenom nestabilita EmmaClienta, jestli to skutecne souvisi z OResults?
@fvacek - O padani QE pri "jen" zapnutem exportu pro EmmaClienta zatim nemam zadne informace. Ani se to ke me nedostalo, ty mas nejake takove zpravy ?
@mestaond - 2.6.7 - Buildovali jste si to sami nebo jste pouzili verzi z runs (jak tak koukam 2.6.7 znamena commit 08baf71 )?
@mestaond - Jak casto jste puvodne meli oba exporty nastavene (cas jak casto se export provadel) ?
Tušíš jak kvalitní připojení jste měli? LTE, 4G? My jsme dnes pozorovali problémy při uploadu pouze přes službu OResults. Po chvíli upload proběhl zase úspěšně. Chování jsme přisuzovali slabšímu mobilnímu připojení. Vliv na chod vyčítání jsem nepozoroval. Možná to spolu nesouvisí a je to spíš na jinou issue.
Fotku logu přímo z akce:
sesíťovaný přes mobilní hotspot
To pres mobilni hostpot jelo jak spojeni mezi QE a Postgresem, tak upload na OResult a Liveresultat ? Zadne jine zasitovani jste nemeli ?
@arnost00 2.6.7 jsme stáhli z runs (myslím že odsud https://github.com/Quick-Event/quickbox/actions/runs/3028804793, ale to se dělo v době, kdy jsem roznášel, takže přesně nevím), exporty byly do OResults těch výchozích 15 s, do EmmaClientu 30 nebo 60 s (nebavilo mě těch výchozích 60 pořád přepisovat) do xml. Nějaké logy možná někde jsou, ale nezvládl jsem je ve filesystemu najít. Ano, přes hotspot jelo jak zasíťování databáze, tak i upload na servery.
@lukaskett s tím připojením, v některých chvílích byla síť asi trochu přetížená, protože mezi vyčtením a vytištěním lístku byla i pár vteřinová prodleva, ale ty pády QE na tom byly myslím nezávislé (že stejně padal ve chvíli s delayem jako i bez něj)
Dnes jsme poradali zavody, pripojeni pres 4G muj mobil hot-spot, naprosto bez problemu. Diky Oto :+1: Tyka se to jenom O-Results, postgres jsem mel na lokale.
Ahoj. O minulém víkendu jsme pořádali MČR NOB a žebříček A a potkala nás, myslím, podobná nestabilita. Konfigurace QE 2.6.14, 3 PC ( v reálu v provozu 1, ostatní jen občas připojené k DB), postgress, Oresults - 10s. QE při obou závodech několikrát (při A cca 10x) spadl při vyčítání, respektive až po - před vytištěním lístečku. Po opětovném spuštění bylo předchozí vyčtení v QE, a pokračovali jsme bez problému. Internetové připojení nebylo stabilní, v průběhu jsme přecházeli na mobilní data, ale nezdálo se, že by to mělo nějaký vliv. V závěru jsme prodloužili Oresults službu na 30s a poté už to myslím nespadlo. QE soubory jsme poslali Jurdovi.
@petrsv to vycitani a export pro OResults jelo z jednoho PC ? Osobne jsem proto aby podobne exporty jely z jineho PC nez se vycita (kdyz jste meli 3) Pak totiz nevadi pad vycitani ruznym exportum a ty bezi dale.
@fvacek nestalo by za uvahu rozjet nejaky system ktery by pri padu ukladal dump ? Napr. neco jako crashpad.
Ano, bylo to ze stejného PC. Log bohužel nemáme. Dívali jsme se do něj a přijde mi, že se vždy smazal po restartu? A bohužel netuším jak ho nastavit, aby se někam ukládal
O víkendu jsme měli podobnou zkušenost - QE nám na PC, ze kterého se nahrávaly online výsledky (a na kterém se také vyčítalo), asi 3x spadl.
Nejsem si na 100 % jistý, ale mám pocit, že to minimálně jednou spadlo i ve chvíli, když si nikdo nevyčítal (možná ale mohl někdo vyčítat na druhé krabičce?). Log bohužel také nemám, zapomněl jsem ho přesměrovat do souboru :(
Interval pro export jsme měli nastavený na 1 minutu, vyčítali jsme cca 2 hodiny, ~650 závodníků.
jestli se to děje při vyčítání, může to souviset s tím, že zatímco se pravidelně exportují výsledky
https://github.com/Quick-Event/quickbox/blob/444bd9328bc3d20cc33be8e7f018ef39133bfc85/quickevent/app/quickevent/plugins/Event/src/services/oresultsclient.cpp#L112
, tak vyčtění spustí zároveň další request se změnami závodníka (invoknutý přes dbEventNotify)
https://github.com/Quick-Event/quickbox/blob/444bd9328bc3d20cc33be8e7f018ef39133bfc85/quickevent/app/quickevent/plugins/Event/src/services/oresultsclient.cpp#L179
ale aspoň mé oči nevidí proč by to mohl být (na špatném připojení) problém
@fvacek nestalo by za uvahu rozjet nejaky system ktery by pri padu ukladal dump ? Napr. neco jako crashpad.
problem je, ze pri padu, uz toho QE vetsinou moc neudela, musel bych ten log ukladat nekam do tempu, aby tam po padu proste zustal, coz neni zas tak spatny napad, udelam na to issue. https://github.com/Quick-Event/quickbox/issues/888
jestli se to děje při vyčítání, může to souviset s tím, že zatímco se pravidelně exportují výsledky
https://github.com/Quick-Event/quickbox/blob/444bd9328bc3d20cc33be8e7f018ef39133bfc85/quickevent/app/quickevent/plugins/Event/src/services/oresultsclient.cpp#L112
, tak vyčtění spustí zároveň další request se změnami závodníka (invoknutý přes
dbEventNotify)https://github.com/Quick-Event/quickbox/blob/444bd9328bc3d20cc33be8e7f018ef39133bfc85/quickevent/app/quickevent/plugins/Event/src/services/oresultsclient.cpp#L179
ale aspoň mé oči nevidí proč by to mohl být (na špatném připojení) problém
ani ja tam zadny problem nevidim, vice HTTP requestu muze bez problemu paralelne bezet
Comment by @JaroslavBeran - https://github.com/Quick-Event/quickbox/pull/886#issuecomment-1514203056
I expect this bug is related to our events during last weekend at Petrohrad.
We were facing a lot of QE crashes during the races. It happend each 20th up to 50th card read. When the runner read out his card the DB record was correctly created, but the app immediately crashed without printing receipts. Windows stopped the app and we had to start the app again then OResults service was either started automatically again or we did it manually. Then the runner either could read out his card again so new DB record was created and his receipt was printed or we could print the receipt maually for his already created DB record only.
na WMTBOC jeden den jsme vyčítali na jednom PC a export na OResults běžel na jiném PC => ani jeden pád dnes jsme vyčítali i exportovali z jednoho PC => spadlo nám to při vyčtení několikrát
na WMTBOC jeden den jsme vyčítali na jednom PC a export na OResults běžel na jiném PC => ani jeden pád dnes jsme vyčítali i exportovali z jednoho PC => spadlo nám to při vyčtení několikrát
takze to vypada, ze se OResults nejak nesnesou s vycitanim, my jsme na HSH vycitali a exportovali na jednom pocitaci tri dny a pokud vim, tak ani jeden pad, jel jsem teda na QT6 verzi.
jeste neni vyzkouseno jestli to padani pri spojeni oresults + vycitani nahovou neni windows specific vec