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.
nem lenne jobb neked egy ntp, es akkor nem az ido van allitgatva?
Ezt úgy érted, hogy a kiszolgálón amin a GF fut legyen beállítva hogy ntp szinkronizálja az óráját?
aha, ne percenkent huzogasd ntpdate-al, majd az ntp megcsinalja maganak a szinkront. (gyorsit/lassit)
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.
Időt, mint olyat UTC-ben tárol, és a megjelenítés történik beállított időzóna szerint. Vagy nem...?
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.
https://en.wikipedia.org/wiki/XY_problem
X: idióták elállítják az időt
Y: meg akarod javítani az alkalmazásod
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~