[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.



On Thu, Dec 09, 2010 at 09:09:21AM +0100, Pierangelo Masarati wrote:
> I think the best (blind) fix consists in only performing that test
> if sl_mincsn is assigned a value; something like
> 
>             /* Are there any log entries, and is the consumer state
>              * present in the session log?
>              */
> -           if ( sl->sl_num > 0 && ber_bvcmp( &mincsn,
> &sl->sl_mincsn ) >= 0 ) {
> +           if ( !BER_BVISEMPTY( &sl->sl_mincsn ) &&
> +               sl->sl_num > 0 &&
> +               ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 )
> +           {
>                 do_present = 0;
>                 /* mutex is unlocked in playlog */
>                 syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids );
> 
> However I'd like to hear some other opinion.

This fix would have the effect of treating the sessionlog
as empty until it overflows, and will cause unnecessary
refresh traffic.

Other than the patch I suggested (using the list head's
CSN value directly), I can think of two other approaches:

	1) When adding an entry to the sessionlog, check
	if sl_mincsn is empty. If it is, update sl_mincsn
	to the new entry's CSN.

	2) When initializing the sessionlog, set sl_mincsn
	to the maximum contextCSN value of the underlying
	database.

#2 seems ideal from an efficiency standpoint, although it
differs from the algorithm the current code appears to be
intended to implement.

-- 
Chris Mikkelson  | Vampireware; n, a project capable of sucking the 
cmikk@qwest.net  | lifeblood out of anyone unfortunate enough to be
		 | assigned to it which never actually sees the light
                 | of day, but nonetheless refuses to die. (tlode@nyx.net)