Wicket
  1. Wicket
  2. WICKET-4371

Timer problems with Internet Explorer

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 1.4.19, 1.5.3, 1.5.4
    • Fix Version/s: None
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      Jetty/Apache Tomcat & Internet Explorer

      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.

      1. wicket-4371-with_firefox.har
        163 kB
        Mikko Pukki
      2. WICKET-4371.patch
        1 kB
        Martin Grigorov
      3. TimerProblem.zip
        39 kB
        Mikko Pukki
      4. TimerProblem_take2.zip
        41 kB
        Mikko Pukki

        Activity

        Hide
        Igor Vaynberg added a comment -

        closing for now. please reopen if you find a problem with wicket itself.

        Show
        Igor Vaynberg added a comment - closing for now. please reopen if you find a problem with wicket itself.
        Hide
        Ari Suutari added a comment -

        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.

        Show
        Ari Suutari added a comment - 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.
        Hide
        Igor Vaynberg added a comment -

        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...

        Show
        Igor Vaynberg added a comment - 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...
        Hide
        Ari Suutari added a comment -

        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.

        Show
        Ari Suutari added a comment - 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.
        Hide
        Igor Vaynberg added a comment -

        what exactly does that last request break?

        Show
        Igor Vaynberg added a comment - what exactly does that last request break?
        Hide
        Ari Suutari added a comment -

        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.

        Show
        Ari Suutari added a comment - 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.
        Hide
        Mikko Pukki added a comment -

        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

        Show
        Mikko Pukki added a comment - 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
        Hide
        Martin Grigorov added a comment -

        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 ?

        Show
        Martin Grigorov added a comment - 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 ?
        Hide
        Mikko Pukki added a comment -

        Fixed quickstart to demonstrate what really causes the problem

        Show
        Mikko Pukki added a comment - Fixed quickstart to demonstrate what really causes the problem
        Hide
        Martin Grigorov added a comment -

        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 ?

        Show
        Martin Grigorov added a comment - 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 ?
        Hide
        Ari Suutari added a comment -

        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.

        Show
        Ari Suutari added a comment - 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.
        Hide
        Ari Suutari added a comment -

        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.

        Show
        Ari Suutari added a comment - 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.
        Hide
        Mikko Pukki added a comment -

        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

        Show
        Mikko Pukki added a comment - 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
        Hide
        Martin Grigorov added a comment -

        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 ?

        Show
        Martin Grigorov added a comment - 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 ?
        Hide
        Mikko Pukki added a comment -
        Show
        Mikko Pukki added a comment - open with http://www.softwareishard.com/har/viewer/
        Hide
        Mikko Pukki added a comment -

        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/

        Show
        Mikko Pukki added a comment - 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/
        Hide
        Martin Grigorov added a comment -

        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.

        Show
        Martin Grigorov added a comment - 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.
        Hide
        Mikko Pukki added a comment -

        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

        Show
        Mikko Pukki added a comment - 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
        Hide
        Martin Grigorov added a comment -

        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.

        Show
        Martin Grigorov added a comment - 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.
        Hide
        Martin Grigorov added a comment -

        OK, now we have an issue
        Please update the ticket's title and description.

        Show
        Martin Grigorov added a comment - OK, now we have an issue Please update the ticket's title and description.
        Hide
        Mikko Pukki added a comment -

        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

        Show
        Mikko Pukki added a comment - 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
        Hide
        Martin Grigorov added a comment -

        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.

        Show
        Martin Grigorov added a comment - 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.
        Hide
        Mikko Pukki added a comment -

        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

        Show
        Mikko Pukki added a comment - 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
        Hide
        Martin Grigorov added a comment -

        Can you describe what exactly behaves wrong according to you ?

        Show
        Martin Grigorov added a comment - Can you describe what exactly behaves wrong according to you ?
        Hide
        Mikko Pukki added a comment -

        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

        Show
        Mikko Pukki added a comment - 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
        Hide
        Martin Grigorov added a comment -

        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.

        Show
        Martin Grigorov added a comment - 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.
        Hide
        Martin Grigorov added a comment -

        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.

        Show
        Martin Grigorov added a comment - 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.
        Hide
        Mikko Pukki added a comment -

        Also added smple debug print with println so that it would be clear what version of page is going to the store

        Show
        Mikko Pukki added a comment - Also added smple debug print with println so that it would be clear what version of page is going to the store

          People

          • Assignee:
            Igor Vaynberg
            Reporter:
            Mikko Pukki
          • Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development