A Bodog a Linuxra és a JBoss-ra fogadott. És nyert.

Linux

A Bodog.com egy online kaszinó, sportfogadási és póker oldal. Elég jól megy nekik, a foci szezonban hetente több mint 200 000 fogadást kötnek az oldalon, és egy időben akár 5 000 fogadó is játszhat a virtuális pókerasztaloknál. Az site üzemeltetőjének van egy igazi Linux + JBoss sikertörténete.

Carl Schmidt, a site vezető műszaki embere elmondta, hogy az oldal annak idején Sun Solaris-on futó BEA Weblogic J2EE alkalmazás-szerverrel és Versant adatbázis-szerverrel indult. A fogalom nőtt, és azon kezdtek el gondolkozni, hogy hogyan skálázódjanak fel a megnövekedett terheléshez. Sajnos az általuk használt Enterprise Java Beans (EJB) technológia a forgalmi tüskék idején felmondta a szolgálatot. Egy a termékben levő bug miatt ilyenkor az összes alkalmazás-szerver leállt és nem reagált a kérésekre.
A site a gyártókhoz fordult segítségért, de azok ahelyett, hogy megoldották volna a problémát egymásra mutogattak. Segítség hiányában az oldal munkatársai nekiálltak visszafejteni a kódot, és fixálták a problémát. Innentől kezdve a zárt forrású programok napjai meg voltak számlálva a Bodog.com-on.

Látva a cégek hozzáállását, onnantól kezdve Schmidt nyílt forrású termékeket vásárolt. Ha egyszer már nekik kell javítani az alkalmazásaikat, akkor legalább legyen meg a forráskód. Lecserélte a Sun Solaris-t és a többi szoftvert Red Hat Enterprise Linux-ra, Apache-ra, JBoss-ra és IBM DB2-re. A zárt forrású IBM DB2-re azt mondta, hogy abban az időben még nem érezte úgy, hogy a nyílt forrású MySQL kész lett volna a feladatra, de ma már más a helyzet.

Schmidt a migrációról elmondta, hogy az relatíve egyszerű volt. Hat fejlesztőből álló csoport portolta a cuccot Weblogic-ról JBoss-ra, és objektum-orientált adatbázis környezetről relációs adatbázisra. Az átállás nyolc hónapot vett igénybe. Az új infrastruktúra megfelelően növekedett a site-tal, amely jelenleg 14 webszerveren és egy 30 CPU-s alkalmazás-szerver cluster-en helyezkedik el.

A cikk itt.

( syntern | 2006. 06. 16., p – 14:48 )

Bugfix a szöveghez: az Enterprise Java Beans (EJB) az nem Sun technológia, hanem Java specifikáció (amiben a Sunon kívül sok más cég köztük a JBoss is részt vesz), amelynek a BEA Weblogic-os implementációja mondta fel a szolgálatot a tüskék idején. A teljes leállás meg úgy gondolom, hogy jó kis szinkronizálási bug lehetett.

Tehát akkor technológia, csak nem Sun-os? Van nem is technológia, viszont akkor hibás a Sun oldala? :)

Egyébként az eredeti cikkben nevén nevezik, hogy a Sun-nak kapcsolatban áll: "But Enterprise Java Beans (EJB), a Sun product, "

Ez azt jelentheti gondolom, hogy a Sun-tól vették az egész hóbelebacot.

--
trey @ gépház

Jo kerdes, a hwsw-n van egy jo terjedelmes forum, hogy mi technologia es mi technika. Ami angolul technology az magyarul ritkan az, de ez meg nyelveszeti kerdes ami nem hup-ra valo imho.

EJB sok Javas tech-hez hasonloan Sun-on belulrol jott (1.0), azutan kikerult a JCP szarnyai ala, ahol n+1 db ceg rakta ossze az ujabb es ujabb verziok specifikacioit. A kurrens verzio (EJB 3.0, ami a J2EE 1.5, mas verziozas szerint Java EE 5.0) kb most jott ki, es a fo ujdonsaga, hogy amit eddig 100-150 sorban kodolt le valaki, azt most elkeszitheti 40-ben, sokkal kevesebb XML deszkriptort kell elkesziteni a kod melle, lassan szabvannya valik az alkalmazasdeployment menete is, stb...

Tehát akkor most miről van szó?

"But Enterprise Java Beans (EJB), a Sun product, started bringing everything to a halt whenever usage spiked. "

Vettek valami Sun (vagy nem Sun?) terméket (vagy nem terméket?), ami leállított mindent valahányszor terhelési, használati csúcs volt?

--
trey @ gépház

