Salut,
neekfenwick wrote:
> You seem to be on the money. The glassfish v3 prelude 'promoted' build I
> downloaded is different to the one available from the default download page,
> and contains glassfish/modules/grizzly-comet.jar, and serves
> non-comment-enclosed json. Huzzah.
It is not Prelude build :-) It is v3. Which version have you downloaded
from here:
http://download.java.net/glassfish/v3/promoted/
>
> My simple dojo app now runs into a tight loop, sending repeated
> /meta/connect messages. I have googled and not found an answer. I've run
> the mortbay servlet instead of the grizzly one, and do not get this loop.
> As far as I can tell, the mortbay one returns info relating to a timeout
> which the grizzly one isn't using, for some reason. I'm not sure if it's
> the servlet or the browser code that is supposed to implement the timeout
> (i.e. actually wait) but I suspect the servlet, so perhaps I've
> misconfigured your grizzly cometd servlet?
>
> My web.xml says:
>
> <servlet>
> <servlet-name>Grizzly Cometd Servlet</servlet-name>
>
> <servlet-class>com.sun.grizzly.cometd.servlet.CometdServlet</servlet-class>
> <init-param>
> <description>
> expirationDelay is the long delay before a request is
> resumed. -1 means never.
> </description>
> <param-name>expirationDelay</param-name>
> <param-value>24000000</param-value>
> </init-param>
> <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
> <servlet-name>Grizzly Cometd Servlet</servlet-name>
> <url-pattern>/cometd</url-pattern>
> </servlet-mapping>
>
> Comparing actual conversations using the mortbay servlet and the grizzly
> servlet:
>
> Using Mortbay servlet, handshake and connect request and response (note the
> timeout param in 'advice' in the response):
>
> [{"version":"1.0","minimumVersion":"0.9","channel":"/meta/handshake","id":"0","supportedConnectionTypes"
> :["long-polling","long-polling-json-encoded","callback-polling"]}]
> ->
> [{"id":"0","minimumVersion":"0.9","supportedConnectionTypes":["long-polling","callback-polling"],"successful"
> :true,"channel":"/meta/handshake","advice":{"reconnect":"retry","interval":0,"timeout":240000},"clientId"
> :"1t9vrrwhw3j0ryuh9","version":"1.0"}]
>
> [{"channel":"/meta/connect","clientId":"1t9vrrwhw3j0ryuh9","connectionType":"long-polling","id":"1"}
> ]
> ->
> [{"id":"1","successful":true,"advice":{"reconnect":"retry","interval":0,"timeout":240000},"channel":"
> /meta/connect"}]
> The handshake and connect conversation looks like this now:
>
> Grizzly servlet responses (note the lack of 'timeout' in response's advice):
>
> [{"channel":"/meta/handshake","version":"1.0","supportedConnectionTypes":["long-polling","callback-polling"],"minimumVersion":"0.9","id":"0","clientId":"2ej65rm6j34vgwmKtoFhvA==","successful":true,"advice":{"reconnect":"retry","interval":0,"multiple-clients":false},"authSuccessful":true}]
>
> [{"channel":"/meta/connect","clientId":"2ej65rm6j34vgwmKtoFhvA==","successful":true,"id":"1","advice":{"reconnect":"retry","interval":0,"multiple-clients":false},"timestamp":"Wed,
> 20 May 2009 09:36:11 GMT"}]
Looks like the Bayeux spec added this timeout value recently. Can you
file an issue here:
https://grizzly.dev.java.net/issues/
And attach a small test case?
>
> I have tried hacking the dojo source that returns your servlets json, to
> include a 'timeout' variable in the advice, but this does not help. It
> seems to me the servlet should wait, I just don't know how to make this
> happen.
>
> Before I end up diving into your implementation to figure this out, how can
> I impose the correct timeout on the grizzly servlet so my browser doesn't
> get into a tight loop?
I think this is simple for us to fix the issue by adding the missing
timeout value. If you can file an issue and attach a test case, I
promise a solution pretty fast :-)
A+
-- Jeanfrancois