There were a number of comments on twitter and blogs last week discussing Weld's performance and scalability, and I wanted to comment on the issues discussed and our work to resolve them. Upfront, let me say that we have been actively working on performance and scalability for a while now (previously more on memory usage, more recently on performance). Of course, we work primarily with JBoss AS, but also work closely with the GlassFish team; many of the improvements will be directly available as Weld is updated in GlassFish, and we'll continue to support the GlassFish team in any performance work they do on GlassFish that impacts on Weld.
To understand why we didn't release Weld 1.0 with excellent performance and scalability (I would have loved to, of course!) it's worth mentioning a few points. Firstly, Weld was one of entirely new RI's in Java EE 6 (the others being Hibernate Validator and Jersey), and of these is perhaps the biggest, and certainly the most integrated into other parts of Java EE. Secondly, the deadline for the Java EE 6 release (and hence the final release of it's RIs) was very tight (with the CDI spec still undergoing major overhauls up until about 3 weeks prior to the Weld 1.0 release). Thirdly, this was the first release of Java EE that included RIs not produced by Sun, which were fully open source (spec, RI and TCK) which led to the obvious scheduling issues you have when two different teams work together, as well the need to invent new infrastructure (e.g. for running the TCK).
All of these factors together meant that the 1.0 release of Weld primarily focused on being feature-complete to the CDI spec, with 1.0.1 focusing again on resolving functional issues. 1.1.0 is our chance to review the architecture of Weld and investigate both memory usage and performance, and deliver something that will shine.
If you have concerns about performance or memory usage, and want to help us work on this, we have batteries of stress tests we can run, so you can concentrate on looking for improvements.
We'll be including Weld 1.1.0 in JBoss AS 6.0.0, and we are recommending to the GlassFish team that they include it in GlassFish 3.1.
Finally, of course if you come across issues, you should file them in the issue tracker, or better yet, take a look at the source and see if you can help out!
Hi Pete; thanks for the post. A quick question. What version of Weld is planned for JBoss 7?
I would think AS7 Final is far enough out that the answer will be whatever is stable at the time AS7 ships
My understanding was that JBoss AS 7 was planned for end of 2011 as an enterprise quality release, so I was hoping you would have a general idea of that by now. In any case, I'm only looking at big-picture plans. As in, planning for a Weld 1.1.x, a Weld 1.x, or a Weld 2.x?
Re: Weld and GlassFish - We plan to integrate Weld 1.1.0 beta2 into the trunk of GlassFish 3.1 within a few days.
Fantastic!
When do we expect Weld 1.1 to achieve GA?
Here is the relevant post at TheAquarium. There should be a follow-up from Siva sometime next week with the actual details of the commit.
Argh! Here it is http://blogs.sun.com/theaquarium/entry/weld11inglassfish
Weld increases GAE cold start. Is It true?
I can't comment on AS7 schedule, Jason can comment on that. There are two options for Weld in AS7. If we do a MR of CDI then we would include Weld 1.2, otherwise it will be Weld 1.1 (IOW I am planning to make any needed changes to the integration SPI for Weld 1.1.0, we are planning to integrate Weld into AS7 initially in the next couple of months).
We are aiming for before Christmas this year.
Yes, but then deploying your app to GAE increases it's start time ;-) And improving the time Weld takes to start is on our priority list.:
There are lots of ways to improve startup time. The biggest overhead we have observed is actually loading the classes to scan in the first place, followed by the scan. We can use a project such as jandex to improve both of these significantly, by generating all the metadata about the classes as part of the build, and storing it in the deployed jar. This should have a major effect on a runtime env like GAE which has to go through startup much more often.
In fact, I want to take this one step further for Weld 1.1 and offer a full mode, whereby the environment can say to Weld . Obviously very useful in something like GAE which needs to cold-start much more often (my crude estimate is this could save say 60% of startup time without us doing any optimisation on startup time, something I hope Stale can look at once he has worked on runtime performance). This will also be very useful in JBoss AS 7 which will offer the ability to build parts of the deployment on the domain controller before handing it off to the individual servers.
Thank you for answer
And what about upgrading GF 3.0.1 with the newest weld lib? is there any change getting help there? I'm stuck in a project with major memory leaks caused by weld (and/or javassist) known bugs and it would be a pain to drop weld completely. Waiting to GF 3.1 it's not an option for me, Feb 2011 is too far away... I need to get the job done sooner.
I've tried to update weld-osgi-bundle.jar with some 1.1 beta versions downloaded from the m2 repos without luck, any hints? I'm getting javassist.NotFoundException with some of them and osgi problems about dependencies with others. It would be needed to update weld-integration.jar too? any extra package needed? Any help would be welcome! Thanks and sorry about the weeping! I'm a little bit lost.
Ricardo:
For instructions on how to patch Weld 1.0.1 to remove the runtime memory leak, see this thread:
http://www.sfwk.org/Community/LeakingOrNot
Sorry, I missed that post. Thanks a lot, Stuart. I'll try it now!