JBoss, EJB 3 i StreamCorruptedException
Ostatnio wykonywałem stawianie serwera JBoss 4.0.5 z pakietem patchującym jboss-EJB-3.0_RC9_Patch_1, który miał zapewnić mi rozszerzenie do funkcjonalności EJB 3. Uruchamiałem JBoss w konfiguracji default. Podczas uruchamiania otrzymałem komunikat, którego finałowym powodem był brak klasy org.jboss.cache.TreeCache. Klasę odnalazłem w pakiecie jboss-cache.jar znajdującą się w konfiguracji all. Poza tym jar’em okazało się również niezbędne dodanie jgroups.jar z podobnej konfiguracji. I teraz po uruchomieniu okazało się, że ustawicznie otrzymuje komunikat, wyglądający mniej więcej tak:
2007-05-29 19:31:15,453 WARN [org.jgroups.protocols.UDP] packet from /X.X.X.X 
has different version from ours
2007-05-29 19:31:27,671 ERROR [org.jgroups.protocols.UDP] exception=java.io.StreamCorruptedException: invalid stream header
at java.io.ObjectInputStream.readStreamHeader (ObjectInputStream.java:764)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:277)
at org.jgroups.protocols.UDP.handleIncomingUdpPacket(UDP.java:670)
at org.jgroups.protocols.UDP.run(UDP.java:249)
at java.lang.Thread.run(Thread.java:595)
Podczas poszukiwań w internecie próbowałem ustalić “Skąd się to diabła bierze ??” oraz “Jak to wyłączyć ?”. Dowiedziałem się, że głównym sprawcą zamieszania jest opcja grupowania w klastry (group clustering). Opcja ta oczywiście dostępne jest wyłącznie w dystrybucji all. Moje przeniesienie plików jar, w celu zniwelowania problemu przyczyniły się do powstania tego kłopotu.
Tak więc postanowiłem wykonać operację w drugą stronę i dowiedzieć się, co spowodowało narodzenie się wymagania klas typu TreeCache i JGroups. Przyczyną był oczywiście ów patch, który rejestrował dwa serwisy, korzystające z tej usługi. Usunąłem więc pliki, które są odpowiedzialne za taki stan rzeczy: ejb3_clustered_sfsbcache_service.xml oraz ejb3_entity_cache_service.xml (znajdujące się w folderze deploy). Oczywiście nie zapomniałem również o pozbyciu się jgroups.jar oraz jboss-cache.jar (z folderu lib). Po tych czystkach wszystko poszło pięknie i bez problemów.
Oczywistym jest, że zacząłem się zastanawiać nad sposobami zniwelowania problemu w przypadku, kiedy posiadam zainstalowany clustering. Okazało się, że powodem jest istnienie innych serwerów w lokalnej sieci, które mają inną wersję JBoss’a, a które próbują utworzyć ze mną wspólną grupę. Każda z takich grup używa swoją prywatną nazwę oraz określenie adresu i portu dla multicastingu. Z pomocą nad rozwikładniem zagadki przyszły mi poniższe dwa artykuły:
http://docs.jboss.org/jbossas/jboss4guide/r4/html/jbosscache.chapt.html , który opisuje sposób konfigurowania JGroups (i tu mała uwaga, opcja discard_incompatible_packets w mojej wersji nazywa się discard_incompatibe_packets z powodu literówki, która została później poprawiona w JBoss)
http://wiki.jboss.org/wiki/Wiki.jsp?page=TwoClustersSameNetwork , który opisuje jak skonfigurować dwa odrębne klastry w tej samej sieci - co sprawdziłem i stwierdzam, że funkcjonuje to poprawnie (plik cluster-service.xml jest dostępny w konfiguracji all). Problemem, jaki należy później jeszcze rozwiązać jest skonfigurowanie plików EJB 3, które usuwałem, tak, aby nie kolidowały z odpowiednikami, jakie znajdują się w naszej sieci lokalnej.
