Hi Pierre, hi Francis, additionally, there's a problem/bug with performParentAction() in WOComponent: before the actual parentAction gets called via parent.valueForKey(action), WOF calls pushValuesToParent(). In case of stateless components this method also prematurely resets the component and returns the component instance to the component instance pool. :( So, in case of concurrent request handling it is absolutely possible that your component instance gets checked out from the component instance pool while your parent action is called. Two separate threads would use the same instance of your component concurrently. Sad, but it's like that and it's a bug. Of course, the probability to experience this bug rises with the load on your application and the duration to perform the actual parent action.
I reported this bug nearly three years ago to Apple, along with a simple test application and a JMeter configuration script to reproduce it reliably. After a year or so I gave up on periodically watching the bugreport for changes or comments. Probably it hasn't been read until now. ;) Our simple workaround then was to directly use parent().valueForKey(actionName) instead of performParentAction(actionName). By this means the problematic pushValuesToParent() doesn't get called in a place where it isn't meant to be and everything's fine. (At least, as long as your stateless components are non-synchronizing. Luckily, in our case, they were.) HTH a bit. Cheers,--micha -----Original Message----- From: Pierre Bernard [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 4:49 PM To: Ulrich Köster; Francis Labrie Cc: WebObjects Development Subject: Re: Bug in stateless WOComponent management? A stateless component should be locked to one request/response loop and thus thread at a given time. No two things should happen concurrently. If the stateless component is needed by another thread, a new copy will be created. I have had a similar problem that I traced back to having my stateless component recursively embedded within itself. In that case the same instance of the component does indeed get used at two different places (within the same thread). The results of this seem pretty unpredictable. Pierre On 7 Dec 2006, at 16:30, Ulrich Köster wrote: I've hit the send button to early. The special thing about a stateless component is that only one instance of the component is used. With concurrent request handling it's very likely that a reset and valueForKey are called at eh same time. Uli Am 07.12.2006 um 16:25 schrieb Ulrich Köster: _flag is a state ! public boolean flag() { Boolean _flag; if(_flag == null) { // Initialize _flag to a Boolean instance: it can't be set to null [...] } return _flag.booleanValue(); } public boolean isStateless() { return true; } public boolean synchronizesVariablesWithBindings() { return false; } Am 07.12.2006 um 16:12 schrieb Francis Labrie: Hi, I have several WebObjects 5.3.2 applications deployed in production running with Java 5, and I've found something worrying with stateless components. By the way, these applications are set to allow concurrent request. I have an heavily used stateless component managing is own bindings synchronisation: public class Cell extends WOComponent { // Private instance variable private Boolean _flag; // Code removed for clarity... [...] public boolean flag() { if(_flag == null) { // Initialize _flag to a Boolean instance: it can't be set to null [...] } return _flag.booleanValue(); } public boolean isStateless() { return true; } public void reset() { super.reset(); // The only place in the variable is set to null _flag = null; } public boolean synchronizesVariablesWithBindings() { return false; } } But sometimes (less than 1% of concurrent requests), I get a NullPointerException on the "return _flag.booleanValue();" line! And this is only an evidence of the problem: sometimes I also get incorrect values. Normally, this can't be the case according to the WOComponent documentation: << Note that a stateless component's instance variables will remain valid for the duration of the phase (takeValuesFromRequest , invokeAction , appendToResponse ); this lets you use instance variables in the stateless components to hold things analogous to items in a WORepetition. >> And IIRC, WebObjects use only one instance of a stateless component per thread. So I must conclude another thread called "reset()" on the same component instance, violating the WOComponent contract quoted above. This seems to be a bug in WebObjects... Can someone confirm this? Is their any workaround? I've tried to syncronize the stateless component in the appendToResponse method, but it leads to deadlocks on concurrent requests... Kind regards, -- Francis Labrie Saint-Bruno-de-Montarville, Quebec, Canada _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/ulrich.koester%40assen se.com This email sent to [EMAIL PROTECTED] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/ulrich.koester%40assen se.com This email sent to [EMAIL PROTECTED] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/webobjects-lists%40hou dah.com This email sent to [EMAIL PROTECTED] - - - Houdah Software s. à r. l. http://www.houdah.com - Quality Mac OS X software - Premium WebObjects consulting _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
