Thinking more about the singleton aspect, I guess this is mostly an issue for
blackbox containers, where manifest/managed containers will mitigate at least
some of the singleton failure delays by prewarm/stemcell containers.
So in the case of singleton failure, impacts would be:
- managed conta
A couple comments on singleton:
- use of cluster singleton will introduce a new single point of failure - from
time of singleton node failure, to single resurrection on a different instance,
will be an outage from the point of view of any ContainerRouter that does not
already have a warm+free co
Tyson Norris wrote on 08/15/2018 08:29:48 PM:
>
> FWIW This won’t help with concurrent activations since the logs from
> concurrent activations will be interleaved (I think Dave was not
> suggesting to use this for concurrent activations). It will only
> help in the case where log processing is
This was a pretty simple change, so to make things concrete I have PRs with
a prototype of the enabling change in the invoker [1] and a change to the
nodejs runtime to emit the start sentinels [2].
If we go ahead with this design, here's an example from an action that
writes one line to stdout an
Thanks, Markus!
On 15.08.18, 16:30, "Markus Thömmes" wrote:
Hi Michael,
loosing/adding a shard is essentially reconciled by the ContainerManager.
As it keeps track of all the ContainerRouters in the system, it can also
observe one going down/crashing or one coming up and jo
