You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Mikko Pukki (Created) (JIRA)" <ji...@apache.org> on 2012/01/30 14:42:10 UTC
[jira] [Created] (WICKET-4371) Timer problems with
HttpSessionDataStore
Timer problems with HttpSessionDataStore
----------------------------------------
Key: WICKET-4371
URL: https://issues.apache.org/jira/browse/WICKET-4371
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.5.4, 1.5.3
Environment: Jetty/Apache Tomcat
Reporter: Mikko Pukki
Hi,
We are encountering problems on all pages that have timers for updating/polling new data.
It seems that if new page is rendering, timer's request can mess things up. Problem can be
reproduced with Wicket 1.5.3 and 1.5.4
An example situation:
1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
2) Request is being processed at server and page with id2 is rendered
3) While still in render phase timer makes new request to a server
Timer's request is handled even if there is a new rendered page. Timer's request is now last request
handled and page that contained timer is last page stored at PageTable. This causes weird problems with
our applications.
Session store is created at application's init:
setPageManagerProvider(new DefaultPageManagerProvider(this) {
@Override
protected IDataStore newDataStore()
{
return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
}
});
I'm wondering that why any request that is meant for previous versions of pages are processed?
In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Ari Suutari (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213388#comment-13213388 ]
Ari Suutari commented on WICKET-4371:
-------------------------------------
For end-users the problem shows as page which renders odd data. For example, imagine a three-page application:
page1 has link to page2
page2 has link to page3 and "backwards" link to page1. page2 also has timer running.
page3 has "backwards" link to page2.
These links are in a tree component in real application and the tree is updated by ajax requests.
Now user clicks link on page1 to navigate to page2. Page2 renders and timer starts. User clicks link to navigate to page3. Timer backfires and causes
wicket side of application to think that user has gone back to page2. At this point user doesn't notice anything, but if backward link is clicked
tree state from page1 is rendered to browser.
Maybe we should further develop the quickstart example to reflect the real application, which has those links in a tree component. This is a little bit difficult to debug since the problem is related
to timing.
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: TimerProblem.zip, TimerProblem_take2.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with
HttpSessionDataStore
Posted by "Mikko Pukki (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196166#comment-13196166 ]
Mikko Pukki commented on WICKET-4371:
-------------------------------------
Of course, my bad! Sorry, forgot to mention that I tested with Internet Explorer. Tried also now with Firefox
and there it seems to works just as it should. Confirmed also with firebug.
Tried now with ie7, ie8, ie9 and some different document modes and happens with all of them.
When new Page is rendered:
URL Method Result Type Received Taken Initiator Wait Start Request Response Cache read Gap
http://localhost:8080/wicket/page?1 GET 200 text/html 2,78 KB 16 ms navigate -172 0 16 0 0 125
And after that:
URL Method Result Type Received Taken Initiator Wait Start Request Response Cache read Gap
/?0-1.IBehaviorListener.0-&random=0.7431589526621849 GET 200 text/xml 476 B 141 ms -172 16 125 0 0 0
And with that get:
Key Value
Referer http://localhost:8080/?0
So it seems to be ie only problem. Too bad Developer tools wont retain requests from previous page so that it would show sequentially all requests.
-Mikko
> Timer problems with HttpSessionDataStore
> ----------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> Session store is created at application's init:
> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IDataStore newDataStore()
> {
> return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
> }
> });
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Mikko Pukki (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197822#comment-13197822 ]
Mikko Pukki commented on WICKET-4371:
-------------------------------------
Hi,
I tried the patch with 1.5.4 and it truly seemed that it helped. Until my colleague pointed out that this happens also on Firefox.
So we tested with 3.6.25, 9.x and 10.x versions. The quickstart seemed to work, but in our real life applications this error still exists (in both, ie and Firefox).
Almost all of our pages are stateful and have some kind of timers to update the content. When changing page through our menu,
maybe once in every 10 to 40 times, timer request from previous page is sent after new page is rendered. This must be some kind of
timing problem? I'll attach a file that contains requests sent from Firefox. It can be viewed with http://www.softwareishard.com/har/viewer/
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip, WICKET-4371.patch
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197830#comment-13197830 ]
Martin Grigorov commented on WICKET-4371:
-----------------------------------------
Can you re-check that your real app does use the new wicket-ajax.js and your browser doesn't use the old one from the cache ?
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211311#comment-13211311 ]
Martin Grigorov commented on WICKET-4371:
-----------------------------------------
Wicket queues all Ajax requests in special channels at the client side. Unless you provide custom channel (see AjaxChannel class) the default is "0|s" which should be read : a channel with name "0" and type "queue". Each scheduled request is executed after the previous says it is done by calling Wicket.channelManager.done(channel). With my patch I reset all queues (for all channels, no matter what their name is because we are going to redirect).
I cannot reproduce the problem with the attached quickstart after applying the patch.
I understand that the solution in Wicket 1.4 and earlier was to ignore the request at the server side by executing EmptyAjaxRequestTarget. This is an option for a possible fix in 1.5 but I think the problem can be solved completely at the client side.
@ other devs: opinions ?
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: TimerProblem.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196191#comment-13196191 ]
Martin Grigorov commented on WICKET-4371:
-----------------------------------------
The problem is wicket-ajax.js, stateChangeCallback, line 996:
// In case the page isn't really redirected. For example say the redirect is to an octet-stream.
// A file download popup will appear but the page in the browser won't change.
this.done();
this.successHandler();
this code executes the scheduled actions in the channel (i.e. the timer behavior).
I tried to solve the problem by moving these lines after "window.location=..." calls but they are executed again.
Anyone ideas how to solve this ?
I can it only as an additional setting for Wicket.Ajax.Request that decides whether to call those or not.
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Mikko Pukki (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196209#comment-13196209 ]
Mikko Pukki commented on WICKET-4371:
-------------------------------------
I decided to revisit wicket-1971 because some applications using wicket 1.4.19 have also been experiencing
problems with timer. Test case in wicket-1971 works ok but this new issue also affects 1.4.19.
I updated "Affects Version/s" to include 1.4.19
-Mikko
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with
HttpSessionDataStore
Posted by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196155#comment-13196155 ]
Martin Grigorov commented on WICKET-4371:
-----------------------------------------
I don't see logs where page id less than the previous is printed.
You can also verify with the current request url. Or you can check with Firebug to see that timer's url is not issued after link's link.
> Timer problems with HttpSessionDataStore
> ----------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> Session store is created at application's init:
> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IDataStore newDataStore()
> {
> return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
> }
> });
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with
HttpSessionDataStore
Posted by "Mikko Pukki (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196124#comment-13196124 ]
Mikko Pukki commented on WICKET-4371:
-------------------------------------
Also added smple debug print with println so that it would be clear what version of page is going to the store
> Timer problems with HttpSessionDataStore
> ----------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> Session store is created at application's init:
> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IDataStore newDataStore()
> {
> return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
> }
> });
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Mikko Pukki (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikko Pukki updated WICKET-4371:
--------------------------------
Affects Version/s: 1.4.19
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4371) Timer problems with
HttpSessionDataStore
Posted by "Mikko Pukki (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikko Pukki updated WICKET-4371:
--------------------------------
Attachment: TimerProblem.zip
> Timer problems with HttpSessionDataStore
> ----------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> Session store is created at application's init:
> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IDataStore newDataStore()
> {
> return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
> }
> });
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Mikko Pukki (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikko Pukki updated WICKET-4371:
--------------------------------
Attachment: TimerProblem_take2.zip
Fixed quickstart to demonstrate what really causes the problem
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: TimerProblem.zip, TimerProblem_take2.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Ari Suutari (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204466#comment-13204466 ]
Ari Suutari commented on WICKET-4371:
-------------------------------------
Hi,
I'm the colleague who was still able to reproduce this. This looks very similar to case we had years ago, with wicket 1.1/1.2 (don't remember the
exact version). Here is a link to that conversation:
http://apache-wicket.1842946.n4.nabble.com/Problems-with-AjaxSelfUpdatingTimerBehavior-and-buttons-on-same-page-td1915564.html
I think that Igor added "ignoreIfNotActive" flag to timer request URL:s and after that it worked, because that allowed server side to ignore timer request that were fired after user left the page.
Ari S.
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Igor Vaynberg (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213721#comment-13213721 ]
Igor Vaynberg commented on WICKET-4371:
---------------------------------------
do you somehow depend on what the last accessed page was? because you say that "Timer backfires and causes
wicket side of application to think that user has gone back to page2", but nothing in wicket cares about that, so it must be something in your application?
in 1.1/1.2 these kinds of accesses caused a problem with page versioning, thats why they were fixed with ignoreIfNotActive. in 1.5 with the unified page id/version parameter there is no more such problems.
you go to page 3
timer hits page 2
wicket renders page 2
user clicks a link on page 3
page 3 is pulled from diskstore
everything continues as normal, at least from vanilla wicket side.
you need to describe more about exactly what and how the access to page 2 breaks...
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: TimerProblem.zip, TimerProblem_take2.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with
HttpSessionDataStore
Posted by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196140#comment-13196140 ]
Martin Grigorov commented on WICKET-4371:
-----------------------------------------
Actually the timer is not executed at all after clicking the link.
Clicking the link schedules page1 to be saved (touches the page) and rendering page2 also schedules it for storing. This is the reason to see these log statements.
> Timer problems with HttpSessionDataStore
> ----------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> Session store is created at application's init:
> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IDataStore newDataStore()
> {
> return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
> }
> });
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with
HttpSessionDataStore
Posted by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196138#comment-13196138 ]
Martin Grigorov commented on WICKET-4371:
-----------------------------------------
What is the problem exactly ?
I don't see how HttpSessionDataStore is involved.
Here is what happens:
1. the timer executes regularly
2. the user clicks on the link
3. the next timer is queued at the client side and waits for the link's ajax response to be processed
4. the timer is executed
The problem is at point 4 but you get the same behavior with DiskDataStore as well.
> Timer problems with HttpSessionDataStore
> ----------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> Session store is created at application's init:
> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IDataStore newDataStore()
> {
> return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
> }
> });
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Mikko Pukki (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikko Pukki updated WICKET-4371:
--------------------------------
Description:
Hi,
We are encountering problems on all pages that have timers for updating/polling new data.
It seems that if new page is rendering, timer's request can mess things up. Problem can be
reproduced with Wicket 1.5.3 and 1.5.4
An example situation:
1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
2) Request is being processed at server and page with id2 is rendered
3) While still in render phase timer makes new request to a server
Timer's request is handled even if there is a new rendered page. Timer's request is now last request
handled and page that contained timer is last page stored at PageTable. This causes weird problems with
our applications.
I'm wondering that why any request that is meant for previous versions of pages are processed?
In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
In the quickstart there is PageB -link. Pressing that invokes this behavior
There is also custom store in quickstart that provider simple debug logging.
was:
Hi,
We are encountering problems on all pages that have timers for updating/polling new data.
It seems that if new page is rendering, timer's request can mess things up. Problem can be
reproduced with Wicket 1.5.3 and 1.5.4
An example situation:
1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
2) Request is being processed at server and page with id2 is rendered
3) While still in render phase timer makes new request to a server
Timer's request is handled even if there is a new rendered page. Timer's request is now last request
handled and page that contained timer is last page stored at PageTable. This causes weird problems with
our applications.
Session store is created at application's init:
setPageManagerProvider(new DefaultPageManagerProvider(this) {
@Override
protected IDataStore newDataStore()
{
return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
}
});
I'm wondering that why any request that is meant for previous versions of pages are processed?
In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
In the quickstart there is PageB -link. Pressing that invokes this behavior
Environment: Jetty/Apache Tomcat & Internet Explorer (was: Jetty/Apache Tomcat)
Summary: Timer problems with Internet Explorer (was: Timer problems with HttpSessionDataStore)
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Martin Grigorov (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Grigorov reassigned WICKET-4371:
---------------------------------------
Assignee: Igor Vaynberg
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: TimerProblem.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with
HttpSessionDataStore
Posted by "Mikko Pukki (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196154#comment-13196154 ]
Mikko Pukki commented on WICKET-4371:
-------------------------------------
Hi,
It seems that something (the timer?) touches first page after rendering the other page.
quickstart gives logging like this with slow onAfterRender on HomePage2:
com.mycompany.WicketApplication$1$1@633e6346 ###### Page id: 0
com.mycompany.WicketApplication$1$1@633e6346 ###### Page id: 0
com.mycompany.WicketApplication$1$1@633e6346 ###### Page id: 0
com.mycompany.WicketApplication$1$1@633e6346 ###### Page id: 1 <--- Page 2 render?
com.mycompany.WicketApplication$1$1@633e6346 ###### Page id: 0 <--- This here?
But when thread.sleep is removed:
com.mycompany.WicketApplication$1$1@7b6bb7d9 ###### Page id: 0
com.mycompany.WicketApplication$1$1@7b6bb7d9 ###### Page id: 0
com.mycompany.WicketApplication$1$1@7b6bb7d9 ###### Page id: 0
com.mycompany.WicketApplication$1$1@7b6bb7d9 ###### Page id: 0
com.mycompany.WicketApplication$1$1@7b6bb7d9 ###### Page id: 1 <--- Page 2 render
-Mikko
> Timer problems with HttpSessionDataStore
> ----------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> Session store is created at application's init:
> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IDataStore newDataStore()
> {
> return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
> }
> });
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Mikko Pukki (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211915#comment-13211915 ]
Mikko Pukki commented on WICKET-4371:
-------------------------------------
Hi,
Ari sent me a comment considering the fact that requests just might come to the server in different order than they were initiated from the browser.
This was actually my initial thought but I did not consider that as a viable option when testing locally. However if there are any filters before WicketFilter
that could in some/any situations cause delays to request, there is a real problem. Actually random network delays present the same problem.
In the new quickstart delay is removed from HomePage2's onAfterRender. I added another filter (com.mycompany.DelayFilter) in front of WicketFilter to put some delay to all other
requests than timer requests. Ok, it is not pretty but it does what it is supposed to do :). It sleeps 1500 ms if request is not from timer.
com.mycompany.WicketApplication$1$1@469695f ###### Page id: 0
com.mycompany.WicketApplication$1$1@469695f ###### Page id: 0
com.mycompany.WicketApplication$1$1@469695f ###### Page id: 1
com.mycompany.WicketApplication$1$1@469695f ###### Page id: 0
com.mycompany.WicketApplication$1$1@469695f ###### Page id: 0
Now I managed to get two requests for the next page but it is only because of the long delay
And Martin, no you should not make a diff, hadn't just thought yet what to say about the new quickstart :)
in pom.xml "<wicket.version>1.5.X</wicket.version>" is 1.5.4 from my own maven repository including the changes you suggested earlier.
-Mikko
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: TimerProblem.zip, TimerProblem_take2.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with
HttpSessionDataStore
Posted by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196145#comment-13196145 ]
Martin Grigorov commented on WICKET-4371:
-----------------------------------------
Can you describe what exactly behaves wrong according to you ?
> Timer problems with HttpSessionDataStore
> ----------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> Session store is created at application's init:
> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IDataStore newDataStore()
> {
> return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
> }
> });
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211910#comment-13211910 ]
Martin Grigorov commented on WICKET-4371:
-----------------------------------------
Please tell us what is changed and what really causes the problem.
Or should I diff it to the previous one to see what happens ? ;-)
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: TimerProblem.zip, TimerProblem_take2.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Mikko Pukki (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikko Pukki updated WICKET-4371:
--------------------------------
Attachment: wicket-4371-with_firefox.har
open with http://www.softwareishard.com/har/viewer/
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Ari Suutari (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214365#comment-13214365 ]
Ari Suutari commented on WICKET-4371:
-------------------------------------
Ok, I see, I wasn't aware that 1.5 is *that* smart with things. I took a look at application code, it looks that the tree that renders the links is implemented so that it's ITreeState is kept in session instead of member in Page class.
Maybe this causes the problems, because this causes that tree information is not part of diskstore versioning mechanism you describe. When timer changes it's state back to that of page2 it is not restored when page3 is pulled from diskstore.
So this starts to look more and more a problem with our application only.
Thank you for explaining 1.5 logic.
Ari S.
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: TimerProblem.zip, TimerProblem_take2.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Ari Suutari (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13210191#comment-13210191 ]
Ari Suutari commented on WICKET-4371:
-------------------------------------
I was thinking why the proposed patch doesn't completely fix the issue although it makes it harder to reproduce. I understood that the patch modifies things so that after the redirect response has been received timers on old page are ignored.
Could it be that timer fires after clicking the link but *before* the redirect response comes in ? The timeframe is smaller of course (about lenght of redirect request processing) but this could explain why I am still able to reproduces the problem.
To prove if this theory is correct or not we would need to insert some kind of artificial delay for each web server request.
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: TimerProblem.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Ari Suutari (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212462#comment-13212462 ]
Ari Suutari commented on WICKET-4371:
-------------------------------------
I think there is a slight misunderstanding here. The issue is not caused by browser requests coming to server in different order than sent by browser.
However, with pending javascript timer there are two different problem scenarios:
1) User clicks link, request goes to server, it is processed by wicket application and redirect response is sent back. After that javascript timer fires. I think that the proposed patch handles this case very well.
2) User clicks link, request goes to server for processing. But before the response is received by browser end the javascript timer fires a request to server. This seems to confuse wicket application on server side, because it might have completed redirect processing already. This results in some kind of mismatch between application states in browser and server, the server thinks that user wanted to go back to first page (because the timer request came from that) but browser sits happily on new page. To handle this on browser side ajax/javascript stuff it would be necessary to block timer
requests totally if there is some other ajax call in progress.
These problems occur more easily if network link is a little bit slow. That is the reason for Mikko trying to demonstrate to problem for adding
delay into application code. Otherwise it would be difficult to hit correct timeframe with clicking (in real application it might take tens of clicks to
hit the problem).
Regards,
Ari S.
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: TimerProblem.zip, TimerProblem_take2.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4371) Timer problems with
HttpSessionDataStore
Posted by "Mikko Pukki (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikko Pukki updated WICKET-4371:
--------------------------------
Description:
Hi,
We are encountering problems on all pages that have timers for updating/polling new data.
It seems that if new page is rendering, timer's request can mess things up. Problem can be
reproduced with Wicket 1.5.3 and 1.5.4
An example situation:
1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
2) Request is being processed at server and page with id2 is rendered
3) While still in render phase timer makes new request to a server
Timer's request is handled even if there is a new rendered page. Timer's request is now last request
handled and page that contained timer is last page stored at PageTable. This causes weird problems with
our applications.
Session store is created at application's init:
setPageManagerProvider(new DefaultPageManagerProvider(this) {
@Override
protected IDataStore newDataStore()
{
return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
}
});
I'm wondering that why any request that is meant for previous versions of pages are processed?
In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
In the quickstart there is PageB -link. Pressing that invokes this behavior
was:
Hi,
We are encountering problems on all pages that have timers for updating/polling new data.
It seems that if new page is rendering, timer's request can mess things up. Problem can be
reproduced with Wicket 1.5.3 and 1.5.4
An example situation:
1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
2) Request is being processed at server and page with id2 is rendered
3) While still in render phase timer makes new request to a server
Timer's request is handled even if there is a new rendered page. Timer's request is now last request
handled and page that contained timer is last page stored at PageTable. This causes weird problems with
our applications.
Session store is created at application's init:
setPageManagerProvider(new DefaultPageManagerProvider(this) {
@Override
protected IDataStore newDataStore()
{
return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
}
});
I'm wondering that why any request that is meant for previous versions of pages are processed?
In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> Timer problems with HttpSessionDataStore
> ----------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> Session store is created at application's init:
> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IDataStore newDataStore()
> {
> return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
> }
> });
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Martin Grigorov (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Grigorov updated WICKET-4371:
------------------------------------
Attachment: WICKET-4371.patch
A patch for 1.5.x that solves the problem by resetting the channel manager. This way we drop all scheduled tasks when a redirect response comes. This may break partially some applications which download resource with "window.location=... " and then execute another Ajax call. In this case the user will have to repeat the action that schedules the second Ajax call.
Feedback is welcome.
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip, WICKET-4371.patch
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Igor Vaynberg (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212837#comment-13212837 ]
Igor Vaynberg commented on WICKET-4371:
---------------------------------------
what exactly does that last request break?
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: TimerProblem.zip, TimerProblem_take2.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Igor Vaynberg (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg resolved WICKET-4371.
-----------------------------------
Resolution: Invalid
closing for now. please reopen if you find a problem with wicket itself.
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: TimerProblem.zip, TimerProblem_take2.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with Internet
Explorer
Posted by "Mikko Pukki (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197852#comment-13197852 ]
Mikko Pukki commented on WICKET-4371:
-------------------------------------
Hi,
That was my initial thoughts exactly.
>From firebug wicket-ajax.js lines 1010 to 1012:
1010 Wicket.Log.info("Redirecting to: "+text);
1011 Wicket.channelManager.channels = {};
1012 window.location=text;
and:
692 t.onreadystatechange = Wicket.emptyFunction;
693 Wicket.channelManager.channels = {};
694 this.done();
Developer tools in Internet Explorer show the same. Line numbers may or may not be exact because I applied
the changes by hand.
In Internet Explorer the behavior stays the same as it was before:
1st request to page:
http://localhost/SyncWare/wicket/bookmarkable/syncrontech.common.cluster.ClusterPage?35 GET 200 text/html 59,17 KB 140 ms navigate 0 0 16 124 0 195002
2nd request:
/SyncWare/wicket/page?34-1.IBehaviorListener.0-pageContent-uiPanel-topPanel-icons-0-icon-indicator&random=0.7190102663417967 GET 200 text/xml 0,69 KB 1.01 s 16 0 1014 0 0 265981
Before the patch I was able to get this with Internet Explorer all the time if rendering was slower than timer's timeout.
Now it is random. Sometimes it takes ~40 page traversals and sometimes happens with the first try.
-Mikko
> Timer problems with Internet Explorer
> -------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19, 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat & Internet Explorer
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip, WICKET-4371.patch, wicket-4371-with_firefox.har
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with
HttpSessionDataStore
Posted by "Mikko Pukki (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196143#comment-13196143 ]
Mikko Pukki commented on WICKET-4371:
-------------------------------------
Actually that's true, it should not matter if it is disk storage or httpsession.
I guess that it did matter when using 1.3 or 1.4 because handling was a little bit different?
-Mikko
> Timer problems with HttpSessionDataStore
> ----------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> Session store is created at application's init:
> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IDataStore newDataStore()
> {
> return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
> }
> });
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4371) Timer problems with
HttpSessionDataStore
Posted by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196171#comment-13196171 ]
Martin Grigorov commented on WICKET-4371:
-----------------------------------------
OK, now we have an issue :-)
Please update the ticket's title and description.
> Timer problems with HttpSessionDataStore
> ----------------------------------------
>
> Key: WICKET-4371
> URL: https://issues.apache.org/jira/browse/WICKET-4371
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3, 1.5.4
> Environment: Jetty/Apache Tomcat
> Reporter: Mikko Pukki
> Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> Session store is created at application's init:
> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IDataStore newDataStore()
> {
> return new HttpSessionDataStore(new DefaultPageManagerContext(), new PageNumberEvictionStrategy(12));
> }
> });
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira