Open jclulow opened 8 years ago
I'm in the same position. Unfortunately I don't think this library is being actively maintained so we might need to find a solution ourselves
I'm also running in a similar issue. Depending of situation heartbeat does sometime seems to kick in ie. I did get "no heartbeat or data in last xx seconds" exception once, but most of the time I don't.
Listening for the "close" event I can see connection being closed between the 2 heartbeat, so I suspect the problem is with the if(self.socket.readable)
check which no longer check heartbeat after socket is closed.
@jclulow @chriswiggins did you find a solution to this problem?
@siboulet I'm working around it in my library -- https://github.com/joyent/node-urclient/blob/master/lib/mq.js#L362-L375
Anyone tried the new heartbeatForceReconnect option introduced in the latest 0.2.6 release?
https://github.com/postwait/node-amqp/commit/4a382125d18d74fdffa450afe5f46c0cff1aef57
4a38212 this fix is also failing and the issue is the same
If I set the
heartbeat
option (e.g. to5
), the client appears to correctly negotiate the heartbeat interval with RabbitMQ. The"heartbeat"
event is emitted at the correct interval when the server is ending heartbeats. If I disable the server while watching this output, the heartbeats (obviously) stop arriving but the client does not signal an error until I try to send a message -- even if this is many intervals later.I'm not yet completely familiar with the relatively esoteric socket state tracking being used in this library, but I don't see how this logic can be correct:
Specifically: if no data has arrived (heartbeats or otherwise), why would the socket be readable?