I'm stumped. (also, your e-mails aren't updating the ticket...). It's impossible for a connection to get into the closed state without having event_del() and close() called on the socket. A socket slot isn't event_add()'ed again until after the state is reset to 'init_state'.
There was no code path for event_del to actually fail so far as I could see. I've e-mailed steven grimm for ideas but either that's not his e-mail anymore or he's not going to respond. I really don't know. I guess the old code would've just called conn_close again by accident... I don't see how the logic changed in any significant way in .18. Though again, if it happened with any frequency people's curr_conns stat would go negative. So... either that always happened and we never noticed, or your particular OS is corrupt. There're probably 10,000+ installs of .18+ now and only one complaint, so I'm a little hesitant to spend a ton of time on this until we get more reports. You should downgrade to .17. On Sun, 4 May 2014, notificati...@commando.io wrote: > Damn it, got network timeout. CPU 3 is using 100% cpu from memcached. > Here is the result of stat to verify using new version of memcached and > libevent: > > STAT version 1.4.19 > STAT libevent 2.0.18-stable > > > On Saturday, May 3, 2014 11:55:31 PM UTC-7, notifi...@commando.io wrote: > Just upgraded all 5 web-servers to memcached 1.4.19 with libevent > 2.0.18. Will advise if I see memcached timeouts. Should be good > though. > > Thanks so much for all the help and patience. Really appreciated. > > On Friday, May 2, 2014 10:20:26 PM UTC-7, memc...@googlecode.com wrote: > Updates: > Status: Invalid > > Comment #20 on issue 363 by dorma...@rydia.net: MemcachePool::get(): > Server > 127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout > http://code.google.com/p/memcached/issues/detail?id=363 > > Any repeat crashes? I'm going to close this. it looks like remi > shipped .19. reopen or open a new one if it hangs in the same way > somehow... > > Well. 19 won't be printing anything, and it won't hang, but if it's > actually our bug and not libevent it would end up spinning CPU. Keep an > eye > out I guess. > > -- > You received this message because this project is configured to send > all > issue notifications to this address. > You may adjust your notification preferences at: > https://code.google.com/hosting/settings > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to memcached+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
