failed to write, and not due blocking: No error

[GoogleCodeExporter]

Hi,
i am running memcached 1.4.4 win32 on windows server 64 bit,
i have on this server 4 instances of memcached 2G each.
few weeks ago we started to see that the instances from time to time are 
freezing for 2 minutes and then get back to work, they are all freezing 
almost at the same time when i ran it in -vv mode i saw the following:

<3564 new auto-negotiating client connection
<2440 new auto-negotiating client connection
240: Client using the ascii protocol
<240 get CheckUserCookie:1714451
>240 END
<3408 connection closed.
3564: Client using the ascii protocol
<3564 get SortedLiveShows:3,0,1714273,0,1,0
>3564 sending key SortedLiveShows:3,0,1714273,0,1,0
>3564 END
Failed to write, and not due to blocking: No error
<3564 connection closed.
<240 connection closed.
2440: Client using the ascii protocol
<2440 get MyTags:4,1616578,1,1616578,3,1,50,0
>2440 sending key MyTags:4,1616578,1,1616578,3,1,50,02 257 1309
>2440 END
<2440 connection closed.

and here it is freezing for to minutes
let me just say that if i run only one instance of memcached  on the 
server it works fine with out any glitch

is some one have any idea what could be wrong?

thank you 
Eyal Sela

Original issue reported on code.google.com by mr.s...@gmail.com on 18 Feb 2010 at 4:12

[GoogleCodeExporter]

I have just installed win32-1.4.4-54 server along with 
memcacheddotnet_clientlib-1.1.5 and am getting 'Failed to write, and not due to 
blocking: No error' every time my client calls the server(Get, Set, Stats, 
i.e.).  I have tried tweaking the command line args with no success.  Any 
ideas.  I've run memcached on linux for years without any type of problems but 
as usual there is probably an issue with something in windoze7.

thx.

Original comment by billyle...@suddenlink.net on 22 Jul 2010 at 11:27

[GoogleCodeExporter]

I have the same issue. Have anyone solve this problem?

Original comment by sean.y....@gmail.com on 7 Feb 2011 at 11:39

[GoogleCodeExporter]

maybe problem with tcp/ip or arp table?
try with udp client/server protocol

Original comment by rspa...@gmail.com on 7 Feb 2011 at 11:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks. Could you please explain what are the possible problems with arp table? 
If I use UDP, how can I make sure it's working fine without the help of the 
telnet interface?

I'm using Memcached 1.4.5 one W2K8 Server R2. And I am testing the memcached 
server from the local machine using telnet. It's giving me the following error 
when I send "STATS" in telnet:

<1352 server listening (auto-negotiate)
<1368 send buffer was 8192, now 268435456
<1368 server listening (udp)
<1368 server listening (udp)
<1368 server listening (udp)
<1368 server listening (udp)
<1380 new auto-negotiating client connection
1380: Client using the ascii protocol
<1380 stats
Failed to write, and not due to blocking: No error
<1380 connection closed.

Thanks again.

Original comment by sean.y....@gmail.com on 8 Feb 2011 at 12:23

[GoogleCodeExporter]

I don't know why one might assume the problem is below layer 3 -- or even 
outside of memcached itself.

It's likely to be related to the Windows port itself (which is not something we 
built or planned to support in 1.4.4, though we've done a lot of work since).

Original comment by dsalli...@gmail.com on 8 Feb 2011 at 1:23

[GoogleCodeExporter]

This happened when the memcached was trying to send the response back to the 
client. The socket error number is 10054, which generally means the socket was 
forcibly closed by the remote host. However, I am using "memcached.exe -l 
127.0.0.1 -p 8199" When I telnet 127.0.0.1 8199, I don't know why the socket 
will be closed. Could anybody shred some light on this issue?

Original comment by sean.y....@gmail.com on 8 Feb 2011 at 8:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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. 

Original comment by sean.y....@gmail.com on 8 Feb 2011 at 8:58

[GoogleCodeExporter]

I'm closing this, as 1.4 under windows isn't supported. If anyone on this 
thread tries the 1.6 release under windows and has a similar issue, please feel 
free to open a new bug.

Original comment by dorma...@rydia.net on 12 Jul 2011 at 11:13

• Changed state: WontFix

[GoogleCodeExporter]

The same:

slab class  40: chunk size    573744 perslab       1
slab class  41: chunk size    717184 perslab       1
slab class  42: chunk size   1048576 perslab       1
<1564 server listening (auto-negotiate)
<1580 send buffer was 64512, now 268435456
<1580 server listening (udp)
<1580 server listening (udp)
<1580 server listening (udp)
<1580 server listening (udp)
<1592 new auto-negotiating client connection
1592: Client using the ascii protocol
<1592 set some_key 0 0 10
>1592 STORED
Failed to write, and not due to blocking: No error
<1592 connection closed.
<1592 new auto-negotiating client connection
1592: Client using the ascii protocol
<1592 set some_key 0 0 10
>1592 STORED
Failed to write, and not due to blocking: No error
<1592 connection closed.

Original comment by pavlovma...@gmail.com on 29 Jun 2012 at 12:26