Nope... no front end proxy. No cleanup handlers. We just call untie %session; to commit it. Apache::Session DESTROY methods save the session. We do all that after mason has handled the request and, obviously, right before returning the status code.
We never explicitly reference the underlying object for anything, so I can't imagine that there'd be a reference lingering around. Now that I look though, I see that there's no explicit close on the socket or sockets Cache::Memcached may have open. So once the Apache::Session object is destroyed, the socket inside will just go out of scope. Maybe that's the problem... I can hack in a quick DESTROY in there and test it out. Rob On Wed, Mar 19, 2008 at 5:52 PM, Perrin Harkins <[EMAIL PROTECTED]> wrote: > On Wed, Mar 19, 2008 at 5:42 PM, Robert Landrum <[EMAIL PROTECTED]> > wrote: > > Finally, at 13:20, the session was read again, and what we got was that > > original session that we wrote way back at 12:42:28. Sometime between > > 12:43:21 and 13:20:06, the session we originally wrote got committed to > > memcached. In the mean time however, the writing process (21133) wrote > to, > > and read from memcached (I have an expanded log), so I know it wasn't > hung. > > > > I cannot figure out how that could have happened. > > It could mean that the original write was waiting for the lingering > close on a TCP connection before finishing and writing the session. > Do you have a frontend proxy? Do you do anything in a cleanup > handler? Do you explicitly force the session to write, or just let it > go out of scope? > > - Perrin >
