You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Christian Kaiser <ch...@bluecellnetworks.com> on 2009/12/01 10:00:02 UTC
Re: ajax and rundata disposal
First of all, thanks for your answers. :-)
Am Montag, den 30.11.2009, 18:34 +0100 schrieb Thomas Vandahl:
> Christian Kaiser wrote:
> > If the ajax request is the first request to finish, it disposes the
> > RunData.
> > This leads to bad behavour of my http request, because this request has
> > to deal with a disposed RunData.
>
> RunData is a per-request object that is borrowed from a pool at request
> creation and returned (and recycled) at request completion. A RunData
> object is not meant to be shared between different requests. If you
> believe you must do this, you have a serious design problem in your
> software.
Ok, I don't believe I must do this.
I thought it is meant to be that way.
>
> Then again, your main screen request and your Ajax request are totally
> unrelated from Turbine's point of view. They should use two different
> RunData objects anyway.
Concerning your previous mentioned point, I don't think that this issue
is Ajax related any more. I face the same problem with ordinary
requests, sent fast in row.
If one request overtakes the other while processing, it ends up in a
disposed Rundata of the first request, too.
>
> > Is this a common problem?
> > Can I prevent from it?
>
> No, this should not happen at any time.
>
That sounds promising.
>
> > Please let me now if I can provide you with additional information.
>
> Well, yes. Let's have a look at some code. This problem sounds very
> strange to me.
>
>
>
I overwrote The DefaultTurbineRunData. ( I think this was to identify disposed rundata ??).
/**
*
* Gets the servlet session information. Return null if data expired.
*
* @return the session.
*/
public HttpSession getSession() {
HttpServletRequest request = getRequest();
if (request == null) {
return null;
}
return request.getSession();
}
Let me know which other code is of interest.
Thanks,
christian
> Bye, Thomas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
> For additional commands, e-mail: user-help@turbine.apache.org
>
Christian Kaiser | Softwareentwicklung
blue cell networks GmbH
Hainstraße 14 | 96047 Bamberg, Germany | phone:+49 (0) 951-30 20 67
121 | fax: +49 (0) 951-30 20 67 201
email: christian.kaiser@bluecellnetworks.com | skype:
bcn_christian.kaiser | web: www.bluecellnetworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org
Re: ajax and rundata disposal
Posted by Christian Kaiser <ch...@bluecellnetworks.com>.
>
> 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
Yes, I think this is re-entrant.
So this might be the source of my problems.
class ATool
public void init(Object data) {
if (data instanceof RunData)
this.data = (RunData) data;
}
public void refresh(RunData data) {
this.data = data;
}
public Model get(String modelName) {
ModelService modelService = TurbineModel.getService();
return modelService.getModel(modelName,data);
}
---------------------------------------------------------------------------------------
I guess I am supposed to use the tool that way.
public Model get(String modelName, presentData) {
ModelService modelService = TurbineModel.getService();
return modelService.getModel(modelName,presentData);
}
Can you confirm that?
christian
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org
Re: ajax and rundata disposal
Posted by tony <to...@prepare-enrich.com>.
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: user-unsubscribe@turbine.apache.org
> For additional commands, e-mail: user-help@turbine.apache.org
>
>
Re: ajax and rundata disposal
Posted by Christian Kaiser <ch...@bluecellnetworks.com>.
> (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: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org
Re: ajax and rundata disposal
Posted by tony <to...@prepare-enrich.com>.
Let me see if I have this straight...
(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.
...
(2) Another event takes place causing you to reference the session
object, where you in turn attempt to use the original reference to your
original RunData object
...
Instead of (1) and (2) simply include a reference of RunData as a
parameter to the methods on your object... Do not store any references
to any instance of RunData. Also, you should not care if you are
working with different instances of RunData as each instance is single
use (per event).
FYI... I would use a parameter approach rather than an init approach...
Depending upon implementations, I have seen cases where the form object
gets called, then the event, and then the form gets called
redundantly... Even if you are referencing an event (where you might
always expect the event to be first in the sequence).
...
If you are worried about maintaining state just use the methods on the
current RunData instance to access whatever you have stored in the
session. Your state is maintained in the session, and not in any
particular instance of RunData.
Christian Kaiser wrote:
> I think I got it now.
> Please correct me if I misconceive.
> log:
>
> 14:51:27,027 [TP-Processor8] DEBUG ...BmsRunData
> recycle ...BmsRunData@1f3bb61
> 14:51:27,033 [TP-Processor8] DEBUG ...ModelTool -
> refresh ...BmsRunData@1f3bb61
>
> 14:51:27,168 [TP-Processor2] DEBUG ...BmsRunData -
> recycle ...BmsRunData@3e65be
> 14:51:27,183 [TP-Processor2] DEBUG ...ModelTool -
> refresh ...BmsRunData@3e65be
> 14:51:27,245 [TP-Processor2] DEBUG ...BmsRunData -
> dispose ...BmsRunData@3e65be
>
> 14:51:27,249 [TP-Processor8] ERROR ...ModelTool - NPE
> for ...BmsRunData@3e65be
> 14:51:27,256 [TP-Processor8] DEBUG ...BmsRunData -
> dispose ...BmsRunData@1f3bb61
>
>
> Processor2 overtakes Processor8.
>
> The modeltool runs in session scope, so only one instance of it exists.
> After P8 refreshes the rundata in the tool,
> P2 overwrites it with its rundata.
> P2 finished and disposed the rundata.
> The model tool in P8 has a disposed rundata.
>
>
> I can prevent from this, when I set the tool in a request scope.
> That means the refresh method of the RunDataApplicationTool is not
> called, but the Rundata is passed to the Tool with the init method.
> The tool gets initialized on every request.
>
> Thats about it for now.
> Feel free to add your thoughts.
> Thanks for your hints, so far.
>
> Christian
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
> For additional commands, e-mail: user-help@turbine.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org
Re: ajax and rundata disposal
Posted by Christian Kaiser <ch...@bluecellnetworks.com>.
> Yes, performance is the key here. The difference is that this switch
> makes *all* tools refresh themselves on every request, while the scope
> change affects your single tool only.
>
Ok, thanks.
> Again, I can only emphasize that RunData objects should not be used in
> any other scope than request.
I use the RunData only in a tool to help rendering a response from a
template.
So this is only for one request.
Setting the scope to request does actually work.
The solution provided in
http://turbine.markmail.org/message/xchloohdlo7enj2l should work too,
but haven't used it so far.
bye
christian
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org
Re: ajax and rundata disposal
Posted by Thomas Vandahl <tv...@apache.org>.
Christian Kaiser wrote:
> I would really like to know why you don't recommend this. Is it for
> performance reasons? Isn't the same thing when I change the tools scope
> to 'request'?
Yes, performance is the key here. The difference is that this switch
makes *all* tools refresh themselves on every request, while the scope
change affects your single tool only.
Again, I can only emphasize that RunData objects should not be used in
any other scope than request. Because they are pooled, recycled and
reused, your tool might end up in using the data of another request -
which is the case if the RunData object you just used is assigned to a
different thread or session.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org
Re: ajax and rundata disposal
Posted by Christian Kaiser <ch...@bluecellnetworks.com>.
> services.PullService.tools.per.request.refresh=true
Nice, thanks for the hint.
> I do not recommend this for production use, however.
I would really like to know why you don't recommend this. Is it for
performance reasons? Isn't the same thing when I change the tools scope
to 'request'?
christian
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org
Re: ajax and rundata disposal
Posted by Thomas Vandahl <tv...@apache.org>.
Christian Kaiser wrote:
> I can prevent from this, when I set the tool in a request scope.
Yes, this is the way to do it.
> That means the refresh method of the RunDataApplicationTool is not
> called, but the Rundata is passed to the Tool with the init method.
The refresh()-method call can be forced by setting
services.PullService.tools.per.request.refresh=true
The comment in the original TurbineResources.properties file is like
this (which explains it all)
---8<---
# This determines whether the non-request tools are refreshed
# on each request (request tools aren't ever, because they're
# instantiated for the request only anyway).
services.PullService.tools.per.request.refresh=true
---8<---
I do not recommend this for production use, however.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org
Re: ajax and rundata disposal
Posted by Christian Kaiser <ch...@bluecellnetworks.com>.
I think I got it now.
Please correct me if I misconceive.
log:
14:51:27,027 [TP-Processor8] DEBUG ...BmsRunData
recycle ...BmsRunData@1f3bb61
14:51:27,033 [TP-Processor8] DEBUG ...ModelTool -
refresh ...BmsRunData@1f3bb61
14:51:27,168 [TP-Processor2] DEBUG ...BmsRunData -
recycle ...BmsRunData@3e65be
14:51:27,183 [TP-Processor2] DEBUG ...ModelTool -
refresh ...BmsRunData@3e65be
14:51:27,245 [TP-Processor2] DEBUG ...BmsRunData -
dispose ...BmsRunData@3e65be
14:51:27,249 [TP-Processor8] ERROR ...ModelTool - NPE
for ...BmsRunData@3e65be
14:51:27,256 [TP-Processor8] DEBUG ...BmsRunData -
dispose ...BmsRunData@1f3bb61
Processor2 overtakes Processor8.
The modeltool runs in session scope, so only one instance of it exists.
After P8 refreshes the rundata in the tool,
P2 overwrites it with its rundata.
P2 finished and disposed the rundata.
The model tool in P8 has a disposed rundata.
I can prevent from this, when I set the tool in a request scope.
That means the refresh method of the RunDataApplicationTool is not
called, but the Rundata is passed to the Tool with the init method.
The tool gets initialized on every request.
Thats about it for now.
Feel free to add your thoughts.
Thanks for your hints, so far.
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org
Re: ajax and rundata disposal
Posted by Christian Kaiser <ch...@bluecellnetworks.com>.
maybe it has to do with scope of the pull tools I am using.
I use the ModelService, done by Henning, maybe you know it.
The model tool runs in authorized scope and uses the contents of the
rundata to get a model.
As far as I understand it, a rundata object will be passed to the tool
when the session gets initialized.
This tool will be used by all requests. It may happen that the rundata
object, stored in the tool, is disposed when some request wants to fetch
a model with it.
I tried to put the tool in request scope. But it seems that the tool
doesn't get a refresh call with the rundata object in that scope.
I am not sure if I am on the right path, but hopefully this helps you to
understand my set up.
christian
Am Dienstag, den 01.12.2009, 11:08 +0100 schrieb Christian Kaiser:
> logs proof that there are multiple RunData Objects:
>
> 2009-12-01 11:03:08,673 [TP-Processor6] DEBUG de.beamzone.sm.service.rundata.BmsRunData - recycle de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:08,752 [TP-Processor6] DEBUG de.beamzone.sm.service.rundata.BmsRunData - dispose de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:08,981 [TP-Processor8] DEBUG de.beamzone.sm.service.rundata.BmsRunData - recycle de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:09,109 [TP-Processor8] DEBUG de.beamzone.sm.service.rundata.BmsRunData - dispose de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:09,357 [TP-Processor8] DEBUG de.beamzone.sm.service.rundata.BmsRunData - recycle de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:09,557 [TP-Processor2] DEBUG de.beamzone.sm.service.rundata.BmsRunData - dispose de.beamzone.sm.service.rundata.BmsRunData@296a42
> 2009-12-01 11:03:09,795 [TP-Processor8] ERROR de.beamzone.sm.tools.ModelTool - Cannot get model Campaign for RunData de.beamzone.sm.service.rundata.BmsRunData@296a42. Error: java.lang.NullPointerException
> 2009-12-01 11:03:09,984 [TP-Processor8] DEBUG de.beamzone.sm.service.rundata.BmsRunData - dispose de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:10,385 [TP-Processor7] DEBUG de.beamzone.sm.service.rundata.BmsRunData - recycle de.beamzone.sm.service.rundata.BmsRunData@296a42
> 2009-12-01 11:03:10,392 [TP-Processor7] DEBUG de.beamzone.sm.service.rundata.BmsRunData - dispose de.beamzone.sm.service.rundata.BmsRunData@296a42
> 2009-12-01 11:03:10,573 [TP-Processor3] DEBUG de.beamzone.sm.service.rundata.BmsRunData - recycle de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:10,603 [TP-Processor3] DEBUG de.beamzone.sm.service.rundata.BmsRunData - dispose de.beamzone.sm.service.rundata.BmsRunData@1afc148
>
>
>
> Am Dienstag, den 01.12.2009, 10:00 +0100 schrieb Christian Kaiser:
> > First of all, thanks for your answers. :-)
> >
> > Am Montag, den 30.11.2009, 18:34 +0100 schrieb Thomas Vandahl:
> > > Christian Kaiser wrote:
> > > > If the ajax request is the first request to finish, it disposes the
> > > > RunData.
> > > > This leads to bad behavour of my http request, because this request has
> > > > to deal with a disposed RunData.
> > >
> > > RunData is a per-request object that is borrowed from a pool at request
> > > creation and returned (and recycled) at request completion. A RunData
> > > object is not meant to be shared between different requests. If you
> > > believe you must do this, you have a serious design problem in your
> > > software.
> >
> > Ok, I don't believe I must do this.
> > I thought it is meant to be that way.
> >
> >
> >
> >
> >
> > >
> > > Then again, your main screen request and your Ajax request are totally
> > > unrelated from Turbine's point of view. They should use two different
> > > RunData objects anyway.
> >
> > Concerning your previous mentioned point, I don't think that this issue
> > is Ajax related any more. I face the same problem with ordinary
> > requests, sent fast in row.
> > If one request overtakes the other while processing, it ends up in a
> > disposed Rundata of the first request, too.
> >
> >
> > >
> > > > Is this a common problem?
> > > > Can I prevent from it?
> > >
> > > No, this should not happen at any time.
> > >
> > That sounds promising.
> > >
> > > > Please let me now if I can provide you with additional information.
> > >
> > > Well, yes. Let's have a look at some code. This problem sounds very
> > > strange to me.
> > >
> > >
> > >
> >
> > I overwrote The DefaultTurbineRunData. ( I think this was to identify disposed rundata ??).
> >
> > /**
> > *
> > * Gets the servlet session information. Return null if data expired.
> > *
> > * @return the session.
> > */
> > public HttpSession getSession() {
> > HttpServletRequest request = getRequest();
> >
> > if (request == null) {
> >
> > return null;
> >
> > }
> >
> > return request.getSession();
> > }
> >
> > Let me know which other code is of interest.
> >
> > Thanks,
> > christian
> >
> >
> >
> > > Bye, Thomas.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
> > > For additional commands, e-mail: user-help@turbine.apache.org
> > >
> >
> >
> > Christian Kaiser | Softwareentwicklung
> >
> > blue cell networks GmbH
> >
> >
> >
> > Hainstraße 14 | 96047 Bamberg, Germany | phone:+49 (0) 951-30 20 67
> > 121 | fax: +49 (0) 951-30 20 67 201
> >
> > email: christian.kaiser@bluecellnetworks.com | skype:
> > bcn_christian.kaiser | web: www.bluecellnetworks.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
> > For additional commands, e-mail: user-help@turbine.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
> For additional commands, e-mail: user-help@turbine.apache.org
>
Christian Kaiser | Softwareentwicklung
blue cell networks GmbH
Hainstraße 14 | 96047 Bamberg, Germany | phone:+49 (0) 951-30 20 67
121 | fax: +49 (0) 951-30 20 67 201
email: christian.kaiser@bluecellnetworks.com | skype:
bcn_christian.kaiser | web: www.bluecellnetworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org
Re: ajax and rundata disposal
Posted by Christian Kaiser <ch...@bluecellnetworks.com>.
logs proof that there are multiple RunData Objects:
2009-12-01 11:03:08,673 [TP-Processor6] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - recycle
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:08,752 [TP-Processor6] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - dispose
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:08,981 [TP-Processor8] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - recycle
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:09,109 [TP-Processor8] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - dispose
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:09,357 [TP-Processor8] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - recycle
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:09,557 [TP-Processor2] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - dispose
de.beamzone.sm.service.rundata.BmsRunData@296a42
2009-12-01 11:03:09,795 [TP-Processor8] ERROR
de.beamzone.sm.tools.ModelTool - Cannot get model Campaign for RunData
de.beamzone.sm.service.rundata.BmsRunData@296a42. Error:
java.lang.NullPointerException
2009-12-01 11:03:09,984 [TP-Processor8] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - dispose
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:10,385 [TP-Processor7] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - recycle
de.beamzone.sm.service.rundata.BmsRunData@296a42
2009-12-01 11:03:10,392 [TP-Processor7] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - dispose
de.beamzone.sm.service.rundata.BmsRunData@296a42
2009-12-01 11:03:10,573 [TP-Processor3] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - recycle
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:10,603 [TP-Processor3] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - dispose
de.beamzone.sm.service.rundata.BmsRunData@1afc148
Am Dienstag, den 01.12.2009, 10:00 +0100 schrieb Christian Kaiser:
> First of all, thanks for your answers. :-)
>
> Am Montag, den 30.11.2009, 18:34 +0100 schrieb Thomas Vandahl:
> > Christian Kaiser wrote:
> > > If the ajax request is the first request to finish, it disposes the
> > > RunData.
> > > This leads to bad behavour of my http request, because this request has
> > > to deal with a disposed RunData.
> >
> > RunData is a per-request object that is borrowed from a pool at request
> > creation and returned (and recycled) at request completion. A RunData
> > object is not meant to be shared between different requests. If you
> > believe you must do this, you have a serious design problem in your
> > software.
>
> Ok, I don't believe I must do this.
> I thought it is meant to be that way.
>
>
>
>
>
> >
> > Then again, your main screen request and your Ajax request are totally
> > unrelated from Turbine's point of view. They should use two different
> > RunData objects anyway.
>
> Concerning your previous mentioned point, I don't think that this issue
> is Ajax related any more. I face the same problem with ordinary
> requests, sent fast in row.
> If one request overtakes the other while processing, it ends up in a
> disposed Rundata of the first request, too.
>
>
> >
> > > Is this a common problem?
> > > Can I prevent from it?
> >
> > No, this should not happen at any time.
> >
> That sounds promising.
> >
> > > Please let me now if I can provide you with additional information.
> >
> > Well, yes. Let's have a look at some code. This problem sounds very
> > strange to me.
> >
> >
> >
>
> I overwrote The DefaultTurbineRunData. ( I think this was to identify disposed rundata ??).
>
> /**
> *
> * Gets the servlet session information. Return null if data expired.
> *
> * @return the session.
> */
> public HttpSession getSession() {
> HttpServletRequest request = getRequest();
>
> if (request == null) {
>
> return null;
>
> }
>
> return request.getSession();
> }
>
> Let me know which other code is of interest.
>
> Thanks,
> christian
>
>
>
> > Bye, Thomas.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
> > For additional commands, e-mail: user-help@turbine.apache.org
> >
>
>
> Christian Kaiser | Softwareentwicklung
>
> blue cell networks GmbH
>
>
>
> Hainstraße 14 | 96047 Bamberg, Germany | phone:+49 (0) 951-30 20 67
> 121 | fax: +49 (0) 951-30 20 67 201
>
> email: christian.kaiser@bluecellnetworks.com | skype:
> bcn_christian.kaiser | web: www.bluecellnetworks.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
> For additional commands, e-mail: user-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org