Czy warto zaktualizować JBoss 7.1 z JBoss 5.1?

Question

Obecnie nasze środowisko produkcyjne obsługuje JBoss 5.1 i debatowaliśmy nad tym, czy warto go migrować do JBoss 7.1. Gdyby to było proste uaktualnienie serwera, nie byłoby problemu. Ale niestety musielibyśmy zmienić konfiguracje i wymagałoby to trochę wysiłku. Ponadto nasz serwer działa w klastrze i czytałem, że JBoss 7.1 ma więcej wsparcia dla klastrów.

Czy warto, czy nie?

Dzięki

Answer 1

Jesteśmy obecnie w tej samej sytuacji.

Wydaje do wielu rzeczy na pozytywne strony:

• Będziemy musieli przenieść się w jednym punkcie 5.1. Potrzebujemy pełnego profilu i nie ma zbyt wielu alternatywnych rozwiązań OSS (GlassFish i być może Geronimo). Tylko ten punkt prawdopodobnie sprzedaje migrację, ponieważ PCI-DSS zabrania nam używania oprogramowania EoL'd.
• Konfiguracja jest o wiele lepsza i prostsza. Nie rozciąga się już na 20 plików XML, w których konfigurujesz aspekty w plikach XML, ale jedno centralne miejsce. Wszystkie porty są skonfigurowane w jednym centralnym miejscu, nie ma już pliku XSL, który przekształca plik server.xml. Możesz zrozumieć plik konfiguracyjny bez znajomości szczegółów implementacji klas. Ciężko to docenić, jeśli nigdy nie skonfigurowałeś JBossa.
• Usługa zdalnego odłączania EJB nie używa już wątku na gniazdo.
• Usunięcie podsystemu, którego nie potrzebujesz, jest o wiele łatwiejsze.
• Model składowania klas wygląda na przyzwoity i uzyskujesz dużą kontrolę dzięki jboss-deployment-structure.xml
• Biblioteka klienta EJB wygląda o wiele bardziej oczyszczona. Dochodzi do 10 JARów z 20, połowa z nich to nawet pakiety OSGi (naszym klientem jest aplikacja Eclipse RCP).
• Chociaż nie jesteśmy zbyt podekscytowani faktem, że Java EE 6 zastępuje niektóre z naszych SLSB fasolą @Singleton, a niektóre z naszych SAR z timerem, EJB na pewno wyglądają interesująco.
• Szybsze uruchamianie i mniejsze zużycie pamięci (przynajmniej dla pustego serwera lub małych wdrożeń). Nie testowaliśmy jeszcze dużego wdrożenia.
• Folder wdrożeń jest domyślnie pusta

rzeczy, które musimy jeszcze zajrzeć do:

• Jesteśmy trochę zaniepokojony wydajności Infinispan. Obecnie korzystamy z interfejsu API TreeCache w JBoss Cache. Chociaż istnieje adapter dla Infinispan, który zapewnia ten sam interfejs API, niektóre testy teoretyczne wykazują gorszą wydajność zapisu. Dotyczy to tylko API drzewa Infinispan.
• ExternalContext nie jest już obsługiwany, obecnie używać go do wypełniania drzewa JNDI od pliki .bindings
• konsoli JMX nie ma, jeśli masz coś, bazującą na ten musi być dostosowany, Edit istnieje w rzeczywistości dostępny jest port konsoli JMX AS7-2227

Nie uruchamiamy w klastrze, więc nie mogę tego komentować.

To, co prawdopodobnie będzie dla nas największym wyzwaniem, to migracja wszystkich skryptów powłoki (instalacja, testy integracyjne, ...), które współdziałają w taki czy inny sposób z JBoss.

Aktualizacja

Mamy migracji i na pewno było warto. Niektóre aktualizacje powyższych punktów:

