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

Switch to Threaded View
Kafka >> mail # dev >> Review Request 21304: Fix KAFKA-1445


Copy link to this message
-
Re: Review Request 21304: Fix KAFKA-1445

This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21304/#review42734

clients/src/main/java/org/apache/kafka/clients/producer/internals/RecordAccumulator.java
<https://reviews.apache.org/r/21304/#comment76592>

    Does this need to be volatile? Do we actually need it? It is a little hard to know how to interpret it...

clients/src/main/java/org/apache/kafka/clients/producer/internals/RecordAccumulator.java
<https://reviews.apache.org/r/21304/#comment76593>

    It seems like this only works some of the time. Let's say you have two partitions F and N where F is full and N has a message but isn't full. If you happen to process F then N, N will carpool, but if you process N then F it won't. So you only get 50% of the carpooling you should (on avg). Perhaps I am misunderstanding?

clients/src/main/java/org/apache/kafka/clients/producer/internals/RecordAccumulator.java
<https://reviews.apache.org/r/21304/#comment76594>

    This linear search may be a bit problematic for large partition counts, no?
    
    Set will be slower in the common case but faster in the extreme case.
    
    Either way we should probably just keep the node id so the comparison is just of a boxed integer rather than a compound object.
- Jay Kreps
On May 10, 2014, 9:38 p.m., Guozhang Wang wrote: