sync_client stalls the rest of cyrus while 'no route to host'

[Bron Gondwana]

On Mon, Aug 28, 2006 at 02:19:31PM -0400, Wesley Craig wrote:
> On 26 Aug 2006, at 21:42, Bron Gondwana wrote:
> >Though it is dying less as we discover bugs and patch them.  See
> >my post last night (au time) about the "three MAILBOX -> USER
> >promotions and you're out" issue.
> >
> >That's the first thing that has killed sync_client in a while.
> 
> I have a (shrinking, yes) list of actions that will kill sync_client  
> reliably.  There are also some design flaws, e.g., expunged messages  
> are not replicated.

What else do you have that will kill it?  I'd be interested in
trying to recreate it.  We agree on the design-flaws front, and
I'm seriously consider (as I said in another post) rewriting to
be a bit more like mysql in the "multiple replicas possible"
design and keeping the sync logs around for double-checking
purposes.

> >We also are nearly at the point where we'll be running a weekly
> >check of replication pairs: message counts, flags, etc.  Make
> >sure everything is up to date.
> 
> Isn't this what make_md5 is for?

Well, yeah - probably.  We don't check contents except in a very
rare (one message per 1000 inside each one in a thousand users)
case, more interested for all the small details to line up since
the body of messages seems to be one of the more reliable things
to transfer.

No transferring expunged messages matters only from a backup
recovery point of view, and we already keep yet another backup[tm]
(I've actually written a tar engine in Perl, oh the horror.  Makes
it a lot eaiser to stream one .tar.gz to another .tar.gz making
decisions about which files get created in the new file on the
fly without the IO hit of making and deleting them all though).

Oh, and if real-time replication is running the "expunged" message
seems to get itself to the replica before actually getting deleted
most of the time.

Bron.