Starting in November 2008, we found a concurrency issue in our web applications that are based on the following framework stack:
- Spring 2.5.4
- Spring Web Flow 2.0.5
- JSF 1.2_09
- Facelets 1.1.14a
- Trinidad 1.2.9
The issue
For a single user, everything run fine. However, when multiple users hit the application, we got some strange exceptions occasionally – not always and not always at the same place. However, we managed to get this one regularly with our JMeter tests:
SCHWERWIEGEND: Error Rendering View[/plan/FindPlan.xhtml]
javax.el.PropertyNotFoundException: /file:/.../facelets/ipl-comboBox.xhtml @64,30 value="#{localField.jsfValue}": Target Unreachable, identifier 'localField' resolved to null
at com.sun.facelets.el.TagValueExpression.getType(Tag ValueExpression.java:62)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.ValueRenderer.getDefaultConverter(ValueRend erer.java:78)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectOneRenderer.renderNonElementCon tent(SimpleSelectOneRenderer.java:323)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormElementRenderer.encodeAllAsNonElement(F ormElementRenderer.java:172)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormElementRenderer.encodeAll(FormElementRe nderer.java:105)
at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:335)
....
This exception got rendered on the page instead of the actual component. At other times, we got java.lang.IllegalStateException and other funny behavior.
The strange thing is, the referenced variable is put into the flow scope, of course. Now that we took the time to debug into this issue, we can see that the scopes seem to be correctly filled and the property is actually there, it's just that the ELResolvers could not retrieve it...
Actually, we thought it would be caused by our Java or Spring configuration code, presumably using wrong bean scope or the like.
...is fixed!
Guess what... now I have been pointed to this bug of Spring Web Flow version 2.0.5: Class SimpleELContext is not thread-safe, but is stored in some application singletons :-( See this or this thread for more details.
The good news is, the bug is fixed in version 2.0.6; we have upgraded our projects and load tested them, and everything is just fine.
But...
IMO this is leaving a stale aftertaste. I'll tell you why.
That issue is a severe one: web applications using SWF 2.0.5 are just not working for concurrent users. Everybody using SWF in this version (maybe earlier versions as well) is affected. Given that, it seems strange that
- the issue hasn't been reported and fixed earlier: Version 2.0.5 has been published on 14th of November, and it took more than 2 weeks for the Jira issue to show up.
- this issue is hard to find in the web: Of course, we did some web research to find out if someone else might have a similar problem, but we did not find very much useful. The mentioned threads have started in February/March 2009 – did nobody suffer from this bug earlier than that? Why did nobody post this issue anywhere before?
- the fact that this version is buggy hasn't been reported on Spring Source web pages: Since it's rather threatening, why not put an eye-catcher message on the download page (or somewhere else) telling that this version is buggy and should not be used?
I can see two reasons for this situation, and actually I don't like both: on one hand, there seems to be no load testing by Spring Web Flow team before doing a release; on the other hand, this version 2.0.5 is probably not used very much for real-world web applications by the community out there, and I honestly hope that this is not true to SWF as a whole...
0 comments:
Post a Comment