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.
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"}]
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?
--
View this message in context: http://www.nabble.com/%28Cometd-issue-with-encoded-json%29Re%3A--Jean-Francois-Arcand%27s-Blog--New-Comment-Posted-to-%27Updating-Grizzly-version-in-GlassFish-v3%27-tp23618372p23632304.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.