A fenti mondat sajnos megkérdőjelezi az egész cikk szakmaiságát. Az EJB, tehát az Enterprise Java Bean nem termék, hanem technológia (http://java.sun.com/products/ejb/). Megvalósítására több cég is implementálta a saját EJB Container-ét. Ezek az implementációk szerves részei az alkalmazásszervereknek (az EJB Container az a szoftvermodul az alkalmazásszerveren belül, amely az EJB-ket menedzseli). A Sun alkalmazásszervere: http://www.sun.com/software/products/appsrvr/index.xml, ennek nyílt forráskódú forkja: https://glassfish.dev.java.net/.
Elvben az (is) szép a J2EE-s fejlesztési modellben, hogy az alkalmazásszerverek cserélhetők. A gyakorlatban ez persze nem olyan mint egy autóban az akkumulátorcsere, de egyre inkább olyan lesz.
Amiről a cikk ír, az valószínűleg egy alkalmazásszerverben leledző hiba miatti misztikus rendszerleállás-sorozat. Ebben az esetben mutogathat egymásra az alkalmazás fejlesztője, az alkalmazásszerver gyártója (ebben az esetben ez a BEA (http://www.bea.com) volt, amely egyébként nagyon régi motoros az alkalmazásszerverek piacán (http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/web…), illetve a JVM szállítója (ez lehetett a SUN is).
Amit tudni kell: a J2EE rendszerek nagyon sok mindent kivesznek az ember kezéből (ami jó is meg rossz is), továbbá relatíve bonyolult rendszerek. Legutóbbi projektemben pont BEA WebLogic hiba miatt szívtunk, egy egyszerű SQL select nem hozott egyetlen sort sem, pedig "kézzel" futtatva volt rekord az adattáblában. A WebLogic SQL optimalizációját kikapcsolva az alkalmazásunk azonnal működni kezdett. Egy ilyen bug-ba botolva az ember nehéz heteket tud átélni... gondolom ez történt a Bodog esetében is. Innen ésszerű dolog váltani a nyílt forrás felé...

Talán ez történhetett.

Újra elolvastam amit írtál.

"nem Sun technológia", "Sunon kívül sok más cég", "a BEA Weblogic-os implementációja mondta fel"

Valószínűleg erről beszélt az ember, amikor azt mondta, hogy egymásra mutogatás. Az ügyfelet probléma esetén általában nem érdekli, hogy mi a baj. Az érdekli - jelen esetben -, hogy menjen az online póker és dőljön a pénz. Azaz a probléma legyen megoldva. Az, hogy ki volt a hibás: a Solaris, a BEA, a Versant, vagy akármi az valószínűleg nem igazán érdekelte, csak az, hogy senki sem oldja meg a problémáját, ezért kivágta az egészet, és kezébe vette az irányítást. Láttam már a szakmában ilyet párszor. :-)

--
trey @ gépház

( _Joel | 2006. 06. 16., p – 14:48 )

"egymásra mutogattak."

Ez ismerős, a legjobb amikor még a fejlesztést is másik cég végzi, és a fejlesztők mutogatnak az alkalmazásszerver gyártójára, az mutogat a jvm meg az operációs rendszer szállítójára, akkor a support bejön, bebizonyítja, hogy az os és a jvm jól működik, az as gyártó meghozza a méregdrága külföldi konzulenst aki egy nap hegesztés után megmutatja a fejlesztőnek azt a bug-ot a kódjában, amit már egy elsőéves egyetemistának is szégyellnie kéne:)

Persze bármelyik rétegben lehet hiba, de az azért gyanús, hogy 8 hónapig írták újra a kódot a két J2EE alkalmazásszerver közötti migráció fedősztorijával... (egy átlag J2EE fejlesztési projekt nulláról befejeződik ennyi idő alatt).

( dikki | 2006. 06. 16., p – 20:19 )

Helyes. Én még sportingbeten nyomom, az full win2k3+asp, le is döglik néha.
Kb. 5 kattintással jutok el mindig oda ahova szeretnék, hihetetlenül kényelmetlen. Tudom, ez nem a szoftver hanem a fejlesztő hibája, de ennél frankóbb ajaxos felhasználási területet nehezen tudok elképzelni. Lehetne azonnal változtatni a téteket, fogadni, meg minden, nem 29 oldalt betölteni mire megfogadok valamit.

( _Joel | 2006. 06. 16., p – 22:00 )

Amúgy ez egy korrekt definíció:

http://en.wikipedia.org/wiki/EJB

Nem mondom, hogy én egyből megértettem anno amikor negyedévben felskiccelték (az akkor még 1.1-es) EJB speckót a whiteboard-ra, de a lényege az valami olyasmi lenne, hogy te, mint programozó úgy írhatsz kódot, hogy 90%-ban csak az üzleti funkcionalitástra kelljen konceltrálnod, és ne olyan alap (angolul ezt "plumbing"-nak, vagyis pumpálásnak mondják) cuccokkal szórakozz, mint a tranzakciókezelés (egy XML file-ban megadod, hogy milyen tranzakciókezelés vonatkozik az egyes metódusokra, és azt majd a container biztosítja, hogy valóban úgy legyen, meg automatikusan lekezeli a meghiúsult tranzakciók kezelését), jogosultsági kérdések (milyen jogosultsággal, szerepből hívható meg az adott objektum adott metódusa), elosztott működés (hol, melyik szerveren is van telepítve az a komponens, amit így hívnak és hogyan is tudom azt meghívni - na ezzel sem kell foglalkozni, csak egyszerűen meghívni - majd a háttérben az alkalmazásszerver kódja felderíti és megtalálja), többszálúsági kérdések (alapból minden EJB objektumban csak egy szál dolgozik - ezt garantálja neked a speckó - mondjuk éppen ezért a legtöbb J2EE szerverben az EJB-ket a háttérben poolozzák és ezeknek a pooloknak az állítgatásával lehet a legnagyobb teljesítményhangolásokat elérni). Meg még biztos van egy pár fontos alapfunkció, amit kihagyok. Ajálott alapmű a témában: Mastering EJBs. Tovább ajánlott az EJB 3.0-át használni, mert sok hajszál kihullásától megkíméli magát az ember (JBoss támogatja, Glassfish a referencia implementáció (mindkettő open source), és asszem mintha az Oracle-nek lenne még kint Java EE5-ből valamilye).