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