Es lohnt sich, von JBoss 5.1 auf JBoss 7.1 zu aktualisieren

8

Derzeit läuft in unserer Produktionsumgebung JBoss 5.1 und wir diskutieren darüber, ob es sich lohnt, auf JBoss 7.1 zu migrieren. Wenn es ein einfaches Serverupgrade wäre, wäre das kein Problem. Aber leider müssten wir die Konfigurationen ändern, und das würde einige Anstrengungen erfordern. Außerdem läuft unser Server in einem Cluster und ich lese, dass JBoss 7.1 mehr Cluster-Unterstützung hat.

Also ist es das wert oder nicht?

Danke

    
Mig56 20.04.2012, 15:16
quelle

4 Antworten

12

Wir befinden uns zur Zeit in der gleichen Situation.

Es gibt eine Menge Dinge auf der positiven Seite:

  • Wir müssen an einem Punkt von 5.1 abwandern. Wir brauchen das volle Profil und es gibt nicht so viele OSS-Alternativen (GlassFish und vielleicht Geronimo). Dieser Punkt allein wird wahrscheinlich die Migration verkaufen, da PCI-DSS uns verbietet, EoL-Software zu verwenden.
  • Die Konfiguration ist so viel besser und einfacher. Es verteilt sich nicht mehr auf 20 XML-Dateien, in denen Sie Aspekte in XML-Dateien an einem zentralen Ort konfigurieren. Alle Ports sind an einer zentralen Stelle konfiguriert. Es gibt keine XSL-Datei mehr, die server.xml transformiert. Sie können die Konfigurationsdatei verstehen, ohne die Implementierungsdetails von Klassen zu kennen. Es ist schwer zu verstehen, wenn Sie noch nie einen JBoss konfiguriert haben.
  • Das EJB-Remoting verwendet keinen Thread pro Socket mehr.
  • Das Entfernen eines Subsystems, das Sie nicht benötigen, ist so viel einfacher.
  • Das Class-loding-Modell sieht normal aus und Sie erhalten eine Menge Kontrolle durch jboss-deployment-structure.xml
  • Die EJB-Client-Bibliothek sieht viel aufgeräumter aus. Es sind 10 JARs von 20, die Hälfte von ihnen sind sogar OSGi-Bundles (unser Client ist eine Eclipse RCP-Anwendung).
  • Obwohl wir nicht gerade begeistert von Java EE 6 sind, das einige unserer SLSBs durch @Singleton-Beans ersetzt, und einige unserer SARs mit Timer-EJBs sehen sicherlich interessant aus.
  • Schnellerer Start und weniger Speicherverbrauch (zumindest für einen leeren Server oder kleine Bereitstellungen). Wir haben noch keine große Bereitstellung getestet.
  • Der Bereitstellungsordner ist standardmäßig leer

Dinge, die wir noch untersuchen müssen:

  • Wir machen uns Sorgen um die Leistung von Infinispan. Wir verwenden derzeit die TreeCache-API von JBoss Cache. Zwar gibt es einen Adapter für Infinispan, der dieselbe API bereitstellt, einige theoretische Tests zeigen jedoch eine schlechtere Schreibleistung. Dies gilt nur für die Tree-API von Infinispan.
  • ExternalContext wird nicht mehr unterstützt, wir verwenden es derzeit, um einen JNDI-Baum aus einer .bindings-Datei
  • zu füllen
  • Die JMX-Konsole ist weg, wenn Sie etwas haben, das darauf basiert, muss es angepasst werden, Bearbeiten Es ist tatsächlich ein Port der JMX-Konsole verfügbar AS7-2227

Wir laufen nicht in einem Cluster, deshalb kann ich dazu nichts sagen.

Was wahrscheinlich der größte Aufwand für uns ist, ist die Migration aller Shell-Skripte (Installation, Integrationstests, ...), die auf die eine oder andere Weise mit JBoss interagieren.

Aktualisieren

