Az előző bejegyzés óta kicsit utánanéztem a FastCGI működésének. Kíváncsi voltam, milyen lehetőségek vannak a halott process-ek kilövésére, stb. Tulajdonképpen a működési logika igen egyszerű. A FastCGI modul előre megadott mennyiségben forkolja a process-t, és ha kérés jön, egy éppen szabad process-nek adja az adatokat feldolgozásra. Beállíthatunk egy request időkorlátot, és ha ezt túllépi a végrehajtás, az adott process halott állapotba kerül. Ekkor azonban maga a process még bennmarad a memóriában. A FastCGI modul megadott időközönként körbenéz, hogy mi újság a process-ekkel, és a halottakat kilődözi, majd új process-ekre cseréli. Ez alapján kicsit elgondolkodtam, hogy talán nem is a Servlet környezet "FastCGI-re erőltetése" az üdvözítő megoldás, hiszen a fenti működési logika a szabvány megoldásokkal is megvalósítható.

Az új ötletem, hogy FastCGI helyett Jetty process-eket kellene futtatni. A Jetty egy pici, kompakt, flexibilis Servlet container, így valószínűleg nem fogyasztana többet, mint egy FastCGI-ra épített speciális változat. Az Apache alá mod_jk-val ugyanúgy be lehetne fésülni, mint a FastCGI-t, és a mod_jk loadbalancing lehetőségének hála, indíthatunk több példányt is ugyanúgy, mint FastCGI esetén. És ami a lényeg, megvalósítható egy FastCGI-hez hasonló gyilkoló mechanizmus is. Mikor egy Jetty process nem tud időben kiszolgálni egy kérést, az adatbázisba bejegyezi, hogy halott a státusza. Eztán a FastCGI-hez hasonlóan egy külső process bizonyos időközönként végigfésülné az adatbázist, és ha talál halott Jetty process-t, egyszerűen kilőné azt, majd új példányt indítana.

A megoldás előnye, hogy viszonylag kis ráfordítással megvalósítható, hiszen nem kell hozzá külön Servlet containert készíteni, ugyanakkor az alkalmazásonkénti több jetty processnek köszönhetően biztosított a magas rendelkezésre állás, valamint a végtelen ciklusok, és hasonló programozási hibákból adódó problémák is kivédhetőek, tehát a FastCGI-hez hasonló, de teljesen szabványos megoldás alakítható ki.