[ale] reasonable socket life

[Sid Lane]

we do something similar to what you're describing (on a fairly good scale):

most of the content in our databases comes from XML quasi-continuously
streamed over persistent tcp sessions to parsing daemons that transform it
into DML (~25M DML/day) on the replication master(s).  we restart the
listeners daily more or less for the hell of it though they have
accidentally gone weeks w/o restarting w/o incident (someone forgot they
commented out cronned restart).

I don't think there's a "one size fits all" answer to this ? - it depends on
your volume, reliability of your network and fault tolerance of the code
(/drivers/libraries) used at both ends.  for us it's been insanely reliable
though I'll admit a few years ago I pulled the XML/SQL translation back from
the datacenter(s) to our office (i.e. only MySQL replication goes over WAN
now).  it wasn't that it was UNreliable before, just that MySQL replication
is actually even MORE network fault tolerant (at least in our case).

if I had it to do all over (& I didn't design the current XML
implimentation, just the DB replication) I would push the XML over
persistent (but easily resetable) HTTP sessions to a load balancer (VIP)
w/multiple active-active parallel ingestors behind it but our current
design, while far from perfect, has been way more than reliable enough to
justify "fixing" it...

On Wed, Mar 4, 2009 at 12:46 PM, Robert Reese~ <ale at sixit.com> wrote:

> > Quick poll/question.
> > Assume you have a daemon that talks to another daemon across a
> > network over a socket.  The communication is constant and unlike
> > http requests are always alive. These socket connections would be
> > across a multimile geographic area but within a corporate WAN.
> > How often would you expect a connection would need to be restarted
> > before you decide that the connection is unstable. hours,
> > weeks,months? Please don't say seconds.
>
> 1^(10^100) seconds.  Or until one side dies.  In theory, anyway.
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20090304/625e2660/attachment.html