Wir sind migriert und es hat sich definitiv gelohnt. Einige Updates zu den oben genannten Punkten:

  • Selbst große Bereitstellungen sind schnell und mit minimalem Tuningaufwand ausgestattet.
  • Die zentralisierte Protokollierung (Slf4j, JUL, JCL, Log4j, ...) ist wirklich nett.
  • 7.1 hat so viele Fehler, dass es für uns unbrauchbar war, also sind wir auf 7.2 / EAP 6.1 und planen, auf 7.3 / EAP 6.2 zu gehen. Es hat immer noch eine Menge Fehler, aber wir können sie umgehen. Wir freuen uns besonders auf eine rollenbasierte Zugriffskontrolle für die Management-Schnittstelle, die es uns ermöglicht, unsere Skripte mit minimalen Privilegien auszuführen.
  • Es wird keine unterstützte Version von GlassFish 4 geben, die ein großes Fragezeichen für die Produktion darstellt.
  • EJB-Remoting-Sicherheit ist viel weniger flexibel. Wir mussten einige Problemumgehungen einbauen, da wir zuvor authentifizierte und nicht authentifizierte EJB-Aufrufe gemischt haben - das ist nicht mehr möglich.
  • Das JEE 6 BOM POM von JBoss ist eine gemischte Tasche. In der Theorie ist es nett, weil es die Versionen aller Sie JEE-Abhängigkeiten verwaltet. In der Praxis sind die Koordinaten schrecklich mit der Version in der artifactId, die bei der Migration zu JEE 7 störend sein wird. Außerdem ist es nicht sehr hilfreich, wenn Sie eine Implementierung einer JEE-API für Tests integrieren möchten.
  • Infinispan tree API-Leistung war kein Problem.
  • Wir haben die JMX-Console-Skripte durch DMR-Skripte ersetzt.

Update 2

  • Es gibt einen Deadlock , wenn EJB-Remoting über SSL verwendet wird. Dieser Deadlock ist auch in EAP 6.2 vorhanden. Wir sind jetzt an dem Punkt, an dem wir eine ganze Reihe von Funktionen haben, die von WildFly nach AS 7 zurückportiert wurden.
Philippe Marschall 22.04.2012, 15:37
quelle
1

Funktioniert alles auf JBoss 5.1.0 für Sie? Ist Ihre Leistung etwas, womit Sie leben können?

Ich bin gerade dabei, von JBoss 5.1.0GA auf JBoss 7.1.1 zu aktualisieren, und es war nicht einfach. Sie aktualisieren im Grunde auf einen neuen Anwendungsserver. Sie müssen eine Menge Dollar für diese Bemühung einplanen, die ich rate.

Nachdem wir gesagt haben, dass JBoss 7.1.1 im Vergleich zu 5.1.0 (mindestens Startzeiten) sehr schnell ist. Ich denke, in den nächsten 6 Monaten (oder so) werden die meisten "harten" Migrations- und Übergangsprobleme in den jboss-Foren oder durch Fehlerbehebungen konkretisiert. An diesem Punkt können Sie und Ihr Team neu bewerten, ob Sie die Migration durchführen möchten.

Viel Glück!

    
madchedar0 12.06.2012 16:50
quelle
1

Wenn Sie SSL verwenden, ist ein Vorteil des Upgrades, dass JBoss 7.1.1 auf jdk 1.7 läuft, welches Unterstützung für TLS 1.1 & amp; 1.2, während jdk 1.6 nur bis zu TLS 1.0 unterstützt. JBoss 5 wird nicht auf Java 1.7 ausgeführt, so dass Sie anfällig für einen BEAST-Angriff sind.

    
Mark L 12.03.2013 02:45
quelle
1

Egal, ich würde ein bisschen warten.

AS 5 ist ein EE5-Server, AS 7.1 ist ein EE6-Server (und EE6-Spezifikation kam 2009 heraus). Das ist eine Menge Arbeit für eine ausgezeichnete neue Laufzeitumgebung, aber es wird Ihnen keine heißen architektonischen Möglichkeiten geben.

Die WildFly 8.0.0.CR1 ist bereits fällig und der EE7 Server bringt Ihnen eine Menge neuer interessanter Entwicklungsmöglichkeiten, wie WebSockets und JAX-RS 2.0 ( Ссылка ). Neue Verwaltungsfunktionen wie Single Instance Patching Und es ist nicht sicher, dass AS7-to-WildFly8 eine super-einfache Migration sein wird, da einige neue Dinge eingeführt werden, wie Undertow statt JBossWeb / Tomcat.

Wenn du gehen musst, musst du gehen - und wenn du den toten 7.x-Pfad runterwindest, vergiss nicht, dein viel verbessertes 7.2.0.Final-Tag in die Finger zu bekommen (einige hundert Probleme besser als 7.1. 1). Aber wenn Sie denken, dass Sie jetzt mit Beta / CR-Releases mit der Entwicklung / Migration beginnen können und einige Monate auf eine schöne, produktionsstabile Version von WildFly 8.x.x warten, können Sie vielleicht bis zum nächsten großen Update noch etwas länger sitzen.

br, Jens

    
Jens X Augustsson 08.12.2013 18:43
quelle