JSONP Transport delays /meta/subscibe responses

After further investigation I found out, that jetty isn't the source of the problem, but firefox (haven' tried IE so far).
The /meta/subscribe is properly returned to the browser but is not executed as long as the /meta/reconnect connection is still open.

That means it is not a jetty bug but still a very tough one for the JSONP stuff in comet. Jetty could workaround by resuming the reconnect continuation with every client message to
make sure that the browser handles all return messages. Anyway I go and ask on the comet mailinglist for some advice.

I wrote some stuff on the comet-dev mailinglist about possible ways to tackle that problem. Jetty already has a alwaysresume parameter but it is only used if a message is delivered through the deliver method of the client and that only happens if the client receives a method via a channel. But there are a few ways to not receive a msg through a channel: -response to a publish, subscribe response, unsubscribe response.

Shouldn't that resume not be implemented in the continuationcometdservlet?
Or is it better to send more messages via the client? Going through the code I wonder why e.g. the response to a subscribe in the subscribe handler is not given to the deliver method of the client but directly to the transport. Is there a reason for that? Couldn't be any response to the client be handled via the clients deliver method (ok at least if the client exists. that's after the first connect, or?)? That would make things more consistent.

Markus,

It is a good question you raise.... and the answer is probably mostly yes.
Except that the complication is that the transport does want to know a bit about which messages
are bundled into which responses.
So if I was to start an implementation again from scratch today, I would probably consider that approach.

But I'm not starting from fresh and I think that making such a drastic change would introduce more instability
than it is worth a this stage.

The issue you have raised is real... but I think at this point, it is transport specific. Ie the transport must
send messages back to the client via the path that they know will get the message delivered according to
the spec. For json transport, that means responses appear not to be sent out of order, so a reconnect
must be woken up, even if all the messages that are available to be delivered could be delivered via
a response to a subscribe/publish/etc.

cheers

I just checked in the fix I had locally. I didn't couple the resume to the transport but to the alwaysResumePoll parameter which makes it configurable. If somebody uses a clientside hack there is no need for a jsonp coupled resume.

Can you please have a look? The only drawback with the resume is that the servlet processing is starting again (but I guess that's how continuations in jetty work) and that it can be called twice in case a message is delivered through a channel, one time by the client and one time by the servlet. Shouldn't be a problem as the resume method checks if a continuation is available. However it might be possible to remove the resume from the client and put it only into the servlet?

reopen this if you think it is not fixed.

cheers