openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <>
Subject Concurrency PR
Date Fri, 17 Aug 2018 17:04:06 GMT
Hi -
I have been noodling with a few tests and the akka http client and gotten the concurrency
PR [1] to a good place, I think, so if anyone can help review that would be appreciated.

A couple of notes:
- akka http client has some different notion of connection reuse than the apache client, to
address this I created a separate PR [2] which, instead of dissuading connection reuse, simple
destroys the client (and connection pool) when the container is paused. (This change is not
reflected in 2795 FWIW). AFAIK the connection reuse issue only comes up with container pauses,
so I wanted to address this where it is relevant, and not impose additional performance costs
for concurrency cases. This client is still not enabled by default.
- There was mention in the comments (for 2795) about need to handle a case where a container
doesn’t support concurrency, but the action dev has enabled it at the action - this PR does
NOT deal with that.

To summarize, enabling concurrency requires:
- all actions may signal that they support concurrency, so all images that might be used would
need to support concurrency, if concurrency is enabled in your deployment
- log collection must be handled outside of invoker (since invoker does not deal with interleaved
log parsing)
- wsk cli will require changes to allow action devs to set the concurrency limits on actions
(current PR only exposes the OW api for doing this); I have a PR queued up for that [3]. (Will
need another PR for the cli once the client-go lib is updated)

To better handle the case of images that don’t support concurrency, or don’t support log
collection from invoker, I would suggest we change the container protocol to allow containers
to broadcast their support either via the /init endpoint, or via a new /info endpoint. This
of course would not give feedback until an action is executed (as opposed to when action is
created), but I think this is ok. I will work on a separate PR for this, but want to mention
some thoughts here about possible approaches to address these known concerns.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message