Re: QRESYNC
Sorry for the late response. I also agree that (1) seems like the best option. Robert Mueller wrote: 1) Pro: * simple to calculate - only updated by cyr_expire "simple" seems good :) 1) Con: * Higher bandwidth use in the "stale client" case. If you're not syncing that often, then there's probably enough other stuff that needs downloading that it'll swamp the bandwidth anyway. 2) Con: * Extra bookkeeping - need to update a different record when removing an expired record. * Replication implications - cyr_expire and replication is already going to be tricky - but probably means arbitrary bumping of modseq on the previous record to guarantee it replicates. More spurious modseq bumps. These seem a bit scary to me. I'd lean towards (1). Simpler to implement, less side effects, less chance of odd edge case bugs or replication issues. Slightly more bandwidth if you don't sync regularly. Rob -- Kenneth Murchison Systems Programmer Carnegie Mellon University
Re: QRESYNC (was: Re: [POLL] Development guidance)
> Yeah - I think I've decided on (1) with a syslog every time it gets a > request that triggers a stale client sync - that way sites (like us!) > can see how much they're getting stale syncs, and can decide to either > extend their expiry time or agitate to have (2) implemented! I like it :) Rob
Re: QRESYNC (was: Re: [POLL] Development guidance)
On Tue, Apr 06, 2010 at 12:04:52PM +1000, Robert Mueller wrote: > > 1) Pro: > > * simple to calculate - only updated by cyr_expire > > "simple" seems good :) > > > 1) Con: > > * Higher bandwidth use in the "stale client" case. > > If you're not syncing that often, then there's probably enough other > stuff that needs downloading that it'll swamp the bandwidth anyway. > > > 2) Con: > >* Extra bookkeeping - need to update a different record when > > removing an expired record. > >* Replication implications - cyr_expire and replication is already > > going to be tricky - but probably means arbitrary bumping of > > modseq on the previous record to guarantee it replicates. More > > spurious modseq bumps. > > These seem a bit scary to me. > > I'd lean towards (1). Simpler to implement, less side effects, less > chance of odd edge case bugs or replication issues. Slightly more > bandwidth if you don't sync regularly. Yeah - I think I've decided on (1) with a syslog every time it gets a request that triggers a stale client sync - that way sites (like us!) can see how much they're getting stale syncs, and can decide to either extend their expiry time or agitate to have (2) implemented! Bron.
Re: QRESYNC (was: Re: [POLL] Development guidance)
> 1) Pro: > * simple to calculate - only updated by cyr_expire "simple" seems good :) > 1) Con: > * Higher bandwidth use in the "stale client" case. If you're not syncing that often, then there's probably enough other stuff that needs downloading that it'll swamp the bandwidth anyway. > 2) Con: >* Extra bookkeeping - need to update a different record when > removing an expired record. >* Replication implications - cyr_expire and replication is already > going to be tricky - but probably means arbitrary bumping of > modseq on the previous record to guarantee it replicates. More > spurious modseq bumps. These seem a bit scary to me. I'd lean towards (1). Simpler to implement, less side effects, less chance of odd edge case bugs or replication issues. Slightly more bandwidth if you don't sync regularly. Rob
