Significant problem with current expiration code - fix included

[Brad Fitzpatrick]

Hm, but realtime() should be a no-op on a unixtime value.  And since it
converts a relative time TO an absolute unixtime value, this should be no
harm:

   abs_time = realtime(realtime(realtime(realtime(5))))

The first one takes 5 to the unixtime, then the rest do nothing.

At least this is always how it was in 1.1.x, which I just verified.  It
seems the facebook changes made the behavior of realtime() change.  Off to
read svn logs to figure out why....


On Fri, 1 Sep 2006, Neulinger, Nathan wrote:

> I started diagnosing a weird issue with current facebook branch, and
> tracked down the expiration appeared to not be working in a predictable
> manner.
>
> Turns out that realtime(expire) is being called twice. This results in
> the following behavior:
>
> At Start+100 seconds, an expiration time of 15 seconds:
> 	100 + 15 = 115, 100 + 115 = 215
>
> At Start+1000 seconds, ...
> 	1000 + 15 = 1015, 1000 + 1015 = 2015...
>
> So basically, unless the value is set almost immediately after memcached
> startup, it's expiration time will be huge compared to what was actually
> requested.
>
> This should fix it... Looks like overlapping changes in 287 combined
> with 288 broke it.
>
> Index: memcached.c
> ===================================================================
> --- memcached.c (revision 318)
> +++ memcached.c (working copy)
> @@ -814,7 +814,7 @@
>          }
>
>          expire = realtime(expire);
> -        it = item_alloc(key, flags, realtime(expire), len+2);
> +        it = item_alloc(key, flags, expire, len+2);
>
>          if (it == 0) {
>              if (! item_size_ok(key, flags, len + 2))
>
>
>
>
>
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nneul at umr.edu
> University of Missouri - Rolla         Phone: (573) 341-6679
> UMR Information Technology             Fax: (573) 341-4216
>
>