[
https://issues.apache.org/jira/browse/LUCENE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099233#comment-13099233
]
Shay Banon commented on LUCENE-3416:
------------------------------------
I agree with Mike, I think it should remain synchronized, it does safeguard
concurrently calling setMaxMergeWriteMBPerSec from falling over itself (who
"wins" the call is not really relevant). Since thats synchronized, the metod I
added should be as well. Personally, I really don't think there is a need to
make it thread safe without "blocking", since calling the "setters" is not
something people do frequently at all, so the optimization is mute, and it will
complicate the code.
As for making mergeWriteRateLimiter volatile, it can be done. Though, in
practice, there really is no need to do it (there is a memory barrier when
reading it before). But, I think that should go in a different issue? Just to
keep changes clean and isolated?
> 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
