ICEpush
  1. ICEpush
  2. PUSH-308

Regression ICE-8858 - icepush kills server

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.3.0.GA_P01, 4.0.BETA
    • Fix Version/s: EE-3.3.0.GA_P02, 4.0
    • Component/s: Push Server
    • Labels:
      None
    • Environment:
      icefaces 4 from trunk
    • Assignee Priority:
      P2

      Description

      Take example ice-session-test.zip from ICE-8858. Compile with current libraries and run on Tomcat 7.0.52.
      Everything is ok until server restart. After restart client app start "flood atack" on server - hundreds requests per second to
      http://localhost:8080/ice-session-test/javax.faces.resource/listen.icepush.xml.jsf can be seen.

      "attack" stops with full reloading of page in browser

        Activity

        Hide
        Krashan Brahmanjara added a comment - - edited

        Test2
        Another side of the same bug. If you change javax.faces.PROJECT_STAGE to Production framework generate requests to invalid page http://localhost:8280/ice-session-test/listen.icepush (404)
        As a result users see thousands javascript errors and browser is killed in few minutes.

        Test 3
        I switched back push version to icepush-3.3.x-maintenance and ice-session-test work stable without above errors
        but I got also old complex app (1.8>3.3 in compatibility mode) and in this application client side redirect on session timeout do not work
        and browser and serwer is killed (request flood) soon after serwer restart.
        So finally ice-session-test should be extended with more facelets, ace and ice controls with basic spring configuration (for libraries). At this moment this stack seems to be very unstable.

        Show
        Krashan Brahmanjara added a comment - - edited Test2 Another side of the same bug. If you change javax.faces.PROJECT_STAGE to Production framework generate requests to invalid page http://localhost:8280/ice-session-test/listen.icepush (404) As a result users see thousands javascript errors and browser is killed in few minutes. Test 3 I switched back push version to icepush-3.3.x-maintenance and ice-session-test work stable without above errors but I got also old complex app (1.8>3.3 in compatibility mode) and in this application client side redirect on session timeout do not work and browser and serwer is killed (request flood) soon after serwer restart. So finally ice-session-test should be extended with more facelets, ace and ice controls with basic spring configuration (for libraries). At this moment this stack seems to be very unstable.
        Hide
        Krashan Brahmanjara added a comment - - edited

        Still the same. Restart of server results thousands error and request in browser.
        A little investigation shows that first xml response after session invalidate is correct and contains login or expiry page but this content is not displayed in browser (Firefox 24). I suppose that server should return redirect response.
        The same was in old compat apllication on icefaces 3.3 (release 2013.03).

        Another inconsistencies

        • org.icepush.browserTimeout parameter, what is this? Should we set this value to session-timeout*60000 ?
        • org.icefaces.strictSessionTimeout, setting to true hangs browser instead redirect to session timeout page.
          With setting to false application completely ignore session-timeout and never expires.
        Show
        Krashan Brahmanjara added a comment - - edited Still the same. Restart of server results thousands error and request in browser. A little investigation shows that first xml response after session invalidate is correct and contains login or expiry page but this content is not displayed in browser (Firefox 24). I suppose that server should return redirect response. The same was in old compat apllication on icefaces 3.3 (release 2013.03). Another inconsistencies org.icepush.browserTimeout parameter, what is this? Should we set this value to session-timeout*60000 ? org.icefaces.strictSessionTimeout, setting to true hangs browser instead redirect to session timeout page. With setting to false application completely ignore session-timeout and never expires.
        Hide
        Krashan Brahmanjara added a comment -

        Forum http://www.icesoft.org/JForum/posts/list/30/18345.page#78809
        Last forum comment confirm this request,

        Show
        Krashan Brahmanjara added a comment - Forum http://www.icesoft.org/JForum/posts/list/30/18345.page#78809 Last forum comment confirm this request,
        Hide
        Mircea Toma added a comment - - edited

        The infinite loop the bridge goes into occurs when the server is killed and it does not get a chance to tell the bridge to shutdown. After the server is restarted the bridge will resume the blocking connection but on the server side ICEfaces has not set up the resources corresponding to the ICEpush connections because no session was yet created (by a page load). The response to the blocking connection is then just the content of the dummy resource at listen.icepush.xml served by JSF, but since the connection is not blocked (pending) the client goes into a loop requesting the resource over and over again.

        Show
        Mircea Toma added a comment - - edited The infinite loop the bridge goes into occurs when the server is killed and it does not get a chance to tell the bridge to shutdown. After the server is restarted the bridge will resume the blocking connection but on the server side ICEfaces has not set up the resources corresponding to the ICEpush connections because no session was yet created (by a page load). The response to the blocking connection is then just the content of the dummy resource at listen.icepush.xml served by JSF, but since the connection is not blocked (pending) the client goes into a loop requesting the resource over and over again.
        Hide
        Mircea Toma added a comment -

        Modified to bridge to shutdown when the response to blocking request is not the one expected. Also fixed connection retry mechanism to properly stop when bridge is shutdown.

        Show
        Mircea Toma added a comment - Modified to bridge to shutdown when the response to blocking request is not the one expected. Also fixed connection retry mechanism to properly stop when bridge is shutdown.

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Krashan Brahmanjara
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: