Is it worth upgrading to JBoss 7.1 from JBoss 5.1

Question

Currently our production environment runs JBoss 5.1 and we have been debating whether or not its worth migrating to JBoss 7.1. If it was a simple server upgrade, then it wouldn't be a problem. But, unfortunately, we would have to change configurations and that would take some effort. Also, our server runs in a cluster and I read that JBoss 7.1 has more cluster support.

So is it worth it or not?

Thanks

Atli

Answer 1

We're currently in the same situation.

There seem to a a lot of things on the positive side:

• We'll have to migrate off 5.1 at one point. We need full profile and there are not that many OSS alternatives (GlassFish and maybe Geronimo). That point alone will probably sell the migration since PCI-DSS forbids us to use EoL'd software.
• The configuration is so much better and simpler. It's no longer spread over 20 XML files in which you configure aspects in XML files but one central place. All ports are configured in one central place, there is no longer an XSL file that transforms server.xml. You can make sense of the configuration file without knowing the implementation details of classes. It's hard appreciate this if you've never configured a JBoss.
• The EJB remoting no longer uses a thread per socket.
• Removing a subsystem you don't need is so much easier.
• The class loding model looks sane and you get a lot of control through jboss-deployment-structure.xml
• The EJB client library looks much more cleaned up. It's down to 10 JARs from 20, half of them are even OSGi bundles (our client is an Eclipse RCP application).
• While we're not too excited about Java EE 6 replacing some of our SLSBs with @Singleton beans and some of our SARs with timer EJBs certainly looks interesting.
• Faster start up and less memory usage (at least for an empty server or small deployments). We haven't yet tested a large deployment.
• The deployments folder is empty by default

Things that we still need to look into:

• We're a bit worried about Infinispan performance. We currently use the TreeCache API of JBoss Cache. While there is an adapter for Infinispan that provides the same API some theoretical tests show worse write performance. This only applies to the tree API of Infinispan.
• ExternalContext is no longer supported, we currently use it to populate a JNDI tree from a .bindings file
• JMX console is gone, if you have anything that builds on this it needs to be adapted, Edit there is actually a port of JMX-Console available AS7-2227

We don't run in a cluster so I can't comment on that.

What will probably be the biggest effort for us is migrating all the shell scripts (installation, integration tests, …) that interact in one way or another with JBoss.

Update

We have migrated and it was definitely worth it. Some updates to the points above:

• Even large deployments are fast with minimal amounts of tuning.
• The centralized logging (Slf4j, JUL, JCL, Log4j, …) is really nice.
• 7.1 has so many bugs it was unusable for us, so we are on 7.2 / EAP 6.1 and plan to go to 7.3 / EAP 6.2. Still has its fair share of bugs but we can work around them. We're especially looking forward to role-based access control for the management interface which will allows us to run our scripts with minimal privileges.
• There will not be a supported version of GlassFish 4 which puts a big question mark on it for production use.
• EJB remoting security is a lot less flexible. We had to put in some workarounds since previously we were mixing authenticated and unauthenticated EJB calls — this is no longer possible.
• The JEE 6 BOM POM from JBoss is a mixed bag. In theory it is nice because it manages the versions of all you JEE dependencies. In practice the coordinates are horrible with the version in the artifactId which is going to be annoying when we migrate to JEE 7. Also it isn't very helpful when you want to include an implementation of a JEE API for tests.
• Infinispan tree API performance was not an issue.
• We replaced the JMX-Console scripts with DMR scripts.

Update 2

• There is a deadlock when using EJB remoting over SSL. This deadlock is present even in EAP 6.2. We're now at the point when we have quite a patch set of features backported from WildFly to AS 7.

Dorcus

Answer 2

Is everything working on JBoss 5.1.0 for you? Is your performance something you can live with?

I'm currently in the middle of upgrading from JBoss 5.1.0GA to JBoss 7.1.1 and it has not been easy at all. You're basically upgrading to a new application server. You will need to budget a lot of dollars for this effort I'm guessing.

Having said that JBoss 7.1.1 is VERY fast compared to 5.1.0 (start up times at least). I think in the next 6 months (or so) most of the "hard" migration and transition issues will be fleshed out in the jboss forums or through bug fixes. At that point you and your team can reevaluate if you want to do the migration.

Good luck!

Toliver

Answer 3

If you are using SSL, one advantage to upgrading is that JBoss 7.1.1 runs on jdk 1.7, which has support for TLS 1.1 & 1.2, while jdk 1.6 only supports up to TLS 1.0. JBoss 5 will not run on java 1.7 so you are susceptible to a BEAST attack.

Vshaped

Answer 4

Regardless, I'd wait a bit.

AS 5 is a EE5 server, AS 7.1 is a EE6 server (and EE6 spec came out in 2009). So that's alot of work for an excellent new runtime environment, but it won't give you any hot architectural possibilities.

The WildFly 8.0.0.CR1 is already due and that's EE7 server bringing you a bunch of new interesting developing possibilitites, like WebSockets and JAX-RS 2.0 (http://www.slideshare.net/dandreadis/2013-11devoxxwild-flybof). New admin features like Single Instance Patching. And it's not sure that AS7-to-WildFly8 will be a super-easy migration since som major new stuff is introduced, like Undertow instead of JBossWeb/Tomcat.

If you gotta go, you gotta go - and if U wind down the dead 7.x path, don't forget to get your hands on the much improved 7.2.0.Final tag (several hundred issues better that 7.1.1). But if you think you can start developing/migrating now using Beta/CR releases and wait some months for a nice production-stable WildFly 8.x.x release, you might be able to sit tight longer before next major update.

br, Jens

Ixia