grizzly
  1. grizzly
  2. GRIZZLY-1121

Better timeout handling for long-running uploads/downloads

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.x.NEXT
    • Component/s: None
    • Labels:
      None

      Description

      As suggested in http://java.net/jira/browse/GLASSFISH-17539 , this suggestion is made into a separate issue for Grizzly. See that issue and also http://forums.java.net/node/855551?force=732 for background.

      The existing timeout mechanisms appears not to be well-suited for uploads or downloads (of e.g. large files). Such requests can take a very long time, especially if the network connection is slow (think "mobile"). I'm talking about gigabytes and several hours.

      Having Glassfish time out unnecessarily in the middle of an upload is really bad, and should be prevented.

      Therefore, I suggest that, as long as there's reasonable traffic (x bytes / s, perhaps configurable), the usual request timeout settings should not apply. And perhaps there should be a new timeout setting, or size limit, or both, for long/big uploads (and downloads, hmm, diffrerent values for GET and POST requests?)

      If you prefer a more specific suggestion:
      + Different values for POST and GET
      + Max number of bytes (default 10 GB), zero means "no limit"
      + Min speed (in B/s) during the last 60 seconds (sliding window)

      • NOTE! This does not CAUSE a timeout, it STARTS a timeout timer,
        which is reset if the speed comes back at any time
        + Max "idle" time (as defined above) (default 15 min), zero means "infinity"
        + Max overall time for an active request (meaning: above 'min speed') default 10 hours.

      Btw, the current magic value -1 (meaning 'none') of the current request timeout settings should perhaps be 0 (with the same meaning). I at least find that more intuitive. In any case, the new suggested timeouts should have the same magic values for 'none'.

      Hope this is useful.

        Activity

        Hide
        emailnbw added a comment -

        I think this is a great feature request. I've taken issue with the terminology used in the various connection pool settings as well. Many of them include the use of the word IDLE, for example: idle-thread-timeout-seconds. This to me implies that the thread or connection is IDLE; no traffic is going across it. However, in fact it just means that the connection has been handed out from the pool and the idle clock starts ticking. So if you have a long running upload and there are actual packets being sent over the connection and the timeout value is reached the active connection will be interrupted and closed.

        Show
        emailnbw added a comment - I think this is a great feature request. I've taken issue with the terminology used in the various connection pool settings as well. Many of them include the use of the word IDLE, for example: idle-thread-timeout-seconds. This to me implies that the thread or connection is IDLE; no traffic is going across it. However, in fact it just means that the connection has been handed out from the pool and the idle clock starts ticking. So if you have a long running upload and there are actual packets being sent over the connection and the timeout value is reached the active connection will be interrupted and closed.
        Hide
        oleksiys added a comment -

        @emailnbw which Grizzly version you're referring to?

        Thank you.

        Show
        oleksiys added a comment - @emailnbw which Grizzly version you're referring to? Thank you.

          People

          • Assignee:
            Unassigned
            Reporter:
            tmpsa
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: