Příhoda je stará asi tři týdny, ale teprve teď mám čas jí napsat.
Vždy jsem za základní vlastnost Javy považoval její spolehlivost a stabilitu. Runtime bylo dobře odladěné, knihovny měly minimum chyb a případů, kdy aplikace spadla kvůli chybě Javy a ne našeho programátora, bylo minimum.
Vždy jsem se smál kolegům vyvíjejícím v .Net, kde každý deployment do složitějšího prostředí byl zdrojem adrenalinu již několik dní předem. Kolize verzí DLL x86 a x64, sdílené DLL přes celý systém atd… Java je přeci lepší, ne?
Instaloval jsem u zákazníka nějakou naší úžasnou aplikaci. Samozřejmě napsanou v Javě. Takže nejprve Java runtime … jakou verzi tam dát? Novou 1.7.1? Tu ještě nemáme odzkoušenou v reálném světě, tak radši poslední 1.6.29. OK. Pak tam hodím aplikační kontejner (Glassfish). V něm připravím zdroje pro aplikaci – datasource pro databázi. Nastavím hodnoty pro spojení na MS SQL Server, zmáčknu PING, aby si je Glassfish ověřil … a nic. Žádná odpověď. Ne chyba spojení, ale prostě žádná reakce.
Restartnu Glassfish. Stále totéž. Nu což, budu to řešit potom, snad jsem vše zadal správně, Nainstaluju aplikaci, zkusím její testovací URL … a aplikace zatuhne. Ve chvíli pokusu o připojení do MS SQL aplikace zatuhne. Bez jakékoli hlášky.
Tak jsem experimentoval s nastavením logování, Glassfishe jako celku, systému. Vsjo marno.
Tak tedy Google. Po několika dotazech jsem našel popis problému podezřele se blížícího tomu mému: článek 1, článek 2. Ukázalo se, že Java 1.6.29 nefunguje s MS SQL Serverem 2008 běžícím na Windows Serveru 2008 R2 x64, pokud je na serveru povolena SSL komunikace. Chyba asi není tak úplně v JDBC driveru od Microsoftu, spíše někde v socketové komunikaci. Verze 1.7.1 (a novější) resp. 1.6.26 (a starší) fungují OK.
OK. Tedy rychlá reinstalace Javy na 1.7.1, která má fungovat. Aplikace se rozbíhá, štěstí na všech stranách. Aplikaci jsem předal k testování.
O den později se mi aplikace vrátila. V nějaké obrazovce nefungovalo načítání souboru z disku. Soubor se hledal podle data. A vypadalo to, že se hledá podle data o dva dny jiného, než které je v databázi. Tak jsem vynadal programátorovi, že tam někde nechal hardcodované testovací datum. Programátor se samozřejmě vykrucoval, jak to tak vždy programátoři dělávají. A to natolik, že mi ukázal kód. A bylo vidět, že data skutečně bere z databáze.
V databázi je datum 2.11. Aplikace však vidí 31.10.
Co s tím? Být to o pár hodin, je to adept na problém s časovou zónou. Ale posun o dva dny se na časovou zónu shodit nenechá.
Takže zase logování, debugování a nakonec Google.
Sakra.
Zase je to chyba Javy. V javě 1.7.0, 1.7.1 při čtení sloupečku typu DATE (jen datum, ne DATETIME) může být vraceno datum o dva dny jinde. Prý se to děje nejen u MS SQL, ale i u Postgresu, našel jsem jinde.
Tak jsem downgradnul javu na 1.6.26 a už vše funguje správně.
Nicméně tyhle dva incidenty nás stály minimálně jeden člověkoden, možná i o něco více.
Poučení?
- Java 1.6.26 je ta pravá a nové verze zkoušet velmi opatrně
- Už neplatí, že runtime Javy je spolehlivý.
Blame Canada Oracle!
pebrou 