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. TimerProblem_take2.zip
        41 kB
        Mikko Pukki
      2. wicket-4371-with_firefox.har
        163 kB
        Mikko Pukki
      3. WICKET-4371.patch
        1 kB
        Martin Grigorov
      4. TimerProblem.zip
        39 kB
        Mikko Pukki

        Activity

        Mikko Pukki created issue -
        Mikko Pukki made changes -
        Field Original Value New Value
        Attachment TimerProblem.zip [ 12512415 ]
        Mikko Pukki made changes -
        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.
        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
        Mikko Pukki made changes -
        Summary Timer problems with HttpSessionDataStore Timer problems with Internet Explorer
        Environment Jetty/Apache Tomcat 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.

        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
        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.
        Mikko Pukki made changes -
        Affects Version/s 1.4.19 [ 12317570 ]
        Martin Grigorov made changes -
        Attachment WICKET-4371.patch [ 12512549 ]
        Mikko Pukki made changes -
        Attachment wicket-4371-with_firefox.har [ 12512749 ]
        Martin Grigorov made changes -
        Assignee Igor Vaynberg [ ivaynberg ]
        Mikko Pukki made changes -
        Attachment TimerProblem_take2.zip [ 12515254 ]
        Igor Vaynberg made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Invalid [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development