[
https://issues.apache.org/jira/browse/LUCENE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099154#comment-13099154
]
Simon Willnauer commented on LUCENE-3416:
-----------------------------------------
bq. The only reason its synchronized is because the setMaxMergeWriteMBPerSec
method is synchronized (I guess to protected from setting the rate limit
concurrently). In practice, I don't see users changing it that often, so
concerns about cache lines are not really relevant.
this make no sense to me. If you don't want to set this concurrently how does a
lock protect you from this? I mean you if you have two threads accessing this
you have either A B or B A. but this would happen without a lock too. if you
want to have the changes to take effect immediately you need to either lock on
each read on this var or make it volatile which is almost equivalent (a mem
barrier).
My concern here was related to make this var volatile which would be a
cacheline invalidation each time you read the var. I think we should get rid of
the synchronized.
> Allow to pass an instance of RateLimiter to FSDirectory allowing to rate
> limit merge IO across several directories / instances
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-3416
> URL: https://issues.apache.org/jira/browse/LUCENE-3416
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/store
> Reporter: Shay Banon
> Assignee: Simon Willnauer
> Attachments: LUCENE-3416.patch
>
>
> This can come in handy when running several Lucene indices in the same VM,
> and wishing to rate limit merge across all of them.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
