memcached losing connections

[Kevin Dalley]

I'm using the standard 5 servers, all on localhost, from 11221 to 11225,
though my most recent run just mentioned one server, localhost:11221.

To make the test somewhat succeed, I added a timeout.  Eventually, the
poll gives up, and then moves on, with one or more failures, but
officially passing the test.

Failed with return value of 5 on insert of .... (long string)

where 5 is MEMCACHED_WRITE_FAILURE

I modified the error message in execute_set a bit to include the return
value.


In my most recent run, this error message was repeated a few times.  If
I skip the timeout, the poll waits forever.

I tried to come up with another test case, but I'm stuck for now.


On Wed, 2008-01-23 at 09:50 -0800, Brian Aker wrote: 
> Hi!
> 
> On Jan 23, 2008, at 9:29 AM, Kevin Dalley wrote:
> 
> > Perhaps this is the close problem, but this is in the middle of
> > generate_data in tests/function.c.   The poll is waiting for a write.
> > I thought that these tests did not close the connection until
> > the end of the test.
> 
> Right. Ok, then this is something different. You are using non-block  
> with buffering? How many hosts?
> 
> Cheers,
> 	-Brian
> 
> >
> >
> > Perhaps I need a refresher on the symptoms
> > of this problem.
> >
> > I am using FreeBSD 4.11 in these tests, so I don't know whether the
> > problem goes away with 6.2.
> >
> >
> > On Tue, 2008-01-22 at 18:55 -0800, Brian Aker wrote:
> >> Hi!
> >>
> >> I suspect that this is the problem I and Sean looked at while at the
> >> hackathon. FreeBSD's (and OSX) network stack do not properly flush on
> >> close() localhost.
> >>
> >> Cheers,
> >> 	-Brian
> >>
> >> On Jan 22, 2008, at 5:53 PM, Kevin Dalley wrote:
> >>
> >>> Yes, this is against localhost.
> >>>
> >>> When the tests are run against a different machine (though under
> >>> Linux),
> >>> the problem goes away.
> >>>
> >>>
> >>> On Tue, 2008-01-22 at 15:43 -0800, Brian Aker wrote:
> >>>> Hi!
> >>>>
> >>>> On Jan 22, 2008, at 9:51 AM, Kevin Dalley wrote:
> >>>>
> >>>>> client.  The libmemcached test case "./testapp generate_nonblock"
> >>>>> reliably shows this problem.  The client is stuck in a poll,  
> >>>>> waiting
> >>>>> for
> >>>>> the ability to write on a socket.
> >>>>
> >>>>
> >>>> Is this against localhost?
> >>>>
> >>>> Cheers,
> >>>> 	-Brian
> >>>>
> >>>> --