[ https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Josh Canfield reassigned TAP5-1355: ----------------------------------- Assignee: Josh Canfield > Threading issue with SessionStateObjects > ---------------------------------------- > > Key: TAP5-1355 > URL: https://issues.apache.org/jira/browse/TAP5-1355 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core > Affects Versions: 5.2.4 > Reporter: Moritz Gmelin > Assignee: Josh Canfield > Attachments: Screenshot.png.jpg, taptest.tgz > > > When a page request consists of multiple HTTP request (e.g. page and some > dynamically generated images) and all those requests access a > SessionStateObject, it happens that a new session (with an empty SSO) is > created for some of the request threads. > 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 (by > adding some random number to the event link) > The effect that you'll see after some reloads of the page (maybe you need to > reload 30 times) is that some images will draw 0 as SSO value instead of the > number set in the page @BeginRender method. Those fields will be marked in > red in the demo so you can quickly see them. > 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? > > The demo has been deployed here > http://www.avetana.de/taptest/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.