> 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?
I think in the current design/prototype the callback is called from the IO thread - which is it needs to be fast. Since the callback is provided by the client, it could submit a longer-running task to an executor service (or signal some other thread that a RecordSend is complete). However, the task submission would still happen from the IO thread. > > > 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 > > > > -- Joel
