Hmmm.. I should read the docs more carefully before I open my big mouth: I just noticed the KafkaProducer#send overload that takes a callback. That definitely helps address my concern though I think the API would be cleaner if there was only one variant that returned a future and you could register the callback with the future. This is not nearly as important as I’d thought given the ability to register a callback - just a preference.
On 1/31/14, 9:33 AM, "Oliver Dain" <od...@3cinteractive.com> wrote: >Hey all, > >I¹m excited about having a new Producer API, and I really like the idea of >removing the distinction between a synchronous and asynchronous producer. >The one comment I have about the current API is that it¹s hard to write >truly asynchronous code with the type of future returned by the send >method. The issue is that send returns a RecordSend and there¹s no way to >register a callback with that object. It is therefore necessary to poll >the object periodically to see if the send has completed. So if you have n >send calls outstanding you have to check n RecordSend objects which is >slow. In general this tends to lead to people using one thread per send >call and then calling RecordSend#await which removes much of the benefit >of an async API. > >I think it¹s much easier to write truly asynchronous code if the returned >future allows you to register a callback. That way, instead of polling you >can simply wait for the callback to be called. A good example of the kind >of thing I¹m thinking is the ListenableFuture class in the Guava >libraries: > >https://code.google.com/p/guava-libraries/wiki/ListenableFutureExplained > > >HTH, >Oliver >
