ICEfaces
  1. ICEfaces
  2. ICE-7242

Updates fetched during push now contain redundant ViewState update

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.2
    • Fix Version/s: 2.1-Beta2, 3.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces + ICEpush
    • Assignee Priority:
      P2

      Description

      Using auction 2.0 in a test I observed the following:

      Previously, we would POST a blocking request to listen for updates

      POST http://localhost:8080/auction/javax.faces.resource/listen.icepush.jsf

      and get a response once a second:

      <notified-pushids>apushId</notified-pushids>


      Then fetch the update:
      POST http://localhost:8080/auction/auction.jsf

      and the update would be something like:

      <?xml version='1.0' encoding='UTF-8'?>
      <partial-response><changes><update id="rpt1:0:otime"><![CDATA[<span id="rpt1:0:otime">7d 1:54:53</span>]]></update><update id="rpt1:1:otime"><![CDATA[<span id="rpt1:1:otime">3d 4:54:44</span>]]></update><update id="rpt1:2:otime"><![CDATA[<span id="rpt1:2:otime">2d 7:55:34</span>]]></update><update id="rpt1:3:otime"><![CDATA[<span id="rpt1:3:otime">7:54:49</span>]]></update><update id="javax.faces.ViewState"><![CDATA[4506655347714165083:6047748643060694507]]></update></changes></partial-response>


      This would occur once a second. Now, however, we're getting two updates per second. The first is similar to the above as the clock polls, but the second update seems to contain a change only to the ViewState key.


      POST http://localhost:8080/auction/javax.faces.resource/listen.icepush.jsf


      ?xml version='1.0' encoding='UTF-8'?>
      <partial-response><changes><update id="javax.faces.ViewState"><![CDATA[4506655347714165083:6047748643060694507]]></update></changes></partial-response>



      Comparing the javax.faces.ViewState field from both updates, they are seen to be equal, so the second update is entirely redundant.
      <![CDATA[4506655347714165083:6047748643060694507]]>

      <![CDATA[4506655347714165083:6047748643060694507]]>


      This means we're doing 2 pairs of requests every second.

        Issue Links

          Activity

          Greg Dick created issue -
          Hide
          Greg Dick added a comment -

          Here's a sample of the traffic showing four requests per second:

          [9.5908s] – POST /auction/javax.faces.resource/listen.icepush.xml.jsf HTTP/1.1
          [9.5985s] – POST /auction/javax.faces.resource/listen.icepush.xml.jsf HTTP/1.1
          [9.6387s] – POST /auction/auction.jsf HTTP/1.1
          [10.589s] – POST /auction/auction.jsf HTTP/1.1
          [10.595s] – POST /auction/javax.faces.resource/listen.icepush.xml.jsf HTTP/1.1
          [10.605s] – POST /auction/javax.faces.resource/listen.icepush.xml.jsf HTTP/1.1
          [10.628s] – POST /auction/auction.jsf HTTP/1.1
          [11.595s] – POST /auction/auction.jsf HTTP/1.1

          And the traffic. The two blocking requests arrive only 10ms apart. This is similar to what Deryk has seen.

          [13.588s]
          HTTP/1.1 200 OK
          Server: Apache-Coyote/1.1
          X-Powered-By: JSF/2.0
          Cache-Control: no-cache
          Cache-Control: no-store
          Cache-Control: must-revalidate
          Pragma: no-cache
          Expires: 0
          Content-Type: text/xml;charset=UTF-8
          Content-Length: 46
          Date: Tue, 04 Oct 2011 16:22:42 GMT

          <notified-pushids>vd8pt42</notified-pushids>

          [13.598s]
          HTTP/1.1 200 OK
          Server: Apache-Coyote/1.1
          X-Powered-By: JSF/2.0
          Cache-Control: no-cache
          Cache-Control: no-store
          Cache-Control: must-revalidate
          Pragma: no-cache
          Expires: 0
          Content-Type: text/xml;charset=UTF-8
          Content-Length: 46
          Date: Tue, 04 Oct 2011 16:22:42 GMT

          <notified-pushids>vd8pt42</notified-pushids>

          [13.673s] [13.645s]
          HTTP/1.1 200 OK
          Server: Apache-Coyote/1.1
          X-Powered-By: JSF/2.0
          Cache-Control: no-cache
          Content-Type: text/xml;charset=UTF-8
          Content-Length: 541
          Date: Tue, 04 Oct 2011 16:22:43 GMT

          <?xml version='1.0' encoding='UTF-8'?>
          <partial-response><changes><update id="rpt1:0:otime"><Unable to render embedded object: File (0:otime">7d 1:58:19</span>]]></update><update id="rpt1:1:otime"><) not found.[CDATA[<span id="rpt1:1:otime">3d 4:58:10</span>]]></update><update id="rpt1:2:otime"><Unable to render embedded object: File (2:otime">2d 7:59:00</span>]]></update><update id="rpt1:3:otime"><) not found.[CDATA[<span id="rpt1:3:otime">7:58:15</span>]]></update><update id="javax.faces.ViewState"><![CDATA[-1441829653106995469:-1044112092089002795]]></update></changes></partial-response>

          HTTP/1.1 200 OK
          Server: Apache-Coyote/1.1
          X-Powered-By: JSF/2.0
          Cache-Control: no-cache
          Content-Type: text/xml;charset=UTF-8
          Content-Length: 192
          Date: Tue, 04 Oct 2011 16:22:43 GMT

          <?xml version='1.0' encoding='UTF-8'?>
          <partial-response><changes><update id="javax.faces.ViewState"><![CDATA[-1441829653106995469:-1044112092089002795]]></update></changes></partial-response>

          Show
          Greg Dick added a comment - Here's a sample of the traffic showing four requests per second: [9.5908s] – POST /auction/javax.faces.resource/listen.icepush.xml.jsf HTTP/1.1 [9.5985s] – POST /auction/javax.faces.resource/listen.icepush.xml.jsf HTTP/1.1 [9.6387s] – POST /auction/auction.jsf HTTP/1.1 [10.589s] – POST /auction/auction.jsf HTTP/1.1 [10.595s] – POST /auction/javax.faces.resource/listen.icepush.xml.jsf HTTP/1.1 [10.605s] – POST /auction/javax.faces.resource/listen.icepush.xml.jsf HTTP/1.1 [10.628s] – POST /auction/auction.jsf HTTP/1.1 [11.595s] – POST /auction/auction.jsf HTTP/1.1 And the traffic. The two blocking requests arrive only 10ms apart. This is similar to what Deryk has seen. [13.588s] HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: JSF/2.0 Cache-Control: no-cache Cache-Control: no-store Cache-Control: must-revalidate Pragma: no-cache Expires: 0 Content-Type: text/xml;charset=UTF-8 Content-Length: 46 Date: Tue, 04 Oct 2011 16:22:42 GMT <notified-pushids>vd8pt42</notified-pushids> [13.598s] HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: JSF/2.0 Cache-Control: no-cache Cache-Control: no-store Cache-Control: must-revalidate Pragma: no-cache Expires: 0 Content-Type: text/xml;charset=UTF-8 Content-Length: 46 Date: Tue, 04 Oct 2011 16:22:42 GMT <notified-pushids>vd8pt42</notified-pushids> [13.673s] [13.645s] HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: JSF/2.0 Cache-Control: no-cache Content-Type: text/xml;charset=UTF-8 Content-Length: 541 Date: Tue, 04 Oct 2011 16:22:43 GMT <?xml version='1.0' encoding='UTF-8'?> <partial-response><changes><update id="rpt1:0:otime">< Unable to render embedded object: File (0:otime">7d 1:58:19</span>]]></update><update id="rpt1:1:otime"><) not found. [CDATA [<span id="rpt1:1:otime">3d 4:58:10</span>] ]></update><update id="rpt1:2:otime">< Unable to render embedded object: File (2:otime">2d 7:59:00</span>]]></update><update id="rpt1:3:otime"><) not found. [CDATA [<span id="rpt1:3:otime">7:58:15</span>] ]></update><update id="javax.faces.ViewState"><![CDATA [-1441829653106995469:-1044112092089002795] ]></update></changes></partial-response> HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: JSF/2.0 Cache-Control: no-cache Content-Type: text/xml;charset=UTF-8 Content-Length: 192 Date: Tue, 04 Oct 2011 16:22:43 GMT <?xml version='1.0' encoding='UTF-8'?> <partial-response><changes><update id="javax.faces.ViewState"><![CDATA [-1441829653106995469:-1044112092089002795] ]></update></changes></partial-response>
          Hide
          Deryk Sinotte added a comment -

          Assigning to Mircea as it looks to be Push related.

          Show
          Deryk Sinotte added a comment - Assigning to Mircea as it looks to be Push related.
          Deryk Sinotte made changes -
          Field Original Value New Value
          Assignee Mircea Toma [ mircea.toma ]
          Deryk Sinotte made changes -
          Salesforce Case []
          Fix Version/s 2.1 [ 10241 ]
          Assignee Priority P1
          Hide
          Deryk Sinotte added a comment -

          Additional info:

          This behaviour occurs with both Mojarra and MyFaces so seems to be related to something in Push. The second update the comes back with just a ViewState appears to occur in the DOMPartialViewContext.processPartial method. There is a guard against a null set of diffs:

          } else if (null != diffs)  {

          but in the case of the second push request, the list of diffs not null but empty. In that instance, we simply write out the ViewState as the only update. However, the unusual behaviour of the push connection unblocking so quickly after the initial update seems to point to something push related. If it is Push related, we should consider re-categorizing this JIRA.

          In addition to creating excess traffic, this also appears to impact MyFaces because each request has a different ViewState (unlike Mojarra). When the ViewState is changed so quickly, it appears to cause an issue with client interactions on the page. You can see this by changing the clock interval from very tight (1 sec or less) to very long (60 secs). When the clock interval is quite long, the Auction example behaves quite well running under MyFaces.

          Show
          Deryk Sinotte added a comment - Additional info: This behaviour occurs with both Mojarra and MyFaces so seems to be related to something in Push. The second update the comes back with just a ViewState appears to occur in the DOMPartialViewContext.processPartial method. There is a guard against a null set of diffs: } else if (null != diffs)  { but in the case of the second push request, the list of diffs not null but empty. In that instance, we simply write out the ViewState as the only update. However, the unusual behaviour of the push connection unblocking so quickly after the initial update seems to point to something push related. If it is Push related, we should consider re-categorizing this JIRA. In addition to creating excess traffic, this also appears to impact MyFaces because each request has a different ViewState (unlike Mojarra). When the ViewState is changed so quickly, it appears to cause an issue with client interactions on the page. You can see this by changing the clock interval from very tight (1 sec or less) to very long (60 secs). When the clock interval is quite long, the Auction example behaves quite well running under MyFaces.
          Deryk Sinotte made changes -
          Salesforce Case []
          Hide
          Deryk Sinotte added a comment -

          Linking to ICE-7118. I believe the issue with Push is causing the problems we are seeing with MyFaces when running the Auction examples.

          Show
          Deryk Sinotte added a comment - Linking to ICE-7118 . I believe the issue with Push is causing the problems we are seeing with MyFaces when running the Auction examples.
          Deryk Sinotte made changes -
          Link This issue blocks ICE-7118 [ ICE-7118 ]
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #25899 Tue Oct 11 13:21:37 MDT 2011 mircea.toma ICE-7242 Moved the notification of inbound observers (with the ids used by the browser) to the place where the server responses back with the outbound notifications. This way the pending notifications are confirmed to be satisfied before a new blocking request has time to arrive to the server.
          Files Changed
          Commit graph MODIFY /icepush/trunk/icepush/core/src/main/java/org/icepush/LocalPushGroupManager.java
          Commit graph MODIFY /icepush/trunk/icepush/core/src/main/java/org/icepush/BlockingConnectionServer.java
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #25900 Tue Oct 11 13:29:58 MDT 2011 mircea.toma ICE-7242 Update ICEpush library.
          Files Changed
          Commit graph MODIFY /icefaces2/trunk/icefaces/lib/icepush.jar
          Hide
          Mircea Toma added a comment -

          This issue was introduced when ICE-6709 was supposedly fixed. It seems there is timing related problem with the clearing of the pending notifications.

          Show
          Mircea Toma added a comment - This issue was introduced when ICE-6709 was supposedly fixed. It seems there is timing related problem with the clearing of the pending notifications.
          Hide
          Mircea Toma added a comment -

          Moved the notification of inbound observers (with the ids used by the browser) to the place where the server responses back with the outbound notifications (the notified pushIDs). This way the pending notifications are confirmed to be satisfied before a new blocking request has time to arrive to the server.

          Show
          Mircea Toma added a comment - Moved the notification of inbound observers (with the ids used by the browser) to the place where the server responses back with the outbound notifications (the notified pushIDs). This way the pending notifications are confirmed to be satisfied before a new blocking request has time to arrive to the server.
          Mircea Toma made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Ted Goddard added a comment -

          This change has caused a regression in Cloud Push notification – Cloud Push is now delivered even when the client is in the foreground.

          Show
          Ted Goddard added a comment - This change has caused a regression in Cloud Push notification – Cloud Push is now delivered even when the client is in the foreground.
          Hide
          Ken Fyten added a comment -

          Re-opened to find common solution that will work for both MyFaces and Could Push (post Beta2).

          Show
          Ken Fyten added a comment - Re-opened to find common solution that will work for both MyFaces and Could Push (post Beta2).
          Ken Fyten made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Assignee Priority P1 P2
          Ken Fyten made changes -
          Salesforce Case []
          Fix Version/s 2.1-Beta2 [ 10294 ]
          Ken Fyten made changes -
          Salesforce Case []
          Fix Version/s 2.1-Beta2 [ 10294 ]
          Ken Fyten made changes -
          Salesforce Case []
          Fix Version/s 2.1-Beta2 [ 10294 ]
          Ken Fyten made changes -
          Salesforce Case []
          Fix Version/s 2.1 [ 10241 ]
          Ken Fyten made changes -
          Salesforce Case []
          Fix Version/s 2.1 [ 10241 ]
          Hide
          Ken Fyten added a comment -

          Resolving this as ICEfaces aspect is now working.

          Created a follow-up JIRA: PUSH-149 for the Cloud push issue.

          Show
          Ken Fyten added a comment - Resolving this as ICEfaces aspect is now working. Created a follow-up JIRA: PUSH-149 for the Cloud push issue.
          Ken Fyten made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Mircea Toma
              Reporter:
              Greg Dick
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: