Great! Keep up the good work!

Is there a release note that lists all the bug fixes contained in this release ?

Also is there any performance-related fixes?

Thanks, -Guillaume

There is a changelog.txt in the download, or see JIRA

Hi, is there any document describing the migration from Seam 2.0.0 or 2.0.1? Or it is just about switching the jars to the ones form newer release? Maybe some developers would appreciate step-by-step instruction to not go wrong. Thanks Tomas

Just drop in the new jars and dependency upgrades if you want them.

This version is working abysmally slow, compared to 2.0.1, and I'm not even talking 20% decrease, I'm talking several times slower. I haven't pointed the exact problem just yet (any pointers on how to do it?), but simply flipping the Seam version from 2.0.1.GA to 2.0.2.GA in POM, slows most pages in my app almost tenfold - say, I'm getting page load times of 34 seconds, compared to the old 3.8 seconds (yes, that's a decimal point in the latter number). No other dependencies have been changed (Hibernate EM 3.3.2, JSF RI 1.2.07 and Facelets).

Has anybody else got similar results after the upgrade?

Alex

I upgraded right after release and my users have not said anything about a slowdown.

Believe me the would complain about any noticeable difference. ;)

I am running on a JBAS 4.2.2 with standard versions of the libraries.

I am using RF 3.2.0SR1.

Yes, I too am experiencing a significant slow down upgrading from 2.0.1.GA to 2.0.2.GA. It is very noticeable when I switch back and forth.

For simple pages with few controls, the difference might not be noticeable. When I was trying to narrow down the issue, I went to gradually simplify the page in question, and while I still get drastically different load times even for the most simple cases (dataTable backed by a conversational EntityQuery, lazily paged as per Seam docs 12.3), the magnitude is smaller, and I doubt users would notice a difference between a 0.2s and 0.8s load time. However, for more complex cases, this could be easily pushed into the 4s/30s difference.

My page is quite a complex search and has many controls. I am not using EntityQuery.

I am using ExtendedDataModel and datascroller from richfaces.

My pages are relatively slow anyway, but there was no change.

I am still trying to flesh out functionality at which point I will go back and optimize. Or maybe Seam 2.1 will magically make everything faster.

Have you found anyways to optimize?

Specifically which part is slower?

Well, I am sorry to say that we experience the same thing. It is considerably slower on pages which calls managed beans with alot of injections repeatedly.

Can you provide more details about this performance slowdown, or something to allow us to reproduce?

The issue seems to be in the interceptors. On my page, I had a dataTable with some conditionally displayed columns, and the condition was referencing a property from a bean with lots of injections. When I moved this property to a separate bean annotated with @BypassInterceptors, I was able to cut down page loads from about 40s to about 12s. On 2.0.1, the page loads for the same interactions were roughly 3s.

I'm still trying to come up with a simple test case, as I understand that I can't simply offload my whole app to you guys for analysis :) Will let you know how it goes.

Is there a best practive how to optimize the injection times?

Pete, should I open a JIRA issue for this? I've come up with a test case WAR that gives about 3x differrence in load times for 2.0.1 and 2.0.2.

Thanks Alex!

Please create a jira and attach your war and how you verify the slowdown with it.

Thank,

Jay

http://jira.jboss.com/jira/browse/JBSEAM-3024

As far as I can tell a big portion of this performance issue is related to the issue described in JBSEAM-2917.

I tried backporting that fix into 2.0.2 with modifications because the calls are different in trunk. That definitely increased performance considerably and my tests in the profiler showed that the bottleneck was removed.

Indeed, you're correct! Not sure why this issue didn't manifest itself in 2.0.1, but putting the patch did resolve the slowdown, bringing load times back to a manageable 5-6s.

Thanks a lot,

Alex

I don't understand how this patch can improve overall performance. Where is Seam.getEjbDescriptor() actually called besides initialization time?

Shane Bryzak wrote on May 25, 2008 02:38:
I don't understand how this patch can improve overall performance. Where is Seam.getEjbDescriptor() actually called besides initialization time?

It gets called on every component method invocation, for every non-null non-transient non-static non-injected field of the component (including inherited fields) whose type is neither a collection nor annotated with @Entity, via the following code path:

ManagedEntityIdentityInterceptor.aroundInvoke
   -> entityRefsToIds (every invocation)
   -> isRef  (for every qualifying field, in superclasses too)
   -> Seam.getEntityClass() 
   -> Seam.getEjbDescriptor() (for the class of the field as well as its superclasses)

Lets say you have on average three fields in your components, and each component has on average one non-trivial superclass. Then getEjbDescriptor is called (6 fields * 2 classes per field) -> 12 times on every invocation of any method in any component.

This probably affects people with older code bases (which use hbms instead of @Entity for their model classes) a lot more. Like me :)

As an aside, IMHO ManagedEntityIdentityInterceptor is the nemesis of all things performant. This isn't the only place it's a hotspot.

Got it, thanks. I was actually looking at the code in trunk, where Seam.getEntityClass() accesses EJB_DESCRIPTOR_CACHE directly, rather than calling getEjbDescriptor(). I've ported the fix back to the 2_0 branch anyway, which will be in the imminent SP1 release. Hopefully that will fix the performance issues that people are experiencing.

great job