Getting closer.
In the cases where it happens, the binding and unbinding is called after
cleanup from different threads. Threads are named btpool0-1 -btpool0-7.
But as I said, this happens only about every second time I start my jetty
server. The other times, the binding- unbinding is called only once for each
page request.
M.
10-10-14 23:13:47.075 [DEBUG]
de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1596)
session 95wqzf1oyaps asoHash 1646600475
10-10-14 23:13:47.075 [DEBUG]
de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)
session 95wqzf1oyaps asoHash 1646600475 name
sso:de.example.aso.CurrentSessionASO thread btpool0-1
10-10-14 23:13:47.089 [DEBUG]
de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1596)
session 95wqzf1oyaps asoHash 1646600475
10-10-14 23:13:47.089 [DEBUG]
de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)
session 95wqzf1oyaps asoHash 1646600475 name
sso:de.example.aso.CurrentSessionASO thread btpool0-7
10-10-14 23:13:47.091 [DEBUG]
de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1596)
session 95wqzf1oyaps asoHash 1646600475
10-10-14 23:13:47.091 [DEBUG]
de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)
session 95wqzf1oyaps asoHash 1646600475 name
sso:de.example.aso.CurrentSessionASO thread btpool0-1
10-10-14 23:13:47.091 [DEBUG]
de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1596)
session 95wqzf1oyaps asoHash 1646600475
10-10-14 23:13:47.092 [DEBUG]
de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)
session 95wqzf1oyaps asoHash 1646600475 name
sso:de.example.aso.CurrentSessionASO thread btpool0-5
10-10-14 23:13:47.098 [DEBUG]
de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1596)
session 95wqzf1oyaps asoHash 1646600475
10-10-14 23:13:47.098 [DEBUG]
de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)
session 95wqzf1oyaps asoHash 1646600475 name
sso:de.example.aso.CurrentSessionASO thread btpool0-3
10-10-14 23:13:47.104 [DEBUG]
de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1596)
session 95wqzf1oyaps asoHash 1646600475
10-10-14 23:13:47.105 [DEBUG]
de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)
session 95wqzf1oyaps asoHash 1646600475 name
sso:de.example.aso.CurrentSessionASO thread btpool0-4
Am 14.10.2010 um 22:04 schrieb Moritz Gmelin:
> Hi,
>
> I added the logging as you suggested. This is part of the logging for a
> _SINGLE_ page request. CurrentSessionASO is our SSO.
>
> 10-10-14 21:51:12.049 [DEBUG]
> de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)
> session 1vsqjhkzdsj37 asoHash 1363402032
> 10-10-14 21:51:12.066 [DEBUG]
> de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1595)
> session 1vsqjhkzdsj37 asoHash 1363402032
> 10-10-14 21:51:12.066 [DEBUG]
> de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)
> session 1vsqjhkzdsj37 asoHash 1363402032
> 10-10-14 21:51:12.069 [DEBUG]
> de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1595)
> session 1vsqjhkzdsj37 asoHash 1363402032
> 10-10-14 21:51:12.070 [DEBUG]
> de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)
> session 1vsqjhkzdsj37 asoHash 1363402032
> 10-10-14 21:51:12.073 [DEBUG]
> de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1595)
> session 1vsqjhkzdsj37 asoHash 1363402032
> 10-10-14 21:51:12.074 [DEBUG]
> de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)
> session 1vsqjhkzdsj37 asoHash 950050904
> 10-10-14 21:51:12.074 [INFO]
> de.example.services.AppModule$3.create(AppModule.java:220) New
> CurrentSessionASO object created CurrentSessionASO{user:0, account:0,
> patient:0, project:, hash:950050904} for session 1vsqjhkzdsj37
> 10-10-14 21:51:12.077 [DEBUG]
> de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1595)
> session 1vsqjhkzdsj37 asoHash 950050904
> 10-10-14 21:51:12.079 [DEBUG]
> de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)
> session 1vsqjhkzdsj37 asoHash 1363402032
> 10-10-14 21:51:12.080 [DEBUG]
> de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1595)
> session 1vsqjhkzdsj37 asoHash 1363402032
> 10-10-14 21:51:12.080 [DEBUG]
> de.example.aso.CurrentSessionASO.valueBound(CurrentSessionASO.java:1587)
> session 1vsqjhkzdsj37 asoHash 950050904
> 10-10-14 21:51:12.084 [DEBUG]
> de.example.aso.CurrentSessionASO.valueUnbound(CurrentSessionASO.java:1595)
> session 1vsqjhkzdsj37 asoHash 950050904
>
> You can see that the CurrentSessionASO is bound and unbound many times for a
> signel page request. Sometimes (as you can see in the log here), a new
> CurrentSessionASO object is created for the same session. This is done in my
> ApplicationStateManagerContribution in AppModule. Most often times, there is
> no new SSO created (correct behaviour).
>
> I'm starting the applcation here locally in a jetty environment. One weird
> observation is also that about half of the startups of the application the
> situation is totally different. Then, our SSO is only bound and unbound once
> per page request, as I would expect. But the other times the situation as
> above happens, that for every page request binding and unbinding happens
> about 20 times. and sometimes a new SSO is created inbetween.
>
> Next thing to notice is that this all happens after the cleanup method of the
> page is called.
>
> Thanks
>
> Moritz
>
>
>
> Am 14.10.2010 um 19:13 schrieb Howard Lewis Ship:
>
>> Tapestry manages persistent state in the HttpSession. As of 5.2, it
>> doesn't do anything special to handle cases of multiple requests
>> (perhaps due to Ajax) attempting to modify the same SSO in multiple
>> threads.
>>
>> This aligns with Brian Goetz's observation that all stateful web
>> applications are inherently broken:
>>
>> http://www.ibm.com/developerworks/library/j-jtp09238.html
>>
>> I'm not aware of any concerns. You may want to have your SSO
>> implement the HttpSessionBindingListener interface, and log the
>> details of when it is bound (saved to the HttpSession). That might
>> illuminate what's going on.
>>
>> It may be a bug in your servlet container, it may be a race condition
>> between threads, or it may just be a coding problem in your code. I
>> hate to say it, but the last option is the most likely (given the
>> total lack of information you've provided).
>>
>> On Thu, Oct 14, 2010 at 3:01 AM, Moritz Gmelin <[email protected]> wrote:
>>> Hi,
>>>
>>> since upgradeing to Tapestry 5.2 (5.2.0 and 5.2.1) we sometimes obseve that
>>> the contents of our SessionStateObject gets lost.
>>> The Session-ID between 2 requests is identical, but the Hashcode of the
>>> @SessionState object changes and thus the contents are lost.
>>> If everything works correctly, the getHashCode() of the SessionState object
>>> does not change between requests. But in the case where our SessionState
>>> objects get lost beweeen requests, obviousely a new SessionState object
>>> gets created.
>>> This happens only in very rare cases but if it does, our users get chucked
>>> out of their pages.
>>> This has not happened with t5.1.0.5 as far as we can see.
>>>
>>> Has anyone else seen this problem yet? Any hints about a possible solution?
>>>
>>> Thanks
>>>
>>> Moritz
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>>
>>
>> --
>> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
