Uploaded image for project: 'Wicket'
  1. Wicket
  2. WICKET-4724

the option name "maxRequests" is wrong in jquery.wicketatmosphere.js

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.0.0-beta3
    • Fix Version/s: 6.6.0
    • Component/s: wicket-atmosphere
    • Labels:
      None

      Description

      the option name should be "maxRequest" not "maxRequests"

        Activity

        Hide
        papegaaij Emond Papegaaij added a comment -

        With WICKET-4946 and a recent version of Atmosphere this issue is fixed.

        Show
        papegaaij Emond Papegaaij added a comment - With WICKET-4946 and a recent version of Atmosphere this issue is fixed.
        Hide
        mgrigorov Martin Grigorov added a comment -

        From Atmosphere mailing lists:

        > Hi folks,
        > I have just found that jquery plugin uses maxRequest 60 by default.
        > According to [1] maxRequest is 'The maximum number of requests that will be executed. Once the maximum gets reached, the connection will be closed.'
        > However it makes sense only for long-polling transport, because the connection is closed each time when client pushes/recieves the message. But i am not sure how it affects the streaming transport.
        > I can send as many messages as i want with streaming transport. I suppose only connection interrupt (or timeout and maxStreamingLength ?) between client and server may force reconnect, so the counter will be increased. So after some amount of time the jquery plugin may silently stop to work and you will not find the reason easily if you don't know about the default value of this parameter . So behavior of this parameter in streaming transport is not consistent with pooling transport.
        > Why max requests are limited by default? Does it make any sense?

        JF Arcand:
        Because of proxy that close connection (with all transports), we need to stop sending requests after some time ... if the server goes down or anything related, the browser will keep trying, so that's why I've added this property. Does it make sence?

        Show
        mgrigorov Martin Grigorov added a comment - From Atmosphere mailing lists: > Hi folks, > I have just found that jquery plugin uses maxRequest 60 by default. > According to [1] maxRequest is 'The maximum number of requests that will be executed. Once the maximum gets reached, the connection will be closed.' > However it makes sense only for long-polling transport, because the connection is closed each time when client pushes/recieves the message. But i am not sure how it affects the streaming transport. > I can send as many messages as i want with streaming transport. I suppose only connection interrupt (or timeout and maxStreamingLength ?) between client and server may force reconnect, so the counter will be increased. So after some amount of time the jquery plugin may silently stop to work and you will not find the reason easily if you don't know about the default value of this parameter . So behavior of this parameter in streaming transport is not consistent with pooling transport. > Why max requests are limited by default? Does it make any sense? JF Arcand: Because of proxy that close connection (with all transports), we need to stop sending requests after some time ... if the server goes down or anything related, the browser will keep trying, so that's why I've added this property. Does it make sence?
        Hide
        mgrigorov Martin Grigorov added a comment -

        The value could be set to -1 and this will disable the max.

        Show
        mgrigorov Martin Grigorov added a comment - The value could be set to -1 and this will disable the max.
        Hide
        papegaaij Emond Papegaaij added a comment -

        This is indeed wrong, however I'm wondering if this option is still needed. I added it because with long-polling, the browser stopped connecting after 60 cycles. Is this still the case? If so, I think this should be fixed in Atmosphere itself, because with long-polling you do not want the browser to stop connecting, not even after 100000 cycles. Atmosphere should differentiate between failed connections and normal disconnections.

        Show
        papegaaij Emond Papegaaij added a comment - This is indeed wrong, however I'm wondering if this option is still needed. I added it because with long-polling, the browser stopped connecting after 60 cycles. Is this still the case? If so, I think this should be fixed in Atmosphere itself, because with long-polling you do not want the browser to stop connecting, not even after 100000 cycles. Atmosphere should differentiate between failed connections and normal disconnections.

          People

          • Assignee:
            papegaaij Emond Papegaaij
            Reporter:
            linekin Sean Lin
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development