RE: Bug in stateless WOComponent management?
RE: Bug in stateless WOComponent management?
- Subject: RE: Bug in stateless WOComponent management?
- From: "Müller, Michael" <email@hidden>
- Date: Thu, 7 Dec 2006 17:24:38 +0100
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@hidden]
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@hidden)
Help/Unsubscribe/Update your Subscription:
se.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
se.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
dah.com
This email sent to email@hidden
- - -
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden