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/11/23 15:30:42 UTC
Threading and SSOs (again)
Hi,
a couple of weeks ago, we had an issue with our application when all assets were checked by our AccessControlDispatcher which is checking User permissions to access any resource based on user information stored in a session state object . The problem was that the session-state-objects were somehow dropped (new sessions were created) when multiple request threads were accessing at the same time.
We could solve this for most cases by simply not checking access on static assets. Which is OK.
But now we discover that the problem somtimes occurs on pages where multiple dynamic images are rendered by the Tapestry Application. Those images are passed through the access control dispatch which in turn checks access permission as above (with the session object) which can cause sessions to be dropped when it happens from multiple request threads at the same time.
Is this a design problem with my application that multple threads can access the sessionstateobject at the same time and thus break its uniqueness or is it tapestrys fault that it does not prevent it from breaking?
What can I do to resolve this?
Thanks
Moritz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Threading and SSOs (again)
Posted by Josh Canfield <jo...@gmail.com>.
Ok, just to follow up. I tracked it down and commented on the defects involved.
> https://issues.apache.org/jira/browse/TAP5-1355
https://issues.apache.org/jira/browse/TAP5-834
Tapestry has two lines of code which set a session attribute to null
and back in order to force updates to clustered servers... not my area
of expertise.
If you're not in a clustered environment, or possibly using an app
server other than Tomcat/Jetty, then your SSO could extend
org.apache.tapestry5.OptimizedSessionPersistedObject and always return
false in isSessionPersistedObjectDirty. This would circumvent the code
that temporarily sets the session attribute holding your SSO to null.
If you aren't changing the values inside the object then it should be
a safe approach.
I'll try to work out a real solution for 5.3... the fix might be a
little risky for a 5.2.4 release.
Josh
On Wed, Nov 24, 2010 at 12:16 AM, Moritz Gmelin <mo...@gmx.de> wrote:
> Thanks
>
> https://issues.apache.org/jira/browse/TAP5-1355
>
> Moritz
>
> Am 24.11.2010 um 00:29 schrieb Josh Canfield:
>
>> Can you put the test case into jira? I'll try to look at it over the
>> holiday/weekend.
>> On 23 Nov 2010 13:16, "Moritz Gmelin" <mo...@gmx.de> wrote:
>>> Hi,
>>>
>>> I was able to create a very simple example to recreate that problem:
>>>
>>> -A simple page that displays 20 dynamically generated images in a loop.
>>> -In the page, a SSO, holding a number value is initialized to a random
>> number.
>>> -Each of the dynamic images read that number and draws it.
>>> -Make sure that a HTTP-Request is made for every image on the page (my
>> adding some random number to the event link)
>>>
>>> The effect that you'll see after some reloads of the page is that some
>> images will draw 0 as SSO value instead of the number set in the page
>> @BeginRender method.
>>>
>>> I definitely beleive that tapestry should take care of this. It is a use
>> case for SSOs that is probably too common to ignore.
>>>
>>> Why can't this be automatically integrated into the
>> ApplicationStateManager?
>>>
>>> Thanks
>>>
>>> Moritz
>>>
>>>
>>>
>>>
>>> Am 23.11.2010 um 16:06 schrieb Thiago H. de Paula Figueiredo:
>>>
>>>> On Tue, 23 Nov 2010 12:30:42 -0200, Moritz Gmelin <mo...@gmx.de>
>> wrote:
>>>>
>>>>> Hi,
>>>>
>>>> Hi!
>>>>
>>>>> Is this a design problem with my application that multple threads can
>> access the sessionstateobject at the same time and thus break its uniqueness
>> or is it tapestrys fault that it does not prevent it from breaking?
>>>>
>>>> It's not Tapestry's nor the servlet container to handle concurrency on
>> session objects. I suggest you to create a service that synchronizes access
>> to your SSO and use it instead of using @SessionState and
>> ApplicationStateManger directly. Another option is to decorate or override
>> ApplicationStateManager to add thread syncronization to them.
>>>>
>>>> --
>>>> 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
>>>
>
>
> ---------------------------------------------------------------------
> 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: Threading and SSOs (again)
Posted by Moritz Gmelin <mo...@gmx.de>.
Thanks
https://issues.apache.org/jira/browse/TAP5-1355
Moritz
Am 24.11.2010 um 00:29 schrieb Josh Canfield:
> Can you put the test case into jira? I'll try to look at it over the
> holiday/weekend.
> On 23 Nov 2010 13:16, "Moritz Gmelin" <mo...@gmx.de> wrote:
>> Hi,
>>
>> I was able to create a very simple example to recreate that problem:
>>
>> -A simple page that displays 20 dynamically generated images in a loop.
>> -In the page, a SSO, holding a number value is initialized to a random
> number.
>> -Each of the dynamic images read that number and draws it.
>> -Make sure that a HTTP-Request is made for every image on the page (my
> adding some random number to the event link)
>>
>> The effect that you'll see after some reloads of the page is that some
> images will draw 0 as SSO value instead of the number set in the page
> @BeginRender method.
>>
>> I definitely beleive that tapestry should take care of this. It is a use
> case for SSOs that is probably too common to ignore.
>>
>> Why can't this be automatically integrated into the
> ApplicationStateManager?
>>
>> Thanks
>>
>> Moritz
>>
>>
>>
>>
>> Am 23.11.2010 um 16:06 schrieb Thiago H. de Paula Figueiredo:
>>
>>> On Tue, 23 Nov 2010 12:30:42 -0200, Moritz Gmelin <mo...@gmx.de>
> wrote:
>>>
>>>> Hi,
>>>
>>> Hi!
>>>
>>>> Is this a design problem with my application that multple threads can
> access the sessionstateobject at the same time and thus break its uniqueness
> or is it tapestrys fault that it does not prevent it from breaking?
>>>
>>> It's not Tapestry's nor the servlet container to handle concurrency on
> session objects. I suggest you to create a service that synchronizes access
> to your SSO and use it instead of using @SessionState and
> ApplicationStateManger directly. Another option is to decorate or override
> ApplicationStateManager to add thread syncronization to them.
>>>
>>> --
>>> 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
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Threading and SSOs (again)
Posted by Josh Canfield <jo...@gmail.com>.
Can you put the test case into jira? I'll try to look at it over the
holiday/weekend.
On 23 Nov 2010 13:16, "Moritz Gmelin" <mo...@gmx.de> wrote:
> Hi,
>
> I was able to create a very simple example to recreate that problem:
>
> -A simple page that displays 20 dynamically generated images in a loop.
> -In the page, a SSO, holding a number value is initialized to a random
number.
> -Each of the dynamic images read that number and draws it.
> -Make sure that a HTTP-Request is made for every image on the page (my
adding some random number to the event link)
>
> The effect that you'll see after some reloads of the page is that some
images will draw 0 as SSO value instead of the number set in the page
@BeginRender method.
>
> I definitely beleive that tapestry should take care of this. It is a use
case for SSOs that is probably too common to ignore.
>
> Why can't this be automatically integrated into the
ApplicationStateManager?
>
> Thanks
>
> Moritz
>
>
>
>
> Am 23.11.2010 um 16:06 schrieb Thiago H. de Paula Figueiredo:
>
>> On Tue, 23 Nov 2010 12:30:42 -0200, Moritz Gmelin <mo...@gmx.de>
wrote:
>>
>>> Hi,
>>
>> Hi!
>>
>>> Is this a design problem with my application that multple threads can
access the sessionstateobject at the same time and thus break its uniqueness
or is it tapestrys fault that it does not prevent it from breaking?
>>
>> It's not Tapestry's nor the servlet container to handle concurrency on
session objects. I suggest you to create a service that synchronizes access
to your SSO and use it instead of using @SessionState and
ApplicationStateManger directly. Another option is to decorate or override
ApplicationStateManager to add thread syncronization to them.
>>
>> --
>> 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: Threading and SSOs (again)
Posted by Moritz Gmelin <mo...@gmx.de>.
Hi,
I was able to create a very simple example to recreate that problem:
-A simple page that displays 20 dynamically generated images in a loop.
-In the page, a SSO, holding a number value is initialized to a random number.
-Each of the dynamic images read that number and draws it.
-Make sure that a HTTP-Request is made for every image on the page (my adding some random number to the event link)
The effect that you'll see after some reloads of the page is that some images will draw 0 as SSO value instead of the number set in the page @BeginRender method.
I definitely beleive that tapestry should take care of this. It is a use case for SSOs that is probably too common to ignore.
Why can't this be automatically integrated into the ApplicationStateManager?
Thanks
Moritz
Am 23.11.2010 um 16:06 schrieb Thiago H. de Paula Figueiredo:
> On Tue, 23 Nov 2010 12:30:42 -0200, Moritz Gmelin <mo...@gmx.de> wrote:
>
>> Hi,
>
> Hi!
>
>> Is this a design problem with my application that multple threads can access the sessionstateobject at the same time and thus break its uniqueness or is it tapestrys fault that it does not prevent it from breaking?
>
> It's not Tapestry's nor the servlet container to handle concurrency on session objects. I suggest you to create a service that synchronizes access to your SSO and use it instead of using @SessionState and ApplicationStateManger directly. Another option is to decorate or override ApplicationStateManager to add thread syncronization to them.
>
> --
> 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: Threading and SSOs (again)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 23 Nov 2010 12:30:42 -0200, Moritz Gmelin <mo...@gmx.de>
wrote:
> Hi,
Hi!
> Is this a design problem with my application that multple threads can
> access the sessionstateobject at the same time and thus break its
> uniqueness or is it tapestrys fault that it does not prevent it from
> breaking?
It's not Tapestry's nor the servlet container to handle concurrency on
session objects. I suggest you to create a service that synchronizes
access to your SSO and use it instead of using @SessionState and
ApplicationStateManger directly. Another option is to decorate or override
ApplicationStateManager to add thread syncronization to them.
--
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