/meta/connect always returns immediately from grizzly cometd servlet

[arinban]

This issue was previously discussed here:

http://www.nabble.com/(Cometd-issue-with-encoded-json)Re%3A--Jean-Francois-Arcand%27s-Blog--New-Comment-Posted-to-%27Updating-Grizzly-version-in-GlassFish-v3%27-td23618372.html#a23638795

I am running glassfish v3 promoted (downloaded from http://download.java.net/glassfish/v3/promoted/latest-glassfish-unix.sh today) and dojo 1.3.0 (pretty much the latest one). I have a simple test page which establishes a connection to a comet servlet. I have run it in glassfish, once against the mortbay servlet, and once against the grizzly one. The mortbay servlet acts 'properly', the grizzly one does not.

On running against the grizzly servlet, I get repeated /meta/connect messages issued by my browser. The mortbay servlet hangs on the second one, not returning a Response immediately. Grizzly cometd returns a Response immediately for every /meta/connect Post, so the browser ends up in a fairly tight loop, a Post every 20ms or so.

The only real difference I can see in what is transmitted in the two cases is that the mortbay servlet returns a 'timeout' value, but I don't see how this value, given back to the client, would affect the server.

Mortbay Servlet Post/Response example:

POST [

{"version":"1.0","minimumVersion":"0.9","channel":"/meta/handshake","id":"0","supportedConnectionTypes" :["long-polling","long-polling-json-encoded","callback-polling"]}

] RESPONSE 13ms [{"id":"0","minimumVersion":"0.9","supportedConnectionTypes":["long-polling","callback-polling"],"successful" :true,"advice":

{"reconnect":"retry","interval":0,"timeout":240000}

,"channel":"/meta/handshake","clientId" :"7fqbfavlrxkmhnhyj","version":"1.0"}]

POST [

{"channel":"/meta/connect","clientId":"7fqbfavlrxkmhnhyj","connectionType":"long-polling","id":"1"}

] RESPONSE 10ms [{"id":"1","successful":true,"advice":

{"reconnect":"retry","interval":0,"timeout":240000}

,"channel":" /meta/connect"}]

POST [

{"channel":"/meta/connect","connectionType":"long-polling","clientId":"7fqbfavlrxkmhnhyj","id":"2"}

] RESPONSE 4.01m ..Hangs for 4 minutes, then.. [

{"id":"2","successful":true,"channel":"/meta/connect"}

]

Grizzly Servlet Post/Response example:

POST [

{"version":"1.0","minimumVersion":"0.9","channel":"/meta/handshake","id":"0","supportedConnectionTypes" :["long-polling","long-polling-json-encoded","callback-polling"]}

] RESPONSE 4ms [{"channel":"/meta/handshake","version":"1.0","supportedConnectionTypes":["long-polling","callback-polling" ],"minimumVersion":"0.9","id":"0","clientId":"Uyx12a4bR5WwwNa3E4KO/w==","successful":true,"advice":

{"reconnect" :"retry","interval":0,"multiple-clients":false}

,"authSuccessful":true}]

POST [

{"channel":"/meta/connect","clientId":"Uyx12a4bR5WwwNa3E4KO/w==","connectionType":"long-polling","id" :"1"}

] RESPONSE 55ms [{"channel":"/meta/connect","clientId":"Uyx12a4bR5WwwNa3E4KO/w==","successful":true,"id":"1","advice" :

{"reconnect":"retry","interval":0,"multiple-clients":false}

,"timestamp":"Wed, 20 May 2009 15:54:45 GMT" }]

POST [

{"channel":"/meta/connect","connectionType":"long-polling","clientId":"Uyx12a4bR5WwwNa3E4KO/w==","id" :"2"}

] RESPONSE 50ms [{"channel":"/meta/connect","clientId":"Uyx12a4bR5WwwNa3E4KO/w==","successful":true,"id":"2","advice" :

{"reconnect":"retry","interval":0,"multiple-clients":false}

,"timestamp":"Wed, 20 May 2009 15:56:09 GMT" }]

.. the POST/RESPONSE sequence continues unabated here ..

The discrepancy in timestamps in the responses is because I had firebug broken in the debugger to capture these messages. The responses came back 50ms or so after the POSTs, as indicated on the 'RESPONSE' lines. Without the "debugger" statements, the firebug console flies past so fast with hundreds of /meta/connect messages, I cannot capture the content.

Environment

Operating System: Linux Platform: All

Affected Versions

[1.9.22]

[arinban]

• Issue Imported From: https://github.com/javaee/grizzly/issues/611
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To:@glassfishrobot
• Original Issue Closed By:@glassfishrobot

[arinban]

@glassfishrobot Commented Reported by neek@java.net

[arinban]

@glassfishrobot Commented neek@java.net said: Created an attachment (id=74) test html, replace /GlassfishTest with your context root

[arinban]

@glassfishrobot Commented jfarcand@java.net said: Re-assign to Shing Wai in case he have time

[arinban]

@glassfishrobot Commented neek@java.net said: Could I have some confirmation of this bug please? Can you reproduce it? Is cometd supposed to work in glassfish today?

I've got the grizzly-cometd source into eclipse and stepped through it, but I can't see how the /meta/connect call would ever pause. /meta/handshake assigns the dumyHandler as the client's handler, and /meta/connect looks like it's coded to fall through and return immediately when the handler is still the dumyHandler (i.e. no subscriptions have been made).

[arinban]

@glassfishrobot Commented jfarcand@java.net said: This is a bug with the version of DOJo you are suing. Our samples current works fine:

http://download.java.net/maven/2/com/sun/grizzly/samples/

I will try to take a look next week, but it is JavaOne and I might not get the time.

[arinban]

@glassfishrobot Commented neek@java.net said: Thanks for looking. It seems you guys are playing catchup with the dojo project (who are in charge of defining the cometd protocol, right?). I think I'm going to be better off using their servlet, or the mortbay one, rather than the grizzly one which has so far been unusable against any versions of dojo I have tried.

While I am looking at it, I wanted to mention the latest version of the dojo code. I was directed to this post by someone at #dojo today:

http://groups.google.com/group/cometd-dev/browse_thread/thread/fefb1346570f292c/6243f78ed49e0c99?#6243f78ed49e0c99

I fetched their latest code and tried it out. When their new code calls the grizzly servlet, I got two exceptions before I stopped trying. The handshake from their new code looks like this:

[{"version":"1.0","minimumVersion":"0.9","channel":"/meta/handshake","supportedConnectionTypes":

{"0" :"long-polling","1":"callback-polling"}

,"id":1}]

This first threw a ClassCastException on your line in VerbUtils.newHandshakeRequest:

handshakeReq.setId((String)map.get("id"));

Once I had hacked their code to send id as a string, the next line fell over:

java.lang.ClassCastException: java.util.HashMap cannot be cast to [Ljava.lang.Object; at com.sun.grizzly.cometd.bayeux.VerbUtils.getSupportedConnectionTypes(VerbUtils.java:416)

I'm not about to play further with supportedConnectionTypes and investigate why it is not an Object array as expected by VerbUtils.

Thanks again. If you continue to think this is a bug with the dojo code, feel free to close this ticket, but it seems to me more like the dojo people keep changing the protocol under your feet and this keeps introducing bugs into your code.

[arinban]

@glassfishrobot Commented jfarcand@java.net said: Bump version

[arinban]

@glassfishrobot Commented jfarcand@java.net said: Bump millestones

[arinban]

@glassfishrobot Commented jfarcand@java.net said: Bump version

[arinban]

@glassfishrobot Commented File: comettestcdn.html Attached By: neek@java.net

[arinban]

@glassfishrobot Commented This issue was imported from java.net JIRA GRIZZLY-611

[arinban]

@glassfishrobot Commented Marked as won't fix on Monday, April 8th 2013, 2:12:56 pm