I have never had a problem accessing pull tools from Velocity, whether
the page contains Javascript that causes the form submittal (because of
a mouse click, the browser closing, etc) or whether the user is
hammering away at the keyboard.
What is puzzling is how the tool is accessing a null reference to
RunData since you are passing in the $data parameter from within the
template.
I have literally beaten/stress tested my forms to intentionally generate
overlapping requests, and I make heavy use of pull tools (that I have
written myself), and I have never had this type of null $data reference
within a tool. From my experience the pull tool concept is sound.
It sounds as if one of the tools you are are accessing is not
re-entrant, meaning that internally it is storing a temporary reference
to RunData (rather than internally passing RunData as a parameter to
every internal method call). Then at some insignificant time later
within the same sequence of steps it is trying to reference this
temporarily stored reference. In a hard hitting, asynchronous model
this could obviously fail. (Or instead of a reference to RunData, a
tool could also be trying to access the same long running resource, data
retrieval, storing data, etc, in which case it would need to control
access to the resource, or maintain state using an external resource).
From what I understand, no matter how quickly you submit overlapping
requests (even for the same session), each will have its own unique
instance of RunData, so the RunData model itself is probably not the
issue. What happens within the application when these different
requests are asynchronously accessing the same resources can be solved
through the implementation of the tool.
Christian Kaiser wrote:
(1) You create an object and while initializing it you store a reference
to RunData. A reference to this object is stored in the session.
...
My code doesn't store objects to RunData. Turbines does.
Hm, the pull tools i am talking about are using TurbineServices.
These services are fetched from Turbine with the RunData as parameter.
The services uses a key from the session to get specific data.
Just to repeat it: If rundata.isDisposed --> session is null --> NPE.
This approach was designed by Henning Schmiedehausen a while ago, so I
assume thats ok. This was with turbine version 2.3.1 resp 2.3.2-rc1
Maybe we shouldn't have upgraded to 2.3.3. ??
My conclusion of turbine behaviour for now:
If you use simple http requests (non-ajax), you won't have too much
trouble besides some ERROR logs resulting from a disposed rundata.
This may happen if a user doesn't wait for a long request to return, and
sends another request which overtakes the first one.
The user would not note anything, because his second request will be
performed correctly.
So, we have only errors in the log files as result. Ok, in bad designed
software it may lead to data inconsistency, but that might be too far
fetched for now.
Things get worse, if you have asynchronous ajax requests AND you use
pull tools from velocity templates to generate the response.
In this case, I suggest to refresh the rundata in all used tools per
request.
christian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
