Readme `init/1` return value
tsloughter opened this issue · 4 comments
In the readme the return value from init/1
is {ok, {AskQueueSpec, AskRQueueSpec}}.
, but it should be {ok, {AskQueueSpec, AskRQueueSpec, MeterSpec}}.
now?
Good catch @tsloughter, that's right. I plan to redo the whole readme because it does not make it obvious enough how sbroker can be used.
In the next release it will be:
{ok, {AskQueueSpec, AskRQueueSpec, [MeterSpec]}}
So we can run any number of meters. The single meter was an intermediate step until all built in meters were written (they are now). I would prefer not to introduce meters at the start of the readme so will update it when doing multiple meters.
Cool, sounds good. I discovered this because I couldn't get any example to work even after adding the MeterSpec
, hehe. Was trying different specs and always getting bad_return_value
:
{bad_return_value,
{ok,{{sbroker_timeout_queue,{out,5000,drop,16}},
{sbroker_drop_queue,{out_r,drop,infinity}},
100}}}
This is the 0.7
format with master queue args :D. The third 3rd element was a "poll" timeout value. This hurt the upper percentiles because we could be slow to timeout requests in the queue. The queue args for time were in native units, which meant we always had to convert in the init/1
callback. Now all arguments use milli_seconds
and conversion is done by the queue to native
and we always use native
internal and when returning times.
Master now gives control of timeouts to the callback modules, e.g. the queues. This means sbroker_timeout_queue
can trigger a timeout for when the oldest request in the queue has been waiting for the timeout, e.g. 5000ms. A meter spec is a callback module with the same form as a queue. There are built in meters that use queue sojourn times to help with load balancing (sbetter_meter
), short circuiting/overload protection (sprotector_pie_meter
), overload (sasl) alarm (sbroker_alarm_meter
) or pool resizing (sregulator_meter
). The meter spec takes the same form as a queue spec, {Mod, Args}
. E.g.
{sbroker_alarm_meter, {100, 1000, ?MODULE}}
This will set an alarm with the alarm_handler
if messages spend longer than 100ms in the process message queue for a time window longer than 1000ms. Once the message queue is below 100ms for 1000ms the alarm is cleared.