[ 
https://issues.apache.org/jira/browse/KAFKA-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490624#comment-14490624
 ] 

Jiangjie Qin commented on KAFKA-2102:
-------------------------------------

I'm with Ewen on this. We probably can take a further look at the way we do the 
patch. Finer locking makes sense only if it provides good performance 
improvement. Here are some thinking:
1. For infrequent method call, we don't need fine lock.
2. For frequent method call, we can check if they really need lock to each 
other.
For metadata, most of the methods are infrequently called, so putting 
synchronized methods are probably fine. There are two exceptions:
1. timeToNextUpdate() - only called by sender thread.
2. containsTopic() - called by caller thread.
Those two methods does not conflict with each other at all. and 1) is only 
called by sender thread. So maybe we can try just replace topics with a 
concurrent hashset and remove the synchronization on containsTopic().

> Remove unnecessary synchronization when managing metadata
> ---------------------------------------------------------
>
>                 Key: KAFKA-2102
>                 URL: https://issues.apache.org/jira/browse/KAFKA-2102
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Tim Brooks
>            Assignee: Tim Brooks
>         Attachments: KAFKA-2102.patch, KAFKA-2102_2015-04-08_00:20:33.patch
>
>
> Usage of the org.apache.kafka.clients.Metadata class is synchronized. It 
> seems like the current functionality could be maintained without 
> synchronizing the whole class.
> I have been working on improving this by moving to finer grained locks and 
> using atomic operations. My initial benchmarking of the producer is that this 
> will improve latency (using HDRHistogram) on submitting messages.
> I have produced an initial patch. I do not necessarily believe this is 
> complete. And I want to definitely produce some more benchmarks. However, I 
> wanted to get early feedback because this change could be deceptively tricky.
> I am interested in knowing if this is:
> 1. Something that is of interest to the maintainers/community.
> 2. Along the right track
> 3. If there are any gotchas that make my current approach naive.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to