You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Moritz Gmelin <mo...@gmx.de> on 2010/10/29 16:14:18 UTC
Again problems with SSOs (Threading)
Hi,
It happened to me again that one of my RequestFilters was creating a SessionStateObject. Which, when done for all assets of a page simply fails at one point. Different Threads accessing different Assets in parallel start to create new Sessions and thus the SSO gets lost.
Now one can resolve this by putting all RequestFilters that use the SSO behind the StaticFile filter. But since it is not enforced by Tapestry, other people might stumble over this.
Can't this be made "thread safe" in some way? So that it would be OK to have multiple parts of the page be handled by different threads using the same SSO?
Regards
Moritz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Again problems with SSOs (Threading)
Posted by Moritz Gmelin <mo...@gmx.de>.
Howard,
I have found ways around this problem for my special requirements. But I ran into this problem on two occasions now in the last 10 days. And I think this could happen to other people too.
Question is whether this is a bug in tapestry or at least something to be noted in the documentation.
......be careful not to use session state objects too early in the request pipeline in order to prevent your session state objects to get lost.....Whatever.
M.
Am 29.10.2010 um 22:16 schrieb Howard Lewis Ship:
> So, if you are trying to handle page access restrictions rather than
> overall access restrictions, you can contribute into the
> ComponentRequestHandler pipeline service, which comes later in the
> process, after the request has been identified as either a component
> event request (including things like form submits) or a page render
> request. That will reduce (but not eliminate) contention because
> requests for assets and the like will not come through the filter.
>
>
> On Fri, Oct 29, 2010 at 11:42 AM, Moritz Gmelin <mo...@gmx.de> wrote:
>> Am 29.10.2010 um 16:24 schrieb Thiago H. de Paula Figueiredo:
>>
>>> On Fri, 29 Oct 2010 12:14:18 -0200, Moritz Gmelin <mo...@gmx.de> wrote:
>>>
>>>> Hi,
>>>
>>> Hi!
>>>
>>>> It happened to me again that one of my RequestFilters was creating a SessionStateObject. Which, when done for all assets of a page simply fails at one point. Different Threads accessing different Assets in parallel start to create new Sessions and thus the SSO gets lost.
>>>
>>> What are you using to create the SSO and set it in the session?
>>>
>> To create the SSO in my RequestHandler I have an ApplicationStateManager asm injected and call asm.get (SSO.class).
>>
>>
>>>> Now one can resolve this by putting all RequestFilters that use the SSO behind the StaticFile filter. But since it is not enforced by Tapestry, other people might stumble over this.
>>>
>>> Why don't you just set the SSO in page requests?
>>>
>> In this case I use an SSO to do access control.
>>
>>
>>>> So that it would be OK to have multiple parts of the page be handled by different threads using the same SSO?
>>>
>>> Multiple parts of a page be handled by different threads? I'm not following you. Rendering a given page is done by a single thread for a given request.
>>>
>> If you have multpile assets on a page (and probably also if you load some zones with ajax) you can see that those parts are loaded from different threads if you just add some debug output in e.g. a timing filter.
>>
>> M.
>>
>>
>>
>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor
>>> Owner, Ars Machina Tecnologia da Informação Ltda.
>>> http://www.arsmachina.com.br
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Again problems with SSOs (Threading)
Posted by Howard Lewis Ship <hl...@gmail.com>.
So, if you are trying to handle page access restrictions rather than
overall access restrictions, you can contribute into the
ComponentRequestHandler pipeline service, which comes later in the
process, after the request has been identified as either a component
event request (including things like form submits) or a page render
request. That will reduce (but not eliminate) contention because
requests for assets and the like will not come through the filter.
On Fri, Oct 29, 2010 at 11:42 AM, Moritz Gmelin <mo...@gmx.de> wrote:
> Am 29.10.2010 um 16:24 schrieb Thiago H. de Paula Figueiredo:
>
>> On Fri, 29 Oct 2010 12:14:18 -0200, Moritz Gmelin <mo...@gmx.de> wrote:
>>
>>> Hi,
>>
>> Hi!
>>
>>> It happened to me again that one of my RequestFilters was creating a SessionStateObject. Which, when done for all assets of a page simply fails at one point. Different Threads accessing different Assets in parallel start to create new Sessions and thus the SSO gets lost.
>>
>> What are you using to create the SSO and set it in the session?
>>
> To create the SSO in my RequestHandler I have an ApplicationStateManager asm injected and call asm.get (SSO.class).
>
>
>>> Now one can resolve this by putting all RequestFilters that use the SSO behind the StaticFile filter. But since it is not enforced by Tapestry, other people might stumble over this.
>>
>> Why don't you just set the SSO in page requests?
>>
> In this case I use an SSO to do access control.
>
>
>>> So that it would be OK to have multiple parts of the page be handled by different threads using the same SSO?
>>
>> Multiple parts of a page be handled by different threads? I'm not following you. Rendering a given page is done by a single thread for a given request.
>>
> If you have multpile assets on a page (and probably also if you load some zones with ajax) you can see that those parts are loaded from different threads if you just add some debug output in e.g. a timing filter.
>
> M.
>
>
>
>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor
>> Owner, Ars Machina Tecnologia da Informação Ltda.
>> http://www.arsmachina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Again problems with SSOs (Threading)
Posted by Moritz Gmelin <mo...@gmx.de>.
Am 29.10.2010 um 16:24 schrieb Thiago H. de Paula Figueiredo:
> On Fri, 29 Oct 2010 12:14:18 -0200, Moritz Gmelin <mo...@gmx.de> wrote:
>
>> Hi,
>
> Hi!
>
>> It happened to me again that one of my RequestFilters was creating a SessionStateObject. Which, when done for all assets of a page simply fails at one point. Different Threads accessing different Assets in parallel start to create new Sessions and thus the SSO gets lost.
>
> What are you using to create the SSO and set it in the session?
>
To create the SSO in my RequestHandler I have an ApplicationStateManager asm injected and call asm.get (SSO.class).
>> Now one can resolve this by putting all RequestFilters that use the SSO behind the StaticFile filter. But since it is not enforced by Tapestry, other people might stumble over this.
>
> Why don't you just set the SSO in page requests?
>
In this case I use an SSO to do access control.
>> So that it would be OK to have multiple parts of the page be handled by different threads using the same SSO?
>
> Multiple parts of a page be handled by different threads? I'm not following you. Rendering a given page is done by a single thread for a given request.
>
If you have multpile assets on a page (and probably also if you load some zones with ajax) you can see that those parts are loaded from different threads if you just add some debug output in e.g. a timing filter.
M.
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Again problems with SSOs (Threading)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, 29 Oct 2010 12:14:18 -0200, Moritz Gmelin <mo...@gmx.de>
wrote:
> Hi,
Hi!
> It happened to me again that one of my RequestFilters was creating a
> SessionStateObject. Which, when done for all assets of a page simply
> fails at one point. Different Threads accessing different Assets in
> parallel start to create new Sessions and thus the SSO gets lost.
What are you using to create the SSO and set it in the session?
> Now one can resolve this by putting all RequestFilters that use the SSO
> behind the StaticFile filter. But since it is not enforced by Tapestry,
> other people might stumble over this.
Why don't you just set the SSO in page requests?
> So that it would be OK to have multiple parts of the page be handled by
> different threads using the same SSO?
Multiple parts of a page be handled by different threads? I'm not
following you. Rendering a given page is done by a single thread for a
given request.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org