JBoss 7 was released yesterday to significantly more fanfare than the poorly timed release of JBoss AS 6, whose December 29th release date spurned rumours that the marketing team had been taken over by a bunch of Christmas hating miscreants who had no idea that the majority of their consumer base might be inerested in doing something other than downloading distribution binaries and playing around on port 8080 two days before the first of January.

But the marketing team didn’t make the same mistake twice, spacing some good room between the recent long weekend and yesterday's big announcement. And judging by the comments and quips generated by the twitiverse yesterday, it would appear that doing a big product release in the middle of a typical workweek isn’t such a bad idea.

Playing in the JBoss AS 7 Sandbox

Yes, JBoss proved that most Enterprise Java Professionals really aren’t busy enough at work these days, as everyone from Java Superstar Matt Raible (rhymes with cable), to the lowly editor of TheServerSide, were busy downloading, installing, and playing around with the newly released software instead of doing the work they're actually being paid to do.

 

On a side note, one of the most highly retweeted comments actually came from JSF-hater Matt Raible, mraible #Tomcat7 startup time: 69ms, #JBossAS7: 3127ms. Startup with ajax-login.war in webapps/deployments? Tomcat: 15985ms, JBoss: fails in 154ms. Which was followed up by this tweet: mraible Reason why #JBossAS7 fails to deploy Ajax Login? It doesn't like #Spring, which seems logical. http://bit.ly/n4gP82

 

Speed and AS 7: Not Just Lip-Service

But indeed, the big news surrounding this whole release is speed: speed, speed, speed. JBoss 7 is fast, super fast in fact, and the reason it’s super fast is because of the modular approach to development, a theme that has become more than a trend in the enterprise Java community.

Now we keep hearing this story over and over again. The GlassFish server is lightning fast because of their modular approach to development, and the Oracle JDeveloper team swears by OSGi. Says Duncan Mills, senior director of product management for Oracle's Application Development Tools, about the latest, lightning fast, JDeveloper release,  “The big speed improvement we saw is really due to the OSGI framework that we have adopted for our plug-ins. Because we moved to that framework, it's actually reduced our startup time rather dramatically, by a factor of two to three, depending on what you have been previously noting.”

But here’s the thing: the JBoss team didn’t use OSGi. JBoss AS 7 does indeed support OSGi, and we will see a huge number of OSGi applications being deployed to it, there’s no doubt about that. In fact, the manner in which the JBoss application server was designed makes AS 7 a pretty hospitable place for OSGi applications. “Thanks to the similarity in the design, OSGi support is available out of the box, built as a layer above JBoss Modules and the Module Service Container (MSC).”

But apparently OSGi was a little too de rigueur for the JBoss 7 AS team. They instead chose their own JBoss modules, a precursor to what should be a JSR 294 (Java modules) compliant implementation. But as it stands now, this is simply a vendor specific module implementation.

But the bottom line is that the modular approach has worked, regardless of whether it was OSGi or a forward looking pre-cursor to Java 7 Modules. “AS 7 does classloading right. It uses JBoss Modules to provide true application isolation, hiding server implementation classes from the application and only loading the classes your application needs. Modules, packaged as collections of classes, are peers that remain isolated unless explicitly defined as a dependency of another module. Visibility rules have sensible defaults, yet can be customized.”

So, speed, ease of use, modularity and incremental deployment are the big features that the JBoss team is decrying with the latest release of their application sever. And from the community response so far, it seems like AS 7 is a winning pitch.

 

I haven't tried JBoss 7 yet (or WebSphere 8 for that matter) but it sound promising (despite the issues ran into by Matt that I'm sure is due to resolvable jar conflicts). I'll have to give it a spin as soon as possible...

Cameron,

Nice overview of JBoss AS7!

Since you mentioned Matt's tweet, it would be fair to also clarify that the deployment problem is caused by an issue related to Spring Modules, a long time unmaintained unofficial extension to Spring, which contains an invalid TLD as tweeted (and re-tweeted) here: http://twitter.com/#!/MariusBogoevici/status/90929033923141632. That being said, there is always room for being more forgiving in such cases if needed, but it's nothing that cannot be taken care of on a mailing list, JIRA, etc.

And since we are at the topic: for those interested in a "Getting Started" experience with Spring and JBoss AS7, I strongly recommend a reading of  http://community.jboss.org/blogs/mariusb/2011/07/13/spring-and-jboss-as7-part-1-getting-started.

Cheers,

Marius

Coming from Matt, I was sure it was something like that :-).

Marius this thread is much more relevant to the discussion on speedup and modularity. http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003095.html Here we have JBoss Modules in JBoss AS 7 hiding resources located in a JVMTI agent library jar added to the classpath by way of the standard -javaagent JVM argument from nested classloaders which are being instrumented by the agent itself. This kinda worked in JBoss AS 7 with the crude use of a system -Djboss.modules.system.pkgs=com.jinspired,org.jinspired which anyone with some OSGi pain experience will immediately recognize. This was needed to get nearly all JVMTI agents to work. In CR1 it was completely broken. In Final it worked for only ONE classloader - the one responsible for bootstrapping the modules system. If it for this reason I have long argued for modularity to be done solely by the VM vendors because they understand much more comprehensively the contracts that exist across the various technologies such as JVMTI that must be supported. I would expect them not to so easily break such things for the sake on one ideal or feature as has been the case with OSGi and now JBoss Modules (I see the system property as a symptom of an underlying design flaw).

I'm sorry you feel that way, though I find your conclusion to be uninformed, and driven by frustration rather than logic.  I do not know what is wrong with your setup; I still need more information.  The system packages property does indeed work for all class loaders (I've tested it locally) so there must be some other factor in play.

As for calling it an "underlying design flaw" - I'm sure you're not seeing the big picture.  Flat classpaths have inherent problems and limitations that were significant enough to us to warrant the new approach.  We are satisfied with the result; it reduces our distribution size, our startup time, and improves runtime perfomance substantially.  I assure you that we have a complete and thorough understanding of the contracts that exist in the VM, and we have used a number JVMTI agents successfully locally.

At most, there is a class loader bug which has nothing to do with any design flaw; perhaps related to resource loading from system packages.  Overall, technical support questions are better kept to the mailing list.  This is a community project with no support agreements; we strive to reply to inquiries as time allows, but thus far I haven't had the time to dig into your problem.  If there is any more information you can supply, please do so; I will try to get to it today (but I may not be able to, due to child care reasons).

David it is about bolting this onto to the runtime. I don't think this property is ideal and I really hope you don't think it is. It is necessary because without nothing worked (for any JVMTI agent) when this option was not available because whilst the agent was able to instrument the class via transformations the outbound calls never resolved. Already there are a number of issues reported in which this has been referenced as a solution. Now customers and vendors must use this without any collisions such as disabling another solution that requires it.

This is already a problem in the standalone.conf and domain.conf scripts which amazingly have this uncommented by default.

JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=org.jboss.byteman"

So later on down in the script a vendor adds -Djboss.modules.system.pkgs=... to the JAVA_OPTS and we now have two property settings on the command line and how knows which one will be used because I doubt the behavior of this is specified anywhere across VM implementations.

The module system has to be much more intelligent and/or tolerant. Modularity should not always assume its only recourse is class|loader hiding because this does not even begin to address other issues with state management that will never be addressed fully even across multiple isolates.

David it is about bolting this onto to the runtime. I don't think this property is ideal and I really hope you don't think it is. It is necessary because without nothing worked (for any JVMTI agent) when this option was not available because whilst the agent was able to instrument the class via transformations the outbound calls never resolved.

You'll want to brace for the future then, because a flat classpath will be a thing of the past when Java 8 arrives.  You're not going to convice me that setting a system property for an agent is so onerous that it makes modularity not worthwhile.  We've been down the flat classpath road and it only ends in pain and complexity.  There is a lot of complexity - a lot - that we'd have to add to Modules to even get close to equalling what is necessary to make the app server work properly with the flat classpath model.  I'm sorry you don't see the elegance in the design that we see, but we're not going anywhere, so please direct your vitriol elsewhere.

we're not going anywhere - David Lloyd, RedHat 

No truer statement has been made by a JBoss developer ;-)

Anyway I have identified the change that broke things with an ominous title. I hope the JVM guys will at least recognize the existing contractual requirements within the JVMTI specification or at least make announcements of the change which they understood to be making.

MODULES-89: make sure ModuleClassLoader lives in complete isolation and use package name to load package spec
https://github.com/jbossas/jboss-modules/commit/2046885497316d66ca0682b4a83fe8fad4cb0ccc#src/main/java/org/jboss/modules/ModuleClassLoader.java

If you want complete isolation put the service in another process.

I'd have to say that one can get enormous mileage out of a flat classpath -- even when using dozens and dozens of open source libraries, as long as one is prepared for a latest-and-greatest-version approach to dependencies and updating one's code accordingly.

One can deal then with cases where this approach hits a brick wall on a special-case basis rather than trying to reshape one's whole world to deal with this issue -- one which should be a non-issue in most cases if you're willing to keep your code up-to-date and insist on libraries that remain up-to-date as well.

Geez man. It hasn't even been 24 hours since you reported your problem!

Guys it has nothing to do with the speed of resolution itself. I think you are just never going to cover all such cases. Apologies to some that might find this offensive but I think modularity attempted outside of the VM itself is liking "pissing in the wind". This is likely to eat up a considerable amount of the JBoss support and development time and to be honest the benefits are questionably at least to customers. Having JBoss modular is a noble goal having this modularity exposed to customers in such issues and additional work on dependency to get things to work when all they care about is performance, reliability, scalability....which is not directly addressed by such endeavors (there was a lot of low hanging fruit to improve on in terms of speed).

I should point out that the last time JBoss attempted to change its classloader mechanism for questionable performance benefits it broke the resource loading contract in exactly the same way. That time I was fortunate to find the issue before it went final. This time I took my eye off the ball for the CR1/Final releases and history repeated itself and I suspect it will happen again and again. It's not necessarily about engineering talent its the nature of the beast (VM) at this stage in its maturity and size. OSGi has shown that even after 10 years its a losing battle in fighting what existed before and currently out in the wild.

Adrian Cole of jclouds fame recently ask me for a quote with regard to start-up performance which I think might be useful here.

Everybody wants software to be faster but unfortunately though we could try to make everything faster it is simply not cost effective. What distinguishes a performance engineer from a developer (with a profiler) is that the performance engineer is always check pointing his/her past, present and predictive progress with effort (cost) and return (value). Added to this there are always trade offs in any performance optimization and its ongoing management. Just like with quality of service (QoS) someone or something generally loses (or incurs additional cost) whilst gains (or resources) are shifted elsewhere. So should a huge amount of effort be expended on start-up time? I think the only justification for this assuming this effort could be better spent elsewhere is that (1) there is only ever one instance of a server and if it goes down we need it to go up immediately because there is no plan B (2) our servers go and down likes yo-yos to such an extent that that is all they actually do. Granted having a quick start-up time allows us to determine very quickly that indeed the service is started without having to second guess and pray for a period of time. It all sounds wonderful and aligned to the elasticity nature of the cloud but I think if you really want speed then don't stop and start and always have them online but not necessarily assigned to one single application, service, or customer just like in the telecommunication domain. If the effort in going from a few seconds startup time to 1 second could have been spent shaving off 0.1 seconds from the normal processing of a single request which happens a billion times a day one would have to call into question the goals and objectives of such an exercise by a developer.

"How fast and at what cost?" 

Startup time has only meaning to developers. Users are more focused on response time and operations on resource consumption (clock, cost, capacity, control,...), utilization and workload throughput.

I don't think the reduced startup time that Glassfish promoted many moons ago has had much of an impact past the sell by date in their growth though it would be hard to separate this from other factors.

Memory footprint reduction is something more interesting as it can gives us a much greater degree of isolation and possibly resilience by being able to have many more instances running assuming the inter/intra process communication is not too chatty across services deployed separately.

 

Startup time has only meaning to developers. [...]

I don't think the reduced startup time that Glassfish promoted many moons ago has had much of an impact past the sell by date in their growth though it would be hard to separate this from other factors.

At many smaller companies and especially startups, it's the developers who choose the technology (I actually think this should always be the case, but that's another story). I know many developers who curse profoundly at the sometimes insanely slow startup of JBoss AS 6.

Although a non-debug startup without any applications deployed to it only takes 10 seconds on a relatively fast machine (i7, 8GB, SSD) it can take up to 7 minutes for a debug startup with a medium sized EAR (e.g. 100MB exploded) on something like an i3 based laptop with 4GB and an HDD.

7 minutes is an absolutely insane amount of time. I'm not sure how often this happens, but I've seen it happen and it's not pretty. Developers experiencing this tend to avoid JBoss AS. Developers avoiding JBoss tech is bad for JBoss. The end-users don't know about JBoss, developers do.

If an appserver is taking minutes to start up I doubt any optimization that has been made (under the guise of modularity) will have much of an impact because clearly its an application issue. But you could always have a server start up in seconds but have the first request take minutes to service and its runs through the initialization code it deferred. I think this is what is missing for this dialog. Has the removed been eliminated (tuned) or deferred (masked) until another time or more appropriate execution point.

But you are right excessive logging which is the default for previous JBoss server releases does create a latency drag especially in startup mode which is generally (or in large part) done in a single thread.

Again developers should always try to use their own software to keep a good balance in their prioritization's. The DevOps movement might encourage this more so as they emphasis in less on startup but more so on scalability, availability, manageability, performance,.....

If an appserver is taking minutes to start up I doubt any optimization that has been made (under the guise of modularity) will have much of an impact because clearly its an application issue.

I wonder. The cases where I saw this slow startup the app itself wasn't actively executing any code at all during startup. It were just a bunch of annotated EJB beans, JPA entities, JSF managed beans a ton of jar files in the war module and a couple of datasources and JMS resources inside the ear module.

Things that seemed to slow the startup down was an excessive copying of jar files and unpacking them to the filesystem (not nice on the HDD based laptop) and seemingly a very slow annotation scanning and DI resolution. On the fast system with plenty of IO, during the entire startup a single core was at 100%. Since many workstations now have at least 4 real cores (or 8th virtual ones), the entire thing could go about 4 to 8 times faster if parallelism was sufficiently exploited. I think this is one of the things the JBoss people did.

 

But you could always have a server start up in seconds but have the first request take minutes to service and its runs through the initialization code it deferred. I think this is what is missing for this dialog. Has the removed been eliminated (tuned) or deferred (masked) until another time or more appropriate execution point.

Hmmm, good point. Indeed, a more complete benchmarking would include the startup immediately followed by a simple request (e.g. only hitting the web layer) and a more complex request (calling through to the EJB and JPA layers).

Congratulations on the release! It seems the JBoss team has been working incredibly hard on this, and the faster startup speed was much overdue.

I do have some reservations about the release. I'm not sure I actually consider the inability to deploy datasources (the famous *-ds.xml files) a feature I've been waiting for. I don't understand this at all. It's not a feature by any means! Maybe I understood incorrectly (and I'd love to be corrected), but it seems it's now required to add datasources in a global JBoss configuration file instead of simply deploying a *-ds.xml or including this file inside an ear or war.

Another point of concern is that JBoss AS 7 is still not Java EE 6 certified and that contrary to JBoss AS 6 is not even fully Java EE 6 compatible anymore. I guess this will happen eventually with a JBoss AS 7.1 or maybe 7.2 as I'm absolutely sure the JBoss developers are completely dedicated to make this happen, but it's something to watch out for when using AS 7.0.

 

I'm testing the JBoss OSGi 7 ...

thank youuu very muchh

Hello,

If you have even a passing interest in the topic of , then you should take a look at the following information. This enlightening article presents some of the latest news on the subject of .

 

How can you put a limit on learning more? The next section may contain that one little bit of wisdom that changes everything pass4sure 1z0-536.

JBoss 7 was released yesterday to significantly more fanfare than the poorly timed release of JBoss AS 6, pass4sure 000-107 whose December 29th release date spurned rumours that the marketing team had been taken over by a bunch of Christmas hating miscreants who had no idea that the majority of their consumer base might be inerested in doing something other than downloading distribution binaries and playing around on port 8080 two days before the first of January pass4sure 642-188.  

This article's coverage of the information is as complete as it can be today. But you should always leave open the possibility that future research could uncover new facts pass4sure 646-204.