That Cache::Memcache DESTROY method fix had no effect. Rob
On Wed, Mar 19, 2008 at 6:04 PM, Robert Landrum <[EMAIL PROTECTED]> wrote: > 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 > > > >
