Jetty
  1. Jetty
  2. JETTY-384

JSONP Transport delays /meta/subscibe responses

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.1.5
    • Component/s: Bayeux
    • Labels:
      None
    • Number of attachments :
      0

      Description

      The response to a /meta/subscribe message is delayed in case a /meta/reconnect response is currently pending.

      If no /meta/reconnect response is pending, the /meta/subscribe is returned immediately.
      The delay only happens with the JSONP transport but debugging through the code I can't see any reason for that delay.
      The transport.complete method is called at the end of the /meta/subscribe request and even an explicit _out.flush() is executed there.
      However the response is only returned at the same time the /reconnect times out.

      Same is true for for unsubscribe and I haven't tested publish yet.

        Activity

        Hide
        Markus Joschko added a comment -

        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.

        Show
        Markus Joschko added a comment - 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.
        Hide
        Markus Joschko added a comment -

        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.

        Show
        Markus Joschko added a comment - 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.
        Hide
        Greg Wilkins added a comment -

        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

        Show
        Greg Wilkins added a comment - 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
        Hide
        Markus Joschko added a comment -

        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?

        Show
        Markus Joschko added a comment - 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?
        Hide
        Greg Wilkins added a comment -

        reopen this if you think it is not fixed.

        cheers

        Show
        Greg Wilkins added a comment - reopen this if you think it is not fixed. cheers

          People

          • Assignee:
            Greg Wilkins
            Reporter:
            Markus Joschko
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: