[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Socket activation



On Wed, Sep 4, 2013 at 12:22 PM, Krishna Raman <kraman gmail com> wrote:
> Could make this a configuration/setup option. If the router/switch misbehaves with it gets SYN failures then use a haproxy,
> else live with 1 SYN failure per gear un-idle.
>
> What do you think?

I'm just wary of relying on failure-retry mechanisms for normal
operations. It takes network monitoring from "no SYN-ACK failures
should occur under normal conditions" to "there is some amount
expected, and expectations might even be exceeded under normal
conditions " Noise like that makes the ops job hard without getting
either false positives (on widespread activation) or false negatives
(on network failure). Even if you can tolerate it, it's not a fun
model to work with in practice.

It might be possible to map gear activations to SYN-ACK failures to
discover network failure, but network and daemon monitoring are rarely
integrated. If you're at a colo facility, they're not even managed by
the same parties.

Using haproxy to mask the SYN-ACK failure is interesting. But, unlike
the socat shim *behind* socket activation, the haproxy would have to
persistently run for every container/gear on the host. That would
really hurt density. What would you think of haproxy *behind* socket
activation as the shim? I don't think it supports it at the moment,
but it would not be hard to implement.

I'd also like to note that the dropped-SYN activation model won't work
for most UDP protocols. Some will retry. Some will just have data go
missing. If you're using statsd or GELF, that would be pretty
annoying.

-- 
David Strauss
   | david davidstrauss net
   | +1 512 577 5827 [mobile]


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]