Appszerver deatmatch Part 1

Van még egy elmaradásom. Szóval a legutóbbi Java User Meeting-en lement az Appserver deatmatch első része, azaz a Sun ingyenes Glassfish v2 szerverét nyüstöltük. Azaz nyüstölte két hozzáértő ember, egy előregyártott "vendégkönyv" ejb-webes alkalmazással, mi pedig figyeltük a kivetítőn ténykedéseiket. Nézzük a nyolc feladatot:

1. Egy EJB3 + JPA alapú egyszerű webes vendégkönyv alkalmazás beüzemelése a gépre telepített adatbázissal, bónuszként a benne lévő webszolgáltatás WSDL-ének letöltése.

Hamar ment, rögtön a második részt is kipipálva. Belenéztünk a WSDL-be (csúnya nagy XML, lényeg hogy automatikusan generálódott) és csináltunk egy teszthívást a Glassfish admin konzol segítségével. A teszthívás azt jelenti, hogy kitöltögettük a Glassfish WSDL alapján dinamikusan generált HTML formját és submitáltuk.

2. Build script-ből (távoli) deploy.

Netbeans-ből nyomták Ant-tal egy speciális Glassfish task-kal. Tehát nem sima másolási műveletről volt szó, bár úgy hallottam támogatja a hot-deploy-t is, azaz pár másodpercenként szkennel egy könyvtárat és ha talál változást benne akkor újradeployol.

3. Loggolási konfig megváltoztatása egy alkalmazás alatt futásidőben.

Ezt is az admin konzolon lehetett megcsináli és a logot is ott néztük csilivili táblázatban. Szokásosan loggerenként lehet severity level-t állítgani. A példaalkalmazás ilyen szempontból hazabeszélős volt, mert épített arra, hogy a Glassfish admin konzolja a Java Logging API-t támogatja (és csak azt). log4j konfigot gondolom a log4j.xml kézzel való szerkesztésével lehetett volna állítgatni és a csilivili html táblázatról is le kellett volna mondani, de ennek mégis jobban örültem volna.

4. A vendégkönyv távoli debug-olása.

Ez is simán ment, de a Glassfish-t újra kellett indítani a Debugolás megkezdése előtt. Úgy rémlik a JBoss-t nem szoktuk újraindítgatni, fixre be van állítva neki egy kapcsoló hogy engedélyezi a debug kliensek csatlakozását. A kapcsolót persze nem lehet menet közben váltogatni. Netbeans volt a debugoló kliens, de más is lehetett volna, mert standard debug portot használ.

5. Adatforrás megváltoztatása futásidőben.

Ez nem ment (exception), bár nem is vártuk el. Szerintem semmelyik alkalmazásszervernél nem működik. Az alkalmazás újraindításával viszont már simán ment. Ezt is az admin felületen állítgatták.

6. Appszerver leállítása majd újraindítása a deployolt alkalmazással.

Ezt észre sem vettem. Nem mértünk időt, de 10 másodperc körül lehetett sacc per kábé.

7. LDAP azononosítás (ha belefér az időbe)

Ez sikerült volna, de már kezdtünk kicsit kicsúszni az időből. Az mondták 10 perc alatt megvan általában, még 2 perc kéne (8 perc eltelt akkor).

8. Terheléses teszt (JMeter)

Terheltünk, 1700 request/sec-en ketyegett egy átlag notebook-on. Már nem emlékszem a pontos számokra, de tuningolással talán fel tudták vinni 2200-re. (JVM paraméterek.) A terhelésnél a loggolás ki volt kapcsolva és a debug mód sem működött. Ennek a pontnak akkor lett volna értelme, ha azonos hardveren van mivel összehasonlítani, így magában nem sokat mond.

Nagyon jól felkészültek voltak a srácok. Kíváncsi vagyok a többi versenyzőre 2 hónap múlva. Remélhetőleg felveszik a kesztyűt és ők is komolyan veszik a dolgot. Továbbá előtte kipróbálják azért a tesztalkalmazást, esetleg megcsinálják benne a szükséges változtatásokat, hogy fusson a saját appszerverükön is.