[jira] Commented: (TAP5-1355) Threading issue with SessionStateObjects
[ https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978691#action_12978691 ] Moritz Gmelin commented on TAP5-1355: - Hi, is there any progress on this? Any chance that this will be fixed in 5.2.4.1? Moritz 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 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.
[jira] Created: (TAP5-1355) Threading issue with SessionStateObjects
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 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? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1355) Threading issue with SessionStateObjects
[ https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moritz Gmelin updated TAP5-1355: Attachment: taptest.tgz 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 Attachments: 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? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1355) Threading issue with SessionStateObjects
[ https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moritz Gmelin updated TAP5-1355: Description: 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/ was: 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? 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 Attachments: 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.
[jira] Updated: (TAP5-1355) Threading issue with SessionStateObjects
[ https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moritz Gmelin updated TAP5-1355: Attachment: Screenshot.png.jpg This is how it looks like when some of the images get a new session 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 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.
