cote

cote copied to clipboard

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.

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.

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.

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?

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

@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.

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

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

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