Persistence? about cote

[thelinuxlich]

Do you have plans for a adapter interface so it can be stored in disk, redis, or whatever and if the requester restarts, it reads this log and resends?

[dashersw]

Messages are kept in the Requester's memory, basically in an in-memory array, so currently it's volatile.

[thelinuxlich]

Also, does the Requester queue has exponential backoff?

[dashersw]

An adapter could really be interesting, but I think it would complicate the solution. cote is designed to be technology independent and I can easily see developers thinking they have to use at least another technology for the Requester queue where in fact it's only necessary in extreme situations where every part of your application is failing. In that case, losing a few requests would be a minor concern. Redundancy is extremely cheap in cote, so developers are encouraged to have multiple Responder copies. That way, the need for a queue is also negligible.

Having said that, I would be happy to merge such a change set if anyone would pick up the creation of adapters for queues.

[dashersw]

The current implementation of the queue keeps the requests in the queue forever, doing nothing until a Responder is available. Upon discovering a Responder, a Requester flushes its queue all at once.

Since we do service discovery, we don't employ "reconnections" or "retries", because we always know if there's another component on the other hand to receive the request. I think exponential backoff would be a good solution if we had retries, and actually it's explicitly disabled because the underlying library, axon, has retry feature for connections, which is unnecessary with a service discovery mechanism.

In what other way do you think a backoff solution would be useful?

[tvalletta]

I believe the assumption here (referring to the backoff solution) is that the request could expire. An expectation borne from dealing with HTTP for a generation is that requests must eventually respond. A request made to a service that will never respond, never log and never error is a recipe for code that is difficult to maintain.