Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka >> mail # dev >> Review Request 17263: New producer for Kafka.

Copy link to this message
Re: Review Request 17263: New producer for Kafka.

This is an automatically generated e-mail. To reply, visit:


    If the caller implements onCompletion to block for a while, the io thread would be blocked. Should this be mentioned somewhere in the interface?


    "you can easily achieve"


    I think what you meant here when you said "the callback will execute in the I/O thread of the producer and so should be reasonably fast." is that the callback should be implemented such that it returns immediately. This is not very obvious from the current description.


    I am not a big fan of this api. I started on these lines for another project and it soon made me reimplement most of codahale features which really is not worth it. I understand the reasoning behind this (not have dependency on external libraries and have any reporters written) but it becomes a pain to maintain, reimplement and stabilize. Also, clients would now have to understand how to use this data to implement metrics. Codahale already supports quite a few reporters. An alternative to the current approach is to take a list of reporters from the config and instantiate them in code using codahale reporters. The project is very active and have done quite a few optimizations recently which are useful. We could end up being handicapped because we may not have the right metrics and only way to get it is to implement something on our own.


    make use of the key


    This seems a bit confusing. It would be useful to keep the usage of RecordSend in the callback and sync producer to be the same. Is there any reason that await throws on error when you have apis to check error?


    A little more information on how availableMemory and free list are used would be useful to comment about.


    Is this exception safe?


    What happens if freeUp actually got memory from the free list? We still seem to create a new buffer with the given size. Why are we not returning from the pool? It looks like availableMemory can go negative here.


    We can allocate a batch larger than the batchSize?


    ready to be sent


    I am assuming this method is called only by a single thread and hence there is no requirement to synchronize here


    magic number
- Sriram Subramanian
On Jan. 23, 2014, 8:54 p.m., Jay Kreps wrote: