Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Here is the proposed multi-threaded semantics: flush doesn't block additional send calls from other threads. The semantics will be that any send from any thread that completes before flush initiates will be completed when the flush call completes (flush flushes all buffered messages, not just the ones sent by the current thread). Other threads can initiate sends while flush is in progress and these sends won't be blocked and may well be included in the requests resulting from the flush however there is no guarantee one way or another.The flush

call itself will hold a lock so that only one flush call can be invoked at any given time (this is for implementation simplicity as it is tricky to have multiple flush calls in progress at a given time and track the point they each guaranteeThere can be multiple flush calls occurring at the same time, each will just block until all the record batches that were in the accumulator at the time that flush call was invoked have been completed.

Currently there is no hard request timeout except what the server enforces, however when a client side timeout is added we can bound the time flush() will take by this timeout since after that time expires the request will be considered failed and hence completed.

...