kanaloa

kanaloa copied to clipboard

Right now it is the mechanism PullingDispatcher shutdown on queue completion. However it's not very robust for pushing dispatcher - it prevents the queue from automatically restarted when errors occur....

kailuowang

if statsD goes offline and then back online, statsD reporter stops sending metrics.

kailuowang

when the latency is below certain threshold, a pushing dispatcher can be in a direct mode that bypass Queue and Worker and directly send the work to backend without any...

kailuowang

Metrics report includes routee in the path

2

that way we can have per routee metrics

kailuowang

As suggested by @nsauro One idea is to provide a Backoff trait, which gets called for every timeout. An instance would need to be created per worker, and it is...

kailuowang

Each routee having its own worker pool and autothrottle allows us to throttle concurrency per routee, which makes sense since routees differ in performance.

kailuowang

Dispatcher API return a Future[Dispatcher]

1

When creating a Dispatcher right now, the Dispatcher constructor returns immediately, even though behind the scenes there is still some initialization going on. We should change this to return a...

nsauro

when the backend is behaving completely irregularly (no apparent patten in throughput and latency) kanaloa should at least ensure it is not a limit factor.

kailuowang

Dispatcher should have a way to fail either a signal from the actual backend (tied to #79) or it fails after it sees the all worker dies (tied to #123...

kailuowang

which will include tests and integration tests see project/Publishing.scala for example of managing release steps

kailuowang