GlassFish @Schedule jobok leállnak ha megváltoztatják a rendszeridőt

Fórumok

Sziasztok!

Egyik ügyfelünknél, az üzemeltetés sikeresen elkonfigurálta egy szerver idő és időzóna beállításait, így elég "érdekes" adatokat rögzített az alkalmazásunk.

Szeretnénk elébe menni az ilyen dolgoknak, így az elképzelés szerint egy @ApplicationScoped-os @Schedule eljárással percenként lekérnénk a pontos időt egy NTP szervertől, illetve az alkalmazásunkat futtató szerver időzóna beállítását. Ezt eltárolnánk, majd ahol kritikus az idő, ott ezen adatok alapján megnéznénk hogy a pontos idő és az időzóna rendben van-e. Azért percenként scannelnénk és az itt kapott adatokból dolgoznánk, mert elég sok helyen kell figyelni, hogy az idő renden van-e, és nem szeretnénk másodpercenként x alkalommal az NTP szervertől kérdezni.

A lényeg, hogy elkezdtük fejleszteni, tesztelni a dolgot és ha átállítjuk a rendszeridőt a GlassFish alatt a @Schedule dolgaink úgy leállnak, hogy csak na.

Az időzóna lekérése (ZoneId.systemDefault()) meg mintha a jvm az indulásakor lekérné a rendszer időzónáját és mindig ezt az értéket adná vissza.

Ezt leteszteltem egy kis konzolos appal. Mindig a jvm indulásakor érvényben lévő időzónát adja vissza. Viszont az időt azt jól adja vissza ez a konzolos app. Ha változik alatta az idő akkor már az újat adja vissza.

Gyanítom ez a GF-nél is így lenne csak ott maga az ejb timer service hasal el ha megváltozik a rendszeridő, így esélye sincs lekérni a rendszeridőt.

Szóval 2 dolgot szeretnék megoldani:

1. ne szálljon el az ejb timer service ha megváltozik a rendszeridő

2. szükség lenne a lekérdezés pillanatában beállított rendszer időzónára és nem arra ami a jvm indulásakor volt.

Hozzászólások

jvm nem szereti ha elmegy alatta az ido... nem olyan reg meg a szokomasodperctol is magaba fordult es elkezdte huzni a cput restartig.

Nekem ez teljesen jó lenne és a legtöbb ügyfelünknél így van. 

Viszont mi csak fejlesztünk és más üzemeltet. És mivel a fő ügyfélkörünk a KKV-k azon belül is a 2. k vagyis a középvállalatok, akik jellemzően külsős "rendszergazdát" alkalmaznak sajnos néhány nem feltétlenül áll a helyzet magaslatán. Így a héten történt egy olyan eset, hogy ügyfél szervere leállt és mikor újra elindították valamiért az addigi Europa/Budapest időzónát szépen átállították UTC-re. És mivel mind az alkalmazásunk , mind az adatbázis szerver Europa/Budapest időzónát vár így igen érdekes idők rögzültek az adatbázisban. 

Szóval az ellen, hogy nem pontos az óra illetve hogy nem Europa/Budapest van beállítva lokál időzónának mint fejlesztő semmit nem tudok tenni, de ha valami rossz lesz emiatt (mondjuk a NAV-hogy nem jó dátummal és/vagy idővel mennek be az adatok) akkor tuti lesz anyázás felénk is hogy szar a program.

Annyit viszont tehetek, hogy az alkalmazásból egy hivatalos ntp szervertől elkérem a pontos időt, összehasonlítom a lokális idővel ami az alkalmazást futtató szerveren van lekérem, hogy rendszer időzónája az Europa/Budapest-e és ha valamelyik sántít akkor lehet üzenni az illetékesnek, vagy adott esetben akár minden funkciót letiltani.

Ezt próbálnám a fenti módon megvalósítani, de az ott leírt két tényező ezt némileg befolyásolja

Szóval én egyáltalán nem akarom a szerver óráját állítani, csak meg akarok győződni róla, hogy pontosan jár ez és az időzónának az van beállítva amit elvárunk.

Hát .. a mysql azért eléggé paraméterezhető ezen a téren. Ha a time_zone változó értéke SYSTEM akkor a rendszertől kéri le az időzóna beállításokat és az alapján fogja tárolni az időt vagy lehet UTC-ben tárolja, de a beállított időzónának megfelelően adja vissza az sql eredményekben.

A lényeg, hogy a rendszer időzónája Europa/Budapset legyen, a time_zone SYSTEM, és a jdbc url-ben is a serverTimezone=Europe/Budapest, és akkor nem lesz időzavar az alkalmazásban.

Én csak szeretném leellenőrizni az alkalmazásomból, hogy ezek így vannak-e beállítva és az óra pontosan jár-e.

És ezt meg is tudom tenni, egyedül akkor van gond, ha a jvm indulása után megváltoztatják az oprendszer időzónáját. De hát aki ezt megteszi, az így járt. Ha nagyon biztosra akarok menni meghívok java-ból egy date vagy egy timedatectl parancsot és kimazsolázom belőle az időzónát. :) 

"a a time_zone változó értéke SYSTEM akkor a rendszertől kéri le az időzóna beállításokat és az alapján fogja tárolni az időt vagy lehet UTC-ben tárolja, de a beállított időzónának megfelelően adja vissza az sql eredményekben."

Azért na. Ez mind-mind kapcsolatonként felülbírálható. Tök mindegy, hogy mi az, amit az üzemeltetés beállított a DB-re defaultként. Te nyugodtan tudod kontrollálni, hogy neked mi kell.
Lásd:
https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-connp-props-da…

Sajnos nem lep meg, de randa dolog tőle. Viszont jó is, hogy felhoztad, meg kell néznem, hogy az Akka frameworkön alapuló rendszerem mit csinál ilyenkor.

kicsit hasonló: windowson ha átállítod az időt/dátumot, az kb 5-20mp mire a böngészőig eljut (chrome, edge)..

így ha valami ütemező fut a js-rétegben, az simán összezavarodik, ha megkínálják egy érvénytelen dátum/idővel.

sleepbe lement eszköz felébredésekor ugyanez, random jó, random 4+ óra eltérés. :D

~ubuntu, raspbian, os x~