Wicket
  1. Wicket
  2. WICKET-4724

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

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major 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
        Emond Papegaaij added a comment -

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

        Show
        Emond Papegaaij added a comment - With WICKET-4946 and a recent version of Atmosphere this issue is fixed.
        Hide
        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
        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
        Martin Grigorov added a comment -

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

        Show
        Martin Grigorov added a comment - The value could be set to -1 and this will disable the max.
        Hide
        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
        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:
            Emond Papegaaij
            Reporter:
            Sean Lin
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development