sync_server "memory leak" with giant new mailbox first sync

[Bron Gondwana]

On Tue, 12 Sep 2006 13:21:01 +0100 (BST), "David Carter" <dpc22 at cam.ac.uk> said:
> On Sun, 10 Sep 2006, Wesley Craig wrote:
> 
> > My solution (such as it is) was to reduce the wasteful amount of space 
> > sync_server was allocating per message:
> > [...]
> > The times-5 is completely gratuitous.  In fact the pre-allocation of any 
> > memory for paths is wasteful, but I was not up for reengineering the memory 
> > scheme in sync_server at the time.
> 
> This started out life as:
> 
>    sprintf(tmp, "%lu.", l->count);
>    result->msg_path   = xmalloc(l->stage_dir_len+strlen(tmp)+2);
> 
> At around 35 bytes a shot, you get rather more of these to the MByte.
> 
> If I recall correctly, the "5 * (MAX_MAILBOX_PATH+1)" was put in to 
> support partitions. A lookup table for partitions and two integers (one 
> for the partition number, one of the message number on that partition) 
> should be all that is needed to reconstruct the paths at a later date.

"rather more" still feels a little dangerous to me.  sync_client is
basically shoving an unlimited number of messages down the wire at
sync_server without even once checking that sync_server is still a 
happy camper (other than the connection dropping out completely)

The only problem I see with cutting the UPLOAD after 'n' messages and
restarting it is that the folder on the replica will be in an
intermediate state with UIDNEXT set quite high but a bunch of messages
not there yet.  On the flip side, if it keeps failing then the folder
on the replica side contains no messages at all, which is somewhat
worse in a failure situation where you actually need to cut over to
the replica.

Bron.
-- 
  Bron Gondwana
  brong at fastmail.fm