You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Peter Keegan (JIRA)" <ji...@apache.org> on 2007/10/03 02:05:50 UTC
[jira] Created: (LUCENE-1017) BoostingTermQuery performance
BoostingTermQuery performance
-----------------------------
Key: LUCENE-1017
URL: https://issues.apache.org/jira/browse/LUCENE-1017
Project: Lucene - Java
Issue Type: Improvement
Components: Search
Affects Versions: 2.2
Environment: all
Reporter: Peter Keegan
I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
TermQuery: 200 qps
BoostingTermQuery (extends SpanQuery): 97 qps
BoostingTermQuery (extends TermQuery): 130 qps
Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
Peter
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-1017) BoostingTermQuery performance
Posted by "Peter Keegan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Keegan updated LUCENE-1017:
---------------------------------
Attachment: BoostingTermQuery.java
Suggested change to BoostingTermQuery to extend TermQuery
> BoostingTermQuery performance
> -----------------------------
>
> Key: LUCENE-1017
> URL: https://issues.apache.org/jira/browse/LUCENE-1017
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.2
> Environment: all
> Reporter: Peter Keegan
> Attachments: BoostingTermQuery.java
>
>
> I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
> The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
> TermQuery: 200 qps
> BoostingTermQuery (extends SpanQuery): 97 qps
> BoostingTermQuery (extends TermQuery): 130 qps
> Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
> Peter
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1017) BoostingTermQuery performance
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550207 ]
Grant Ingersoll commented on LUCENE-1017:
-----------------------------------------
{quote}
I still think it would be nice to have BoostingTermQuery that extends TermQuery, though.
{quote}
What's the use case? Is there something that isn't possible with it as is?
> BoostingTermQuery performance
> -----------------------------
>
> Key: LUCENE-1017
> URL: https://issues.apache.org/jira/browse/LUCENE-1017
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.2
> Environment: all
> Reporter: Peter Keegan
> Priority: Minor
> Attachments: BoostingTermQuery.java, BoostingTermQuery.patch, termquery.patch
>
>
> I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
> The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
> TermQuery: 200 qps
> BoostingTermQuery (extends SpanQuery): 97 qps
> BoostingTermQuery (extends TermQuery): 130 qps
> Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
> Peter
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1017) BoostingTermQuery performance
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532107 ]
Grant Ingersoll commented on LUCENE-1017:
-----------------------------------------
You will have to look at what setFreqCurrentDoc() does. I have a feeling, though, that there really isn't anyway around what the current version does and that the performance difference is due to it not checking all the positions on a document. At any rate, the Span stuff needs more scrutiny performance wise, so it is worth another look.
There should be a unit test in the code that checks multiple payloads per document, etc. Have a look at that and try it out.
> BoostingTermQuery performance
> -----------------------------
>
> Key: LUCENE-1017
> URL: https://issues.apache.org/jira/browse/LUCENE-1017
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.2
> Environment: all
> Reporter: Peter Keegan
> Attachments: BoostingTermQuery.java, termquery.patch
>
>
> I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
> The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
> TermQuery: 200 qps
> BoostingTermQuery (extends SpanQuery): 97 qps
> BoostingTermQuery (extends TermQuery): 130 qps
> Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
> Peter
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1017) BoostingTermQuery performance
Posted by "Peter Keegan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550238 ]
Peter Keegan commented on LUCENE-1017:
--------------------------------------
> What's the use case? Is there something that isn't possible with it as is?
I would say "no", if we can conclude that there is no significant difference in performance between the 2 implementations.
As a developer, when I see queries based on SpanQuery or PhraseQuery, this a tip that there is a potential performance impact. On the plus side, renaming the current implementation to 'BoostingSpanQuery' might give the developer a better hint of the methods of its superclass, too.
Would you expect the cost of traversing the postings to be higher than reading the payload?
Peter
> BoostingTermQuery performance
> -----------------------------
>
> Key: LUCENE-1017
> URL: https://issues.apache.org/jira/browse/LUCENE-1017
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.2
> Environment: all
> Reporter: Peter Keegan
> Priority: Minor
> Attachments: BoostingTermQuery.java, BoostingTermQuery.patch, termquery.patch
>
>
> I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
> The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
> TermQuery: 200 qps
> BoostingTermQuery (extends SpanQuery): 97 qps
> BoostingTermQuery (extends TermQuery): 130 qps
> Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
> Peter
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1017) BoostingTermQuery performance
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531974 ]
Grant Ingersoll commented on LUCENE-1017:
-----------------------------------------
Can you do the BoostingTermQuery as a patch too, that way it will be easy to compare it against the current one? I don't recall seeing a package on the java file. Can you put it in the source tree and svn add it and then do svn diff.
Also, I notice you commented out setFreqCurrentDoc(), how is it that you are handling multiple payloads per document (that bit me the first time)?
> BoostingTermQuery performance
> -----------------------------
>
> Key: LUCENE-1017
> URL: https://issues.apache.org/jira/browse/LUCENE-1017
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.2
> Environment: all
> Reporter: Peter Keegan
> Attachments: BoostingTermQuery.java, termquery.patch
>
>
> I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
> The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
> TermQuery: 200 qps
> BoostingTermQuery (extends SpanQuery): 97 qps
> BoostingTermQuery (extends TermQuery): 130 qps
> Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
> Peter
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1017) BoostingTermQuery performance
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550198 ]
Grant Ingersoll commented on LUCENE-1017:
-----------------------------------------
Peter,
Can you share your test for measuring this? Ideally as a contrib/benchmark alg file. I am not sure why a skipTo would be faster, since is just iterating the TermPositions object as well, so I'd like to investigate further.
Thanks,
Grant
> BoostingTermQuery performance
> -----------------------------
>
> Key: LUCENE-1017
> URL: https://issues.apache.org/jira/browse/LUCENE-1017
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.2
> Environment: all
> Reporter: Peter Keegan
> Priority: Minor
> Attachments: BoostingTermQuery.java, BoostingTermQuery.patch, termquery.patch
>
>
> I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
> The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
> TermQuery: 200 qps
> BoostingTermQuery (extends SpanQuery): 97 qps
> BoostingTermQuery (extends TermQuery): 130 qps
> Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
> Peter
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-1017) BoostingTermQuery performance
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Grant Ingersoll updated LUCENE-1017:
------------------------------------
Priority: Minor (was: Major)
Lucene Fields: [New, Patch Available] (was: [Patch Available, New])
> BoostingTermQuery performance
> -----------------------------
>
> Key: LUCENE-1017
> URL: https://issues.apache.org/jira/browse/LUCENE-1017
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.2
> Environment: all
> Reporter: Peter Keegan
> Priority: Minor
> Attachments: BoostingTermQuery.java, BoostingTermQuery.patch, termquery.patch
>
>
> I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
> The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
> TermQuery: 200 qps
> BoostingTermQuery (extends SpanQuery): 97 qps
> BoostingTermQuery (extends TermQuery): 130 qps
> Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
> Peter
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-1017) BoostingTermQuery performance
Posted by "Peter Keegan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Keegan updated LUCENE-1017:
---------------------------------
Attachment: termquery.patch
Changes to TermQuery and TermScorer for previous patch
> BoostingTermQuery performance
> -----------------------------
>
> Key: LUCENE-1017
> URL: https://issues.apache.org/jira/browse/LUCENE-1017
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.2
> Environment: all
> Reporter: Peter Keegan
> Attachments: BoostingTermQuery.java, termquery.patch
>
>
> I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
> The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
> TermQuery: 200 qps
> BoostingTermQuery (extends SpanQuery): 97 qps
> BoostingTermQuery (extends TermQuery): 130 qps
> Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
> Peter
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1017) BoostingTermQuery performance
Posted by "Peter Keegan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550203 ]
Peter Keegan commented on LUCENE-1017:
--------------------------------------
Grant,
Unfortunately, my performance test bed isn't suitable for contrib/benchmark because it's designed to simulate real queries from our log files. These are multi-threaded queries sent at a very high rate to stress test the Lucene server, which runs on an 8 cpu system.
Given the somewhat dynamic nature of the test bed, I don't think the 5% performance increase that I reported is statistically significant. You're probably right that skipTo is not likely any faster. I still think it would be nice to have BoostingTermQuery that extends TermQuery, though.
Peter
> BoostingTermQuery performance
> -----------------------------
>
> Key: LUCENE-1017
> URL: https://issues.apache.org/jira/browse/LUCENE-1017
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.2
> Environment: all
> Reporter: Peter Keegan
> Priority: Minor
> Attachments: BoostingTermQuery.java, BoostingTermQuery.patch, termquery.patch
>
>
> I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
> The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
> TermQuery: 200 qps
> BoostingTermQuery (extends SpanQuery): 97 qps
> BoostingTermQuery (extends TermQuery): 130 qps
> Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
> Peter
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1017) BoostingTermQuery performance
Posted by "Peter Keegan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532094 ]
Peter Keegan commented on LUCENE-1017:
--------------------------------------
Grant,
You are right about it not handling multiple payloads per document. In fact, I don't think it's even reading the payloads for all the hits. I'll see what I can do, but feel free to step in and help me get this right. I won't touch svn for now.
Peter
> BoostingTermQuery performance
> -----------------------------
>
> Key: LUCENE-1017
> URL: https://issues.apache.org/jira/browse/LUCENE-1017
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.2
> Environment: all
> Reporter: Peter Keegan
> Attachments: BoostingTermQuery.java, termquery.patch
>
>
> I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
> The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
> TermQuery: 200 qps
> BoostingTermQuery (extends SpanQuery): 97 qps
> BoostingTermQuery (extends TermQuery): 130 qps
> Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
> Peter
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-1017) BoostingTermQuery performance
Posted by "Peter Keegan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Keegan updated LUCENE-1017:
---------------------------------
Attachment: BoostingTermQuery.patch
Here is new version that traverses the term positions properly, I believe. It's only about 5% faster than the spans version, though. It's quite possible that this could be improved. I'm using TermScorer to get me to the current doc and then setting TermPositions to the same doc. Do you see any inefficiencies with the 'next' and 'skipTo' calls, particularly in 'getPayloads'?
> BoostingTermQuery performance
> -----------------------------
>
> Key: LUCENE-1017
> URL: https://issues.apache.org/jira/browse/LUCENE-1017
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.2
> Environment: all
> Reporter: Peter Keegan
> Attachments: BoostingTermQuery.java, BoostingTermQuery.patch, termquery.patch
>
>
> I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
> The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
> TermQuery: 200 qps
> BoostingTermQuery (extends SpanQuery): 97 qps
> BoostingTermQuery (extends TermQuery): 130 qps
> Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
> Peter
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org