gistfile1.txt

- rtsource supervisor (controls rtq) attach and ETS table as in lager. One key: overload. read_concurrency
- rtq is only writer to ETS table
- rtq looks at mailbox, if over 2K message, set overload flag to true
- function in rtq (push), read from ETS table, if overload condition, don't send anything to RTQ
- another process under rtq supervisor, rtq_helper. Receives message from post commit hook that say "rtq overloaded"
- rtq_helper sends messages (all it does) to rtq saying "I dropped N message"
- rtq side sets it stats for this message
- rtq turns off OVERLOAD based on mailbox side (1/2 max or some heuristic)

My notes:

rtq's sup, attach an ets table to that.
one key: overload.
ets has high read concurrency.
rtq is the only process that writes to it.
When the rtq gets a queue message, it checks q'ed messages
on high number of messages, sets overload key to true.
the push function checks the overload key
if true, don't send.
helper process w/ rtq (rest for one after rtq in sup)
that helper process gets messages from post commit hook
every x messages it sends a message to rtq stating number of drops.
the rtq then increments it's drop count and sequence number by x.