Closed kubi closed 9 years ago
liveness
rid
to inform the Worker that it is still interested to the request.
This is an optional feature that helps is looong running requests.heartbeats
When the Worker receives an heartbeat and the length is === 5, it means that the heartbeat comes directly from a Client for a specific request.
Is more clear now?
ps. what is not working for you? Do you have an example?
I'll try to prepare something over the weekend to show you my problem. In my opinion the internal method heartbeat
doesn't work. I do a lot of write()
and every time it "ticks" liveness goes down by 1, and after 3-4 times method reply.active()
returns false while stream is still up and running
It's normal that reply.active gives you false
because it doesn't receive a specific heartbeat for the related rid.
Indeed it's not well explained... sorry about that.
To have reply.active returning true
the related Client should send heartbeats for that specific Request to notify that the interest in the reply is still alive. This is something very unusual anyway, so we may want to improve this.
Ideas are appreciated
Thx for your asnwers. I've solved my problem with stream version of client - all i had to do was:
var heartbeat = true,
pigatoCllient = new pigato.Client();
var stream = pigatoCllient.request('workerName', data)
.on('data', function(partialData) {} // handle partial data
.on('end', function() { heartbeat = false; })
.on('error', function(err) { heartbeat = false; });
// send proper heartbeat;
setInterval(function() {
stream.heartbeat(); // add heartbeat === true check and clearInterval
},.pigatoClient.conf.heartbeat);
I don't know if i'm reading something wrong, but it seems that heartbeat part of
Worker.prototype.onMsg
function checks for params that are not passed byWorker.prototype.heartbeat
. lacksrid
param, and requires clientId that is never used.Sending heartbeat:
Heartbeat processing event onMsg requires message to have 5 parameters (and it only has 2)
It's a bit confusing for me ... there are 2 different "livenesses" one is [this|self].liveness and the other is req.liveness. When checking if reply is active req.liveness is tested but stream is still open because testing is done on this.liveness (which on every message is set to HEARTBEAT_LIVENESS)