[
https://issues.apache.org/jira/browse/LUCENE-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980547#action_12980547
]
Shai Erera commented on LUCENE-2856:
------------------------------------
I think start/endTime can be long and not Long?
Maybe instead of adding init/start/endTime to OneMerge, you can pass a 'time'
parameter to MergeEvent. So its signature will be MergeEvent(Type type, long
time, OneMerge merge). The 'time' parameter can then be interpreted according
to Type.
Even better, I think you can remove that parameter entirely, and have
MergeEvent call System.currentTimeMillis() and set its internal member
according to Type?
About this:
{code}
public long getMergeSegmentSize(boolean includeDocStores) throws IOException {
// nocommit: cache this?
return mergeInfo.sizeInBytes(includeDocStores);
}
{code}
SegmentInfo caches sizeInBytes, so I think the 'nocommit' can go away.
However, I did notice that SegmentInfo's cache is potentially buggy -- it
doesn't take into account 'includeDocStores'. I.e., if you call it once w/
'false' and then with 'true' (or vice versa), you won't get the right
sizeInBytes. I'll open a separate issue to fix this.
> Create IndexWriter event listener, specifically for merges
> ----------------------------------------------------------
>
> Key: LUCENE-2856
> URL: https://issues.apache.org/jira/browse/LUCENE-2856
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: 4.0
> Reporter: Jason Rutherglen
> Attachments: LUCENE-2856.patch
>
>
> The issue will allow users to monitor merges occurring within IndexWriter
> using a callback notifier event listener. This can be used by external
> applications such as Solr to monitor large segment merges.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
