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 > >>>> > >>>> --
