You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@usergrid.apache.org by "Jeffrey (JIRA)" <ji...@apache.org> on 2015/11/09 18:57:11 UTC

[jira] [Updated] (USERGRID-368) A connection timeout to the configured mail server causes POST requests to /management/organizations to block

     [ https://issues.apache.org/jira/browse/USERGRID-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeffrey  updated USERGRID-368:
------------------------------
    Sprint: Double Check

> A connection timeout to the configured mail server causes POST requests to /management/organizations to block
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: USERGRID-368
>                 URL: https://issues.apache.org/jira/browse/USERGRID-368
>             Project: Usergrid
>          Issue Type: Story
>            Reporter: ryan bridges
>            Priority: Minor
>
> A connection timeout to the configured mail server causes POST requests to /management/organizations to block. This can cause downstream load-balancers, proxies, and clients to also timeout even though the call eventually completes successfully.
> In the case of a load-balancer, this causes even more confusion. Consider the following scenario:
> - client makes a post request to the /management/organizations endpoint on the load-balancer
> - the load-balancer makes the request to Usergrid instance #1
> - Usergrid #1 successfully creates the org, app, and admin user, then attempts to contact the unavailable SMTP server
> - After 15s, the load-balancer cancels the initial request and makes and identical request to Usergrid #2
> - Usergrid #2 sees that the requested organization already exists and returns a 400 duplicate indexed property error to the load-balancer
> - the load-balancer returns the 400 error to the client
> The originating client application would only see the 400 error, even though the request completed successfully.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)