I don't think anyone knows why that particular port of memcached has
trouble; I'm assuming it's a buggy libevent, or buggy interaction with
libevent. Given that it's an unhandled socket error :P

Where did you get the windows binary from?

On Tue, 8 Feb 2011, Roberto Spadim wrote:

> =] can you use 1.2.1 without problems? use it ehheeheh
> i don't know if you will get more speed with newer version
> if you don't know, please continue trying in this mail list. i can't
> help with windows :(
>
> 2011/2/8 Sean <[email protected]>:
> > I am using only one telnet to test the memcache. So only one client
> > and 0 keys. On the same machine, if I run memcached.exe version 1.2.1,
> > it works fine.
> >
> > On Feb 8, 2:02 pm, Roberto Spadim <[email protected]> wrote:
> >> i don't know, but can memcache use windows pipes?
> >> shared memory protocol?
> >> for loop back (127.0.0.1) arp table have always 1 register (internal
> >> on arp engine, or inside arp table), i think that's not a arp problem
> >> too...
> >> maybe windows virtual memory problem?
> >> what's your today app size?
> >> how many clients at same time?
> >> how many keys?
> >> what's the average key length?
> >>
> >> 2011/2/8  <[email protected]>:
> >>
> >>
> >>
> >> > Comment #9 on issue 122 by [email protected]: failed to write, and not
> >> > due blocking: No error
> >> >http://code.google.com/p/memcached/issues/detail?id=122
> >>
> >> > I don't think it's related to ARP either, since I am using the loopback
> >> > interface 127.0.0.1. The arp table is not full. I can stably repro this
> >> > issue on a few machines right after I start the memcache.exe. On some 
> >> > other
> >> > machines, it works fine though. I can't figure out the differences 
> >> > between
> >> > these machines. They are of the same Windows version with all last 
> >> > patches.
> >>
> >> --
> >> Roberto Spadim
> >> Spadim Technology / SPAEmpresarial
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>

Reply via email to