Ma egy egész érdekes dologot találtunk meló közben. Érdekes egybeesésként ez ugyanaz a gubanc, mint amiről az egyik előadó is beszélt a 33degree konferencián, csak ő valami légiközlekedéssel foglalkozik. (hmmm, biztonságban érzitek magatokat?) A probléma alapja az, hogy a firewall-ok eltépkedik időnként a TCP kapcsolatokat. Egészen vicces, a szerver nem kapja meg a kérést, a kliens meg azt hiszi hogy elküldte, köztük a firewall röhög a markába, te meg nem érted miért áll a kliens, miért nem csinál semmit a szerver, és egyáltalán mi a rák történik. Ne tőlem kérdezzétek, hogy miért annyira fontos firewall-t telepíteni például az adatbázisod és az appszerver közé, szerintem ha valaki felhakkolta az appszervered és megvan az adatbázis kapcsolat akkor már régen rossz, de...
Ennek a problémának általában áldozatul esik néhány protokol, a lényegesebbeket említve RMI és valószinűleg minden adatbázis kapcsolat, általában a hosszú JMS kapcsolatok is, LDAP. Amit nem üt, az a HTTP nyilván, mert az bontódik amint lement a kérés és a válasz. Más most nem jut eszembe, ami jól működik vele :-)
Minden protokolra nem tudok orvosságot, de a commons-dbcp képes csekkolni az adatbázis kapcsolatot mielött odaadná a alkalmazás kódnak. Az 1.2-es verzió csak annyit tud, hogy elküld egy dummy kérdést a szervernek (tipikusan egy "select 1") és ha sikeresen válaszolt az adatbázis, akkor adja csak oda a kapcsolatot. Nem láttam még olyat, hogy a validation query elhasaljon, tulajdonképpen kicsit haszontalannak tűnik. Viszont amikor a fenti firewall gubanc beüt, akkor fentakadsz már a validation query-nél is, a kódod meg se kapja a vezérlést. Na erre a problémára ad megoldást a DBCP 1.3-tól kezdve a validationQueryTimeout paraméter. A DBCP 1.4 is már jó egy éve kint van, de amennyire látom még a legfrissebb cuccokban is az 1.2 van. Szóval egyéb hijján, akinek ez probléma, az kénytelen felülbuherálni.
Hát csak ennyi, remélem átérzitek :)
