On Jun 25, 2019, at 9:42 AM, wli...@bloomberg.net <wli...@bloomberg.net> wrote:
>> I'm still thinking about a possible solution using a global queue and a
>> global
>> timer (and the timer just resuming queued transactions at pre-defined
>> internal), but to implement that:
>> 1. Is it ok to put/store a transaction in an external queue?
>> 2. Is it safe to not call transaction.resume() in a plugin? (What is the API
>> I
> should call to stall the state machine while not tie up the invoking thread?)
>> 3. What kind of thread/group is safe to be used to call
>> transaction.continue()
> asynchronously?
>
> Regarding question 2) It seems the only API that I could use to stall is
> TSContSchedule. If that's the case, this might still be doable: I can
> schedule a relative large delay (larger than queue_size * rate-limit
> interval) using that API, and store the returned handle along with the
> transaction in the queue. Later when timer fires I would just cancel the
> scheduled continuation and call transaction.resume() instead. One scenario
> this won't work is if some other timeout out of our control being imposed on
> the transaction.
>
Yes, in theory it’s doable :) There are indeed a few timers (example,
active/inactive transaction timers) that you may need to tune depending on the
duration you need the transactions queued. Keep in mind also that the clients
may also timeout which means you’ll need to handle connection drops and other
associated error conditions.
I’d also be wary of the event loop itself being able to deliver your scheduled
timeout events reliably in practice - depending on how busy the event loop is,
I’ve seen timeouts take much longer than their scheduled values.
> What you do think? Is it a possible solution or just my fantasy ^_^?
