glassfish
  1. glassfish
  2. GLASSFISH-5259

Using HTTPMonitor appears to cause conflict when the application is configured to use Grizzly's comet support

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 9.1peur2
    • Fix Version/s: 9.1.1_dev
    • Component/s: web_container
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      5,259

      Description

      We've been attempting to create Update Center modules to showcase ICEfaces
      applications using Grizzly's Comet support and encountered a problem during
      testing. The full backround can be found here:

      http://jira.icefaces.org/browse/ICE-2534

      The heart of the issue appears to be that if you use NetBeans to launch
      Glassfish and HTTPMonitor is enabled, then Grizzly Comet-enabled applications do
      not work reliably. In order to eliminate ICEfaces as a variable, I tried
      running a non-ICEfaces sample application that was configured to use Grizzly. I
      chose the Grizzly

      http://download.java.net/maven/2/com/sun/grizzly/samples/grizzly-comet-counter/1.7.3.3/

      The only thing I did to run this on Glassfish V2 was to change the imports from
      the new packages to the old packages. This was before I found the compatibility
      library :-o. The problem may manifest on Glassfish v3 as well but I never tried
      it. So the high-level steps to create this are:

      1) Get the sample to run on Glassfish V2 with Grizzly Comet configured.

      2) Launch Glassfish from NetBeans with HTTPMonitor enabled.

      You can click on the counter for some variable number of times but eventually it
      will stop responding. When I run the Counter application without HTTPMonitor, I
      can click the increment link as fast as possible for as long as I want and see
      the updates in two different browsers. When I add HTTPMonitor back into the mix,
      the counter eventually becomes unresponsive and stuck. If I open up a second
      browser, I can see that clicks go through because the counter on the second
      browser has the correct number of clicks (i.e. the first browser only shows '25'
      but the second browser opens up and starts on '60'). However the second browser
      will eventually get stuck as well. Doing all the same steps without HTTPMonitor
      seems to work fine.

        Activity

        Hide
        jfarcand added a comment -

        Re-assign to Alexey.

        Show
        jfarcand added a comment - Re-assign to Alexey.
        Hide
        jfarcand added a comment -

        Now re-assign

        Show
        jfarcand added a comment - Now re-assign
        Hide
        jfarcand added a comment -

        ping pong.

        Show
        jfarcand added a comment - ping pong.
        Hide
        jfarcand added a comment -

        B55 should have the fix. Can someone try it?

        Show
        jfarcand added a comment - B55 should have the fix. Can someone try it?
        Hide
        jfarcand added a comment -

        Possible fix.

        Show
        jfarcand added a comment - Possible fix.
        Hide
        jfarcand added a comment -

        Closing as fixed. I've tested with several applications and were no longer able
        to reproduce the problem. The jmaki-comet and the comet-counter works without
        any issue with the http-monitor enabled.

        Show
        jfarcand added a comment - Closing as fixed. I've tested with several applications and were no longer able to reproduce the problem. The jmaki-comet and the comet-counter works without any issue with the http-monitor enabled.

          People

          • Assignee:
            jfarcand
            Reporter:
            dmsinotte
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: