[
https://issues.apache.org/jira/browse/KAFKA-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14518314#comment-14518314
]
Jay Kreps commented on KAFKA-1660:
----------------------------------
Here was the source of my paranoia about r/w locks compared to counters:
http://blog.takipi.com/java-8-stampedlocks-vs-readwritelocks-and-synchronized/
http://blog.takipi.com/java-8-longadders-the-fastest-way-to-add-numbers-concurrently/
Now they have added some new StampedLock that is meant to be a faster
replacement but is only in jdk 8.
This may not be applicable in the case where writes are really really rare
which may be why we don't see it in our perf testing.
My concern about RecordAccumulator complexity remains (basically nested locks
like that always seem to bite us). I'm not sure I have a better solution there
though. Let me think a bit and see if I can come up with anything.
> Ability to call close() with a timeout on the Java Kafka Producer.
> -------------------------------------------------------------------
>
> Key: KAFKA-1660
> URL: https://issues.apache.org/jira/browse/KAFKA-1660
> Project: Kafka
> Issue Type: Improvement
> Components: clients, producer
> Affects Versions: 0.8.2.0
> Reporter: Andrew Stein
> Assignee: Jiangjie Qin
> Fix For: 0.8.3
>
> Attachments: KAFKA-1660.patch, KAFKA-1660.patch,
> KAFKA-1660_2015-02-17_16:41:19.patch, KAFKA-1660_2015-03-02_10:41:49.patch,
> KAFKA-1660_2015-03-08_21:14:50.patch, KAFKA-1660_2015-03-09_12:56:39.patch,
> KAFKA-1660_2015-03-25_10:55:42.patch, KAFKA-1660_2015-03-27_16:35:42.patch,
> KAFKA-1660_2015-04-07_18:18:40.patch, KAFKA-1660_2015-04-08_14:01:12.patch,
> KAFKA-1660_2015-04-10_15:08:54.patch, KAFKA-1660_2015-04-16_11:35:37.patch,
> KAFKA-1660_2015-04-20_17:38:22.patch
>
>
> I would like the ability to call {{close}} with a timeout on the Java
> Client's KafkaProducer.
> h6. Workaround
> Currently, it is possible to ensure that {{close}} will return quickly by
> first doing a {{future.get(timeout)}} on the last future produced on each
> partition, but this means that the user has to define the partitions up front
> at the time of {{send}} and track the returned {{future}}'s
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
