Re: subscribe stuck behind a long poll?

1 view
Skip to first unread message

Greg Thomas

unread,
Nov 21, 2009, 9:11:20 AM11/21/09
to cometd-users
> Essentially, there is a 10 second delay between the initial handshake
> and the client sending the initial subscribe message.

OK, I've found the cause of this. It /is/ an issue with the server I'm
using; the client isn't in state "CONNECTED" until the first connect
response is received, and that takes 10s to come back from the server.
The server should probably return the first long poll after a
handshake immediately, to cut that delay out.

Greg

Greg

unread,
Nov 20, 2009, 3:15:15 PM11/20/09
to cometd-users
Hi,

I'm using RC0 of the Cometd JavaScript Implementation with the jQuery
binding, and I'm seeing something I don't understand.

Essentially, there is a 10 second delay between the initial handshake
and the client sending the initial subscribe message. What appears to
happen is that ...

a) Client sends Handshake
b) Server responds immediately
c) Client starts a long poll
d) Client calls subscribe(), but it's not sent
(10 seconds passes)
e) Server ends the long poll with null
f) Client sends the subscribe()

Once I'm subscribed, any messages sent with a long poll open are sent
immediately; i.e. using both of the available connections to the
server - but why doesn't this happen with the subscribe? Is there
something special about /meta/ channels which mean that they wait
until there's no long poll open?

FWIW, I'm not using a cometd server, and am happy to accept that it
may be a server bug, but from what I can tell (see above), the issue
appears to be with the client - or more likely my use of it.

Is there anything obvious I'm missing?

Thanks,

Greg

Simone Bordet

unread,
Nov 23, 2009, 3:56:35 AM11/23/09
to cometd...@googlegroups.com
Hi,
Yes, and also because the server can decide that the long poll for
that client should have an interval, or it can tell the client to
normal-poll because the server has already seen it, etc.
The first long poll returning immediately carries useful information
from the server to the client.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
Reply all
Reply to author
Forward
0 new messages