Versions Compared

Key

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

Table of Contents

Status

Current state:  Under DiscussionAccepted

Discussion thread: here

Original motivation here.

JIRA: KAFKA-1865

Released: 0.8.3

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

...

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 guarantee

There 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.

Proposed Changes

The full description is pretty much covered in the api description. There is a first pass on implementation here.

Compatibility, Deprecation, and Migration Plan

...

No existing users of KafkaProducer should be broken, though.

Rejected

...

Alternative

  1. Do nothing and just instruct people to use the futures. 

  2. Making the signature flush(long timeout, TimeUnit), we decided it is good enough to allow setting a request timeout and having that be the implicit timeout for flush() (since then the requests will be considered failed and hence completed).