You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openwhisk.apache.org by GitBox <gi...@apache.org> on 2019/11/15 21:06:52 UTC

[GitHub] [openwhisk] tysonnorris opened a new issue #4727: Config option to return 504 on blocking activation timeout

tysonnorris opened a new issue #4727: Config option to return 504 on blocking activation timeout
URL: https://github.com/apache/openwhisk/issues/4727
 
 
   Since beginning to use OpenWhisk, we regularly have questions regarding blocking activations and the 60s (now configurable) timeout, where the activation submitted as "blocking" turns into "nonblocking".
   
   I think it would be generally useful to allow the system to treat this as an error, as opposed to returning a 202 with the activation still in progress. 
   Basic reasons are:
   * Customers are confused by not having a consistent response related to the action config - e.g. setting a timeout greater than 60s (or whatever the configured blocking timeout is) would typically imply an error if duration exceeds 60s, but currently it results in 202, with activation completing "sometime later". 
   * We don't have any customers that actually leverage this ability, because building a client that handles 200+response as well as 202+polling is complicated.
   
   What I suggest is:
   * add a config option like `downgrade-blocking-activation=true`
     * if true, keep existing behavior
     * if false, return a 502 when `max-wait-for-blocking-activation` is exceeded, same as exceeding the action-configured timeout
   * in the case of blocking timeout, indicate the action exceeded the blocking timeout, as opposed to the action timeout, e.g. `The action exceeded the blocking activation time limit of 60000 milliseconds.`
   * due to no coordination between activation handling at controller and invoker: when timeout is past for a blocking activation, don't schedule the activation at all (since no one will ever look for the result).
   * in case of "not scheduling the activation", it *might* be useful to let users know whether the timeout occured before processing the action, or during (e.g. was wait time too high, or init time/duration?). To do this, we can proceed with creating the activation at the invoker with a timeout error indicating "wait time too high" or "execution too long". I'm not sure creating these failure activation records is actually that useful so it might should be a separate config as well, like `create-blocking-timeout-activations`
   
   
   
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services