can you try the same process but with UDP protocol? maybe it's a TCP problem (not a memcached problem) i'm thinking about possible problems, if you don't want to try it...
on linux i had the same problem but with another software (network file system, and apache) no error code was reported, but at /var/log/messages i could get the arp table overflowed maybe this could help you to solve the problem... since my first problem (apache/nfs) wasn't at level3, it's at level 6,7 in my case, arp was running (it didn't stoped) but didn't accept a new 'record' in table (a new client) after some time the cache get out (near 2 minutes!) and my program get normal again try with UDP... i think it can help, if not let's think about other problem 2011/2/8 Dustin <[email protected]>: > > Thank you for not responding in the bug. I would like to reduce > confusion over there. > > On Feb 7, 5:53 pm, Roberto Spadim <[email protected]> wrote: >> no not below layer3, it´s a overfloow of table > > ARP is a mechanism to find layer 3 addresses on layer 2. > > I still don't see why you believe that an address lookup table is > causing this exact error on exactly one platform... > >> on linux you will get a table overflow (cache), wait some time and you >> will get you network running again (i don´t know how to flush arp >> cache) > > ...which is not Linux. > > If you know why this exact error (which claims to not be a layer 3 > write failure with no actual error code recorded) on Windows would be > caused by address resolution for three different users under > relatively no traffic, then that may lead us to a solution. > > I don't actually know Windows enough to know why it would happen. I > also don't know where these builds came from. I'd blame the memcached > Windows code long, long before assuming Windows can't write data over > a socket due to ARP. -- Roberto Spadim Spadim Technology / SPAEmpresarial
