Mailing-List: contact dev-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Wed, 12 Mar 2014 12:20:46 +0000 (UTC)
From: "Vitaly Brodetskyi (JIRA)" <jira@apache.org>
To: dev@ambari.apache.org
Message-ID: <JIRA.12700943.1394626796723.50854.1394626846415@arcas>
In-Reply-To: <JIRA.12700943.1394626796723@arcas>
References: <JIRA.12700943.1394626796723@arcas>
Subject: [jira] [Created] (AMBARI-5047) API proxy returns "204 No Content"
 if the underlying call takes more than a few seconds
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Vitaly Brodetskyi created AMBARI-5047:
-----------------------------------------

             Summary: API proxy returns "204 No Content" if the underlying call takes more than a few seconds
                 Key: AMBARI-5047
                 URL: https://issues.apache.org/jira/browse/AMBARI-5047
             Project: Ambari
          Issue Type: Task
          Components: agent
    Affects Versions: 1.5.1
            Reporter: Vitaly Brodetskyi
            Assignee: Vitaly Brodetskyi
            Priority: Critical
             Fix For: 1.5.1


It looks like the API proxy behaves in an expected manner (returns HTTP code 204 with no response) when the underlying API call being proxied does not return in a timely manner.
It seems like this threshold is around 3 seconds.
When I was testing Falcon, I kept getting 204 from Ambari's API proxy, but the underlying API calls were successful when directly run against Falcon.
3 seconds is a bit aggressive.  Perhaps we can pass a parameter to change the timeout value in milliseconds, with a hard limit on 15 seconds or so?
Also, returning 204 is not ideal.  We should return {error: "400", message: "Connection timed out"} or something like that (I didn't check the actual format that we use... just an example), so that the API client can perform appropriate error handling.


--
This message was sent by Atlassian JIRA
(v6.2#6252)