Uploaded image for project: 'Jira Cloud'
  1. Jira Cloud
  2. JRACLOUD-71874

Report 503 instead of 500 in case of "FATAL: too many connections for role"

    XMLWordPrintable

Details

    Description

      UPDATE 2019-02-13

      Hi everyone,

      In Jira Cloud we use rate limiting for REST API to protect our customers' sites (aka tenants) resources. Current implementation isn’t based on REST API consumer, it is based on concurrent requests made across all consumers of single tenant - consider tenant users, your App and other Apps accessing the infrastructure. Thus it is a challenge to provide meaningful, guaranteed information for consumer in response headers (e.g. Retry-After), such information could be seen only as a suggestion.

      In case of implementing retries please be advised of using back-off mechanism to lower retry frequency on subsequent failed attempts and increase traffic gradually on a success. Concurrency based limiting is more visible for longer requests so the rule of thumb would be the longer request is the lower concurrency should be used.

      We are actively working on per consumer rate limiting which should help us provide meaningful information in response headers. We expect it to be delivered in couple of quarters.

      With regard to this issue we’ll fix it by not returning 500 and provide suggestion (as described above) when retry may happen.

      Summary

      Calling search or other REST API endpoints might return status code 500 instead of status code 429 when the error FATAL: too many connections for role... is logged.

      Sometimes other random status codes like 503, 400 or 403 are returned for the same root-cause.

      Steps to Reproduce

      1. Send REST APIs calls (in example the Search endpoint was used) in continuous succession

      Expected Results

      If the rate limit is hit, the status 429. Throttling limit state should be returned in headers like here

      Actual Results

      Different status codes including 500, 503, 400 and 403 are returned instead.

      Attachments

        Issue Links

          Activity

            People

              nmeessen Nicolas Meessen
              a21d157266aa Bartłomiej Jańczak [SoftwarePlant]
              Votes:
              18 Vote for this issue
              Watchers:
              30 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: