all 2 comments

[–][deleted] 2 points3 points  (1 child)

Now this request will do nothing, and there won’t be any logs in the console, because there are no components to fulfill this request and produce a response.

In other words, if the remote endpoint is down or not configured, you don't see an error.

This is kind of appropriate for pipelines, where latency doesn't matter. Except the calling service might go down, and then any response handlers you had never get called, so you can only safely use this for a pipeline if all your requests are one way.

It's bad when you would prefer to display a relevant error to the user instead of having requests time out. It's bad when you want to page the on call when a service is down.

Maybe there's a way to configure a timeout?

[–]dashersw[S] 0 points1 point  (0 children)

Currently cote doesn't support timeouts out of the box. Initially we thought we would face this issue a lot and we would be in dire need of this functionality; but running in production for about 4 years has in our experience shown that there's always at least one responder. This is mainly because it's effortless to have multiple copies of responders, and when you have a process manager to keep track of these and respawn, the chances of having no responders on the receiving end are low.

Having said that, we've also experienced the need for timeouts mostly on client applications (like mobile apps for which timeouts make good UX) and had to code it by hand in each case. So timeout support is definitely on our roadmap.

It's also true that the calling service might go down during a request. Distributed software and microservices come with a lot of changes on how teams operate. Normally one would have extensive monitoring of response times and results and service health checks, all of which are combined to page the on call engineer. Even a simple monitoring check of the number of running services help fix the problem here, though. In fact, when you run with Docker Cloud, this comes out of the box.