TTL for requests

[mikield]

I can not find any information for a request TTL option.

As I understand Requester is gathering requests if has no Responder connected (offline for example)
These requests have no TTL, and are executed when Responder goes live.

What I want is to set a TTL for the same way as timeout option. So that if my Responder has not gone live in for example 30 secs - just ignore that request.

In my application client based services can do many requests, but if my Responder server will go offline, and then after 10 mins go live - that response is not needed already.

[dashersw]

How is this different than the timeout functionality?

Timeout
A timeout could be configured for all Requesters as an environment variable COTE_REQUEST_TIMEOUT, or in advertisement options for specific Requester, or in a property called __timeout in first argument of requester.send method. Latter setting overrides former. Timeout is specified in milliseconds.

[dashersw]

Oh I see, so even if we have timeout, we initially send the messages but just drop the callback.

This makes a lot of sense. Currently cote doesn't offer this functionality, but it's somewhat easy to override with a custom logic. cote stores outgoing messages in a queue in the requester; you can actually reset it with requester.sock.queue = [].

So if you manually implement a timer to check for lost connections, at the end requester.sock.queue = [] will get rid of the queue.

If you'd consider contributing this functionality to cote, I'd love to have this feature.

[dilame]

Funny coincidence, I was just thinking the same thing, and @mikield asked about it just 6 hours ago.
What if i use redis as discovery tool? Behavior is the same?

[dashersw]

Yes, redis only supports us with finding other services, the rest of the communication is the same, through cote and TCP sockets.

[mikield]

@dashersw do we have some sort of id for the queued messages?

Cause if I will implement that by Application side - i want to remove a message/request but not to clear full queue table.

[dashersw]

Not by default, but you can put a unique id into your requests and then requester.sock.queue.filter according to that.

[mikield]

@dashersw I have noticed 2 new Requesters.
Does a TimeBasedRequester solves this issue?

[dashersw]

@mikield no, it's only a routing prioritization based on response times.