|
|
|
|
|
|
by potatosareok
3885 days ago
|
|
|
afaik the cannot identify protocol is normally caused by, as is the case here, half open TCP connection. Seems bug is caused by a mix of using pooled connection manager on python side, not familiar enough with go or etcd to look into it. Seems what author could really use is eventloop on python side, to deal with having blocking forever to read long polling and also respond to signals (or however kill handled). Probably some way to wrap requets(stream=True) w/ it's yield into whatever people use for asyncio in Python now, and another listener in event loop listening for kill singal? Curious about what on go side doesn't actually close the tcp connection, I'd assume channel (assumming it's using channels per watcher) would catch some exception when socket is closed on python side, maybe just socket is never closed after exception? Time to try learn some go to see in etcd code base... |
|
|
Either end of a connection doesn't know if the other end closed it until they try to do something with the socket, per the BSD socket API. The etcd watch API, from reading the article, doesn't reply until an event occurs, so if an event never occurs in time (before a whole bunch more requests come in), it won't do anything with the socket, and thus won't find out the other end closed it.