• Nawet duże wdrożenia są szybkie przy minimalnych modyfikacjach.
• Scentralizowane logowanie (Slf4j, JUL, JCL, Log4j, ...) jest naprawdę miłe.
• 7.1 ma tak wiele błędów, że nie nadaje się do użytku, więc jesteśmy na 7.2/EAP 6.1 i planujemy przejść do 7.3/EAP 6.2. Nadal ma sporo błędów, ale możemy je obejść. Z niecierpliwością czekamy na kontrolę dostępu opartą na rolach dla interfejsu zarządzania, która pozwoli nam uruchamiać nasze skrypty z minimalnymi przywilejami.
• Nie będzie obsługiwanej wersji GlassFish 4, która stawia na niej duży znak zapytania do użytku produkcyjnego.
• Zabezpieczenia zdalne EJB są o wiele mniej elastyczne. Musieliśmy wprowadzić pewne obejścia, ponieważ wcześniej miksowaliśmy uwierzytelnione i nieuwierzytelnione połączenia EJB - nie jest to już możliwe.
• JEE 6 POM POM z JBoss to torba mieszana. Teoretycznie jest to miłe, ponieważ zarządza wersjami wszystkich zależności JEE. W praktyce współrzędne są okropne w przypadku wersji w artefactId, która będzie irytująca, gdy przeprowadzimy migrację do JEE 7. Nie jest też bardzo pomocne, jeśli chcesz dołączyć implementację interfejsu API JEE do testów.
• Działanie interfejsu API drzewa infinispan nie było problemem.
• Zastąpiliśmy skrypty JMX-Console skryptami DMR.

Aktualizacja 2

• Jest deadlock podczas korzystania z usług zdalnych EJB przez SSL. Ten impas występuje nawet w EAP 6.2. Jesteśmy teraz w punkcie, w którym mamy całkiem zestaw poprawek funkcji przeniesionych z WildFly do AS 7.

Answer 2

Czy wszystko działa na JBoss 5.1.0 dla ciebie? Czy twój występ jest czymś, z czym możesz żyć?

Jestem obecnie w trakcie aktualizacji z JBoss 5.1.0GA do JBoss 7.1.1 i nie było to wcale łatwe. Zasadniczo aktualizujesz do nowego serwera aplikacji. Będziesz musiał wydać dużo pieniędzy na ten wysiłek.

Powiedziawszy, że JBoss 7.1.1 jest BARDZO szybki w porównaniu do 5.1.0 (przynajmniej czas uruchomienia). Myślę, że w ciągu najbliższych 6 miesięcy (lub tak) większość "trudnych" kwestii związanych z migracją i przejściami zostanie rozwiązana na forach jboss lub poprzez poprawki błędów. W tym momencie Ty i Twój zespół możecie dokonać ponownej oceny, jeśli chcecie przeprowadzić migrację.

Powodzenia!

Answer 3

Jeśli korzystasz z protokołu SSL, jedną z korzyści do uaktualnienia jest to, że JBoss 7.1.1 działa na jdk 1.7, który obsługuje TLS 1.1 & 1.2, a jdk 1.6 obsługuje tylko do TLS 1.0. JBoss 5 nie będzie działał na java 1.7, więc jesteś podatny na atak BEAST.

Answer 4

Bez względu, poczekałbym trochę.

AS 5 to serwer EE5, AS 7.1 to serwer EE6 (specyfikacja EE6 została wydana w 2009 r.). To dużo pracy dla doskonałego nowego środowiska uruchomieniowego, ale nie daje żadnych gorących możliwości architektonicznych.

WildFly 8.0.0.CR1 jest już należny, a to serwer EE7 oferujący kilka nowych, interesujących możliwości rozwoju, takich jak WebSockets i JAX-RS 2.0 (http://www.slideshare.net/dandreadis/2013-11devoxxwild-flybof). Nowe funkcje administracyjne, takie jak łatanie pojedynczych wystąpień. Nie jest też pewne, czy AS7-to-WildFly8 będzie bardzo łatwą migracją od czasu wprowadzenia czegoś nowego, jak Undertow zamiast JBossWeb/Tomcat.

Jeśli musisz iść, musisz odejść - i jeśli pokonasz martwą ścieżkę 7.x, nie zapomnij wziąć w swoje ręce ulepszonego znacznika 7.2.0.Final (kilkaset błędów lepiej niż 7.1 .1). Ale jeśli myślisz, że możesz zacząć rozwijać/migrować teraz, używając wydań Beta/CR i poczekać kilka miesięcy na fajną stabilną produkcję WildFly 8.x.x, możesz być w stanie usiąść na dłużej przed kolejną ważną aktualizacją.

br, Jens