[
https://issues.apache.org/jira/browse/LUCENE-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491390#comment-13491390
]
Michael McCandless commented on LUCENE-4537:
--------------------------------------------
I think rate limiting merge IO is important functionality: merges
easily kill search performance if you index/search on one box (NRT
app).
But I agree: Directory is abstract and minimal and we should keep it
that way.
A generic wrapper around any IO would be great ... but I'm not sure
how we'd do it? EG, would we have to tally up our own bytes in every
write method (writeInt/Long/VInt/VLong/etc.)? Maybe that's acceptable?
It's only for writing ...
Or maybe we only make RateLimitingBufferedIO subclass? Though I had
wanted to try this with RAMDirectory too (playing with Zing)... I
guess we could make a RateLimitingRAMOutputStream ...
> Move RateLimiter up to Directory and make it IOContext aware
> ------------------------------------------------------------
>
> Key: LUCENE-4537
> URL: https://issues.apache.org/jira/browse/LUCENE-4537
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/store
> Affects Versions: 4.0
> Reporter: Simon Willnauer
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4537.patch, LUCENE-4537.patch, LUCENE-4537.patch
>
>
> Currently the RateLimiter only applies to FSDirectory which is fine in
> general but always requires casts and other dir. impls (custom ones could
> benefit from this too.) We are also only able to rate limit merge operations
> which limits the functionality here a lot. Since we have the context
> information what the IndexOutput is used for we can use that for rate
> limiting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
