The trouble with callbacks, IMHO, is determining the thread in which they will be executed. Since the IO thread is usually the thread that knows when the operation is complete, it's easiest to execute that callback within the IO thread. This can lead the IO thread to spend all its time on callbacks and not IO.
Is there an executor service associated with the client that actually executes the callback, or is the callback executed by the IO thread? --Tom On Fri, Jan 31, 2014 at 10: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 > >
