Vale la pena eseguire l'aggiornamento a JBoss 7.1 da JBoss 5.1

Question

Attualmente il nostro ambiente di produzione esegue JBoss 5.1 e abbiamo discusso se valga la pena di migrare a JBoss 7.1. Se si trattasse di un semplice aggiornamento del server, non sarebbe un problema. Ma, sfortunatamente, dovremmo modificare le configurazioni e ciò richiederebbe un certo sforzo. Inoltre, il nostro server funziona in un cluster e ho letto che JBoss 7.1 ha più supporto per i cluster.

Quindi ne vale la pena o no?

Grazie

Answer 1

Attualmente siamo nella stessa situazione.

ci sembrano un un sacco di cose dal lato positivo:

• Dovremo migrare fuori 5.1 ad un certo punto. Abbiamo bisogno di un profilo completo e non ci sono molte alternative OSS (GlassFish e forse Geronimo). Probabilmente questo punto venderà la migrazione dal momento che PCI-DSS ci proibisce di utilizzare il software EoL'd.
• La configurazione è molto migliore e più semplice. Non è più distribuito su 20 file XML in cui si configurano aspetti nei file XML, ma una posizione centrale. Tutte le porte sono configurate in un punto centrale, non esiste più un file XSL che trasforma server.xml. Puoi dare un senso al file di configurazione senza conoscere i dettagli di implementazione delle classi. È difficile apprezzarlo se non hai mai configurato un JBoss.
• Il servizio remoto EJB non utilizza più un thread per socket.
• La rimozione di un sottosistema non necessario è molto più semplice.
• Il modello di alloggiamento di classe sembra equilibrato e si ottiene un grande controllo tramite jboss-deployment-structure.xml
• La libreria client EJB sembra molto più pulita. Si tratta di 10 JAR a partire da 20, metà dei quali sono addirittura bundle OSGi (il nostro client è un'applicazione Eclipse RCP).
• Mentre non siamo troppo entusiasti di Java EE 6, la sostituzione di alcuni dei nostri SLSB con i bean @Singleton e alcuni dei nostri SAR con timer EJB è sicuramente interessante.
• Avvio più veloce e minore utilizzo della memoria (almeno per un server vuoto o piccole distribuzioni). Non abbiamo ancora testato una grande distribuzione.
• La cartella implementazioni è vuota di default

cose che abbiamo ancora bisogno di guardare in:

• Siamo un po 'preoccupati per le prestazioni Infinispan. Al momento utilizziamo l'API TreeCache di JBoss Cache. Mentre c'è un adattatore per Infinispan che fornisce la stessa API alcuni test teorici mostrano prestazioni di scrittura peggiori. Questo si applica solo all'API dell'albero di Infinispan.
• ExternalContext non è più supportato, al momento lo utilizziamo per popolare un albero JNDI da un file di .bindings
• console JMX è andato, se avete qualcosa che si basa su questo ha bisogno di essere adattato, Modifica c'è in realtà una porta di JMX-Console disponibile AS7-2227

Non eseguiamo in un cluster, quindi non posso commentare su questo.

Quello che probabilmente sarà lo sforzo maggiore per noi è la migrazione di tutti gli script di shell (installazione, test di integrazione, ...) che interagiscono in un modo o nell'altro con JBoss.

Aggiornamento

Abbiamo migrato ed era decisamente la pena. Alcuni aggiornamenti ai punti precedenti:

• Anche le installazioni di grandi dimensioni sono veloci con quantità minime di ottimizzazione.
• La registrazione centralizzata (Slf4j, JUL, JCL, Log4j, ...) è davvero bella.
• 7.1 ha così tanti bug che era inutilizzabile per noi, quindi siamo su 7.2/EAP 6.1 e piano per andare a 7.3/EAP 6.2. Ha ancora una buona dose di errori ma possiamo aggirarli. Attendiamo con impazienza il controllo degli accessi basato sui ruoli dell'interfaccia di gestione che ci consentirà di eseguire i nostri script con privilegi minimi.
• Non ci sarà una versione supportata di GlassFish 4 che pone un grosso punto interrogativo su di essa per l'uso di produzione.
• La protezione remota EJB è molto meno flessibile. Abbiamo dovuto mettere in pratica alcuni stratagemmi poiché prima stavamo mescolando le chiamate EJB autenticate e non autenticate - questo non è più possibile.
• Il POM JEE 6 BOM di JBoss è una borsa mista. In teoria è bello perché gestisce le versioni di tutte le dipendenze JEE. In pratica le coordinate sono orribili con la versione nell'artefatto che sarà noiosa quando migreremo a JEE 7. Inoltre non è molto utile quando si desidera includere un'implementazione di un'API JEE per i test.
• Le prestazioni dell'API dell'albero Infinispan non erano un problema.
• Abbiamo sostituito gli script JMX-Console con gli script DMR.

Aggiornamento 2

• C'è un deadlock quando si utilizzano i servizi remoti EJB su SSL. Questo deadlock è presente anche in EAP 6.2. Siamo ora al punto in cui abbiamo un set di funzionalità abbastanza supportato da WildFly a AS 7.

Answer 2

È tutto ciò che funziona su JBoss 5.1.0 per te? La tua performance è qualcosa con cui puoi convivere?

Attualmente sono al centro dell'aggiornamento da JBoss 5.1.0GA a JBoss 7.1.1 e non è stato affatto semplice. Stai sostanzialmente aggiornando a un nuovo server delle applicazioni. Avrai bisogno di budget di un sacco di dollari per questo sforzo sto indovinando.

Detto questo, JBoss 7.1.1 è MOLTO veloce rispetto a 5.1.0 (tempi di avvio almeno). Penso che nei prossimi 6 mesi (o giù di lì) la maggior parte delle "difficili" migrazioni e problemi di transizione saranno approfondite nei forum di jboss o attraverso correzioni di bug. A quel punto tu e il tuo team potete rivalutare se volete fare la migrazione.

Buona fortuna!

Answer 3

Se si utilizza SSL, un vantaggio dell'aggiornamento è che JBoss 7.1.1 viene eseguito su jdk 1.7, che supporta TLS 1.1 & 1.2, mentre jdk 1.6 supporta solo fino a TLS 1.0. JBoss 5 non funziona su java 1.7, quindi sei suscettibile a un attacco BEAST.

Answer 4

In ogni caso, aspetterei un po '.

AS 5 è un server EE5, AS 7.1 è un server EE6 (e la specifica EE6 è stata pubblicata nel 2009). Quindi è un sacco di lavoro per un eccellente nuovo ambiente di runtime, ma non ti darà alcuna possibilità architettonica.

Il wildfly 8.0.0.CR1 è già dovuto e che del server EE7 portandovi un gruppo di nuovi possibilitites in via di sviluppo interessanti, come WebSockets e JAX-RS 2.0 (http://www.slideshare.net/dandreadis/2013-11devoxxwild-flybof). Nuove funzionalità di amministrazione come Patching di istanze singole. E non è sicuro che AS7-to-WildFly8 sarà una migrazione super-facile da quando vengono introdotte novità importanti, come Undertow invece di JBossWeb/Tomcat.

Se devi andare, devi andare - e se tieni giù il percorso 7.x morto, non dimenticare di mettere le mani sul molto migliorato 7.2.0. Tag finale (diverse centinaia di problemi meglio di 7.1 .1). Ma se pensi di poter iniziare a sviluppare/migrare ora usando le versioni Beta/CR e attendi alcuni mesi per una bella versione WildFly 8.x.x stabile alla produzione, potresti essere in grado di stare seduto più a lungo prima del prossimo aggiornamento principale.

br, Jens