Re: [PR] Change StringHelper from abstract to final. [lucene]
uschindler commented on PR #13928: URL: https://github.com/apache/lucene/pull/13928#issuecomment-2422935859 If you really want to change it, make it final. But it's not necessary. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Include java21 source folders to gradle source sets [lucene]
dweiss commented on PR #13926: URL: https://github.com/apache/lucene/pull/13926#issuecomment-2423618479 Right... I forgot about that. If so then adding this to intellij will be even more complicated because it'd have to be another module, with a different set of compilation flags. Perhaps you can do it manually - I'm not sure. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Change StringHelper from abstract to final. [lucene]
vsop-479 closed pull request #13928: Change StringHelper from abstract to final. URL: https://github.com/apache/lucene/pull/13928 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Include java21 source folders to gradle source sets [lucene]
javanna commented on PR #13926: URL: https://github.com/apache/lucene/pull/13926#issuecomment-2423129841 > Thank you for addressing this! I wish I did! But I know that Chris has been looking at finding some solution around having IDEs import these classes as source sets. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[PR] Move BooleanScorer to work on top of Scorers rather than BulkScorers. [lucene]
jpountz opened a new pull request, #13931: URL: https://github.com/apache/lucene/pull/13931 I was looking at some queries where Lucene performs significantly worse than Tantivy at https://tantivy-search.github.io/bench/, and found out that we get quite some overhead from implementing `BooleanScorer` on top of `BulkScorer` (effectively implemented by `DefaultBulkScorer` since it only runs term queries as boolean clauses) rather than `Scorer` directly. The `CountOrHighHigh` and `CountOrHighMed` tasks are a bit noisy on my machine, so I did 3 runs on wikibigall, and all of them had speedups for these two tasks, often with a very low p-value. In theory, this change could make things slower when the inner query has a specialized bulk scorer, such as `MatchAllDocsQuery` or a conjunction. It does feel right to optimize for term queries though. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Move BooleanScorer to work on top of Scorers rather than BulkScorers. [lucene]
jpountz commented on PR #13931: URL: https://github.com/apache/lucene/pull/13931#issuecomment-2422772402 ``` TaskQPS baseline StdDevQPS my_modified_version StdDevPct diff p-value Wildcard 159.36 (2.9%) 156.17 (5.3%) -2.0% ( -9% -6%) 0.232 AndHighLow 746.04 (4.5%) 732.70 (4.1%) -1.8% ( -9% -7%) 0.290 CountAndHighHigh 96.45 (3.7%) 95.82 (2.7%) -0.7% ( -6% -6%) 0.611 And2Terms2StopWords 209.77 (5.5%) 208.53 (5.5%) -0.6% ( -10% - 10%) 0.784 And3Terms 228.00 (7.2%) 226.66 (7.4%) -0.6% ( -14% - 15%) 0.838 HighTermTitleSort 88.93 (2.9%) 88.48 (4.3%) -0.5% ( -7% -6%) 0.720 CountTerm 5973.32 (5.9%) 5943.88 (4.9%) -0.5% ( -10% - 10%) 0.817 HighTerm 342.55 (5.2%) 341.44 (5.4%) -0.3% ( -10% - 10%) 0.878 CountAndHighMed 227.59 (4.3%) 227.14 (6.2%) -0.2% ( -10% - 10%) 0.924 Prefix3 221.09 (6.7%) 220.79 (5.8%) -0.1% ( -11% - 13%) 0.956 AndHighHigh 126.14 (4.5%) 126.07 (2.4%) -0.1% ( -6% -7%) 0.967 LowTerm 526.10 (4.2%) 526.53 (3.9%)0.1% ( -7% -8%) 0.959 OrHighLow 521.66 (3.9%) 523.36 (2.9%)0.3% ( -6% -7%) 0.808 OrMany 24.25 (4.3%) 24.35 (2.7%)0.4% ( -6% -7%) 0.769 HighTermMonthSort 790.01 (1.9%) 793.38 (2.4%)0.4% ( -3% -4%) 0.619 PKLookup 190.87 (3.0%) 191.74 (3.0%)0.5% ( -5% -6%) 0.697 OrHighNotHigh 227.35 (4.1%) 228.77 (4.7%)0.6% ( -7% -9%) 0.718 IntNRQ 257.99 (7.3%) 260.43 (6.4%)0.9% ( -11% - 15%) 0.725 OrHighHigh 123.13 (5.3%) 124.34 (4.2%)1.0% ( -8% - 11%) 0.601 OrNotHighLow 696.35 (5.1%) 703.21 (4.3%)1.0% ( -8% - 10%) 0.594 MedTerm 422.03 (6.3%) 427.16 (5.1%)1.2% ( -9% - 13%) 0.589 TermDTSort 216.84 (3.9%) 220.04 (4.4%)1.5% ( -6% - 10%) 0.362 Or2Terms2StopWords 215.40 (5.4%) 218.92 (4.4%)1.6% ( -7% - 12%) 0.395 OrNotHighMed 262.76 (5.7%) 267.10 (3.8%)1.7% ( -7% - 11%) 0.385 OrNotHighHigh 201.90 (5.5%) 205.25 (2.6%)1.7% ( -6% - 10%) 0.324 OrHighMed 253.32 (6.8%) 258.46 (9.1%)2.0% ( -12% - 19%) 0.519 HighTermTitleBDVSort 31.08 (5.5%) 31.80 (6.3%)2.3% ( -8% - 14%) 0.314 AndHighMed 227.41 (3.8%) 232.96 (6.1%)2.4% ( -7% - 12%) 0.219 OrStopWords 66.05 (7.2%) 67.77 (4.0%)2.6% ( -7% - 14%) 0.251 OrHighNotLow 305.24 (6.5%) 313.48 (5.1%)2.7% ( -8% - 15%) 0.238 HighTermDayOfYearSort 313.33 (6.7%) 321.85 (6.7%)2.7% ( -9% - 17%) 0.300 Or3Terms 230.36 (5.1%) 237.14 (5.1%)2.9% ( -6% - 13%) 0.142 OrHighRare 243.26 (5.7%) 250.89 (5.8%)3.1% ( -7% - 15%) 0.163 AndStopWords 60.96 (6.2%) 63.00 (3.1%)3.3% ( -5% - 13%) 0.082 OrHighNotMed 294.99 (4.9%) 306.41 (5.2%)3.9% ( -5% - 14%) 0.050 CountOrHighMed 170.22 (6.6%) 199.04 (6.5%) 16.9% ( 3% - 32%) 0.000 CountOrHighHigh 111.03 (10.9%) 132.94 (3.8%) 19.7% ( 4% - 38%) 0.000 ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h
Re: [I] Performance difference between files getting opened with IOContext.RANDOM vs IOContext.READ during merges [lucene]
shatejas commented on issue #13920: URL: https://github.com/apache/lucene/issues/13920#issuecomment-2422871076 Understood, so with not cloning we are avoiding any ambiguity whether the original and other clones are getting affected or not. Not cloning makes it clear that any thread using the reader will get affected With regards to reverting, its restoring the previous state. Wrapper approach sounds good to me, I will try it out. Thanks @uschindler and @jpountz for your inputs! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Fix StoredFieldsConsumer finish [lucene]
linfn commented on PR #13927: URL: https://github.com/apache/lucene/pull/13927#issuecomment-2423476433 > Ouch, thanks for finding it and fixing it. Can you add a test? Test added. Let me know if anything else is needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Change StringHelper from abstract to final. [lucene]
vsop-479 commented on PR #13928: URL: https://github.com/apache/lucene/pull/13928#issuecomment-2423382437 > it's not necessary. I will close it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Convert BooleanClause class to record class [lucene]
wardle commented on PR #13261: URL: https://github.com/apache/lucene/pull/13261#issuecomment-2423217820 Hi all. I understand the change to a record class but this does create a breaking change that would be avoided through the addition of deprecated accessors matching the old class ie getQuery and getOccur, which could be later removed in Lucene 11. Obviously other changes have been easier to manage in moving from Lucene 9->10 because methods have been flagged as deprecated in 9 and it has been straightforward to prepare for these changes. It is tricky because for users of Lucene with codebases that might run on either Java 11, or 21, one previously could have a codebase that would run using different Lucene versions, but this change means one has to choose the correct Lucene version AND keep two branches of their code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Change StringHelper from abstract to final. [lucene]
vsop-479 commented on PR #13928: URL: https://github.com/apache/lucene/pull/13928#issuecomment-2422239762 Thanks @uschindler — Do you think it is necessary that just remove the abstract modifier? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Include java21 source folders to gradle source sets [lucene]
javanna closed pull request #13926: Include java21 source folders to gradle source sets URL: https://github.com/apache/lucene/pull/13926 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Include java21 source folders to gradle source sets [lucene]
javanna commented on PR #13926: URL: https://github.com/apache/lucene/pull/13926#issuecomment-2423128918 > (but java21 folders can definitely be folded in). I talked with @ChrisHegarty and he kindly explained that that is not the case. it's complicated :) While we are on java 21, these functionalities require the `--enable-preview` flag, and we can't simply copy all under `src/java` just yet. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Add a Better Binary Quantizer (RaBitQ) format for dense vectors [lucene]
benwtrent commented on PR #13651: URL: https://github.com/apache/lucene/pull/13651#issuecomment-2423186168 I will open a PR against Lucene Util to update it to utilize these formats and show y'all some runs with it soon. But The PR is ready for general review. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Include java21 source folders to gradle source sets [lucene]
javanna commented on PR #13926: URL: https://github.com/apache/lucene/pull/13926#issuecomment-2421592171 I will close this then and figure out a different change for branch_10x and main. Thanks for the help! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Fix StoredFieldsConsumer finish [lucene]
jpountz commented on PR #13927: URL: https://github.com/apache/lucene/pull/13927#issuecomment-2421883503 Ouch, thanks for finding it and fixing it. Can you add a test? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Change StringHelper from abstract to final. [lucene]
vsop-479 commented on PR #13928: URL: https://github.com/apache/lucene/pull/13928#issuecomment-2421959479 I moved the private constructor to the beginning place. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] Performance difference between files getting opened with IOContext.RANDOM vs IOContext.READ during merges [lucene]
uschindler commented on issue #13920: URL: https://github.com/apache/lucene/issues/13920#issuecomment-2421745757 > @uschindler On a high level it makes sense to me. I have a couple of questions so that I understand this better > > > Add a method to Indexinput to change the IOContext (without cloning it), > > I am interested in understanding when its appropriate to clone. Based on the [javadoc](https://github.com/apache/lucene/blob/350de210c3674566293681bb58e801629b5ceee7/lucene/core/src/java/org/apache/lucene/store/IndexInput.java#L22-L39) for IndexInput, for multithreaded use IndexInput must be cloned. My understanding is that merges will have a separate thread. Since the Readers are pooled and the same instance is used - I cloned it when I was trying to [benchmark the solution](https://github.com/shatejas/lucene/commit/4de387288d70b4d8aede45ef3095ae6c1e189331#diff-e0a29611df21f6d32a461e2d24db1585cdf3a8590f08d93b097f0dd84684ebc8R316). Would appreciate if you can give insights on why the indexInput shouldn't be cloned in this case. Cloning a reader wont clone any input which is a fully different thing. Don't care about cloning or not for implementing this issue. The Javadocs and usage pattern (when to clone) is more about stateful use of IndexInputs (they have a read position which can't be updated from multiple threads). If you are about pure random access, you can get a view on it as RandomAccessInput (which is sometimes used for Lucene). In all cases: The cloned inputs use exactly the same MemorySegments behind scenes (in former days it was ByteBuffers, those were also duped for clones). What I wanted to say is: When you change the read advice, it will affect all clones, too. Therefor it is not needed to create a clone of the IndexInput. So basically it simplifies thigs: The CodecReader that is used for merging (and used at same time also for searching) can just be instucted to change the read advice on its backing IndexInput. Thats relatively simple to implenment and won't affect the current behaviour how merging works. > > "revert to normal use" > > In the [benchmarking code](https://github.com/shatejas/lucene/commit/4de387288d70b4d8aede45ef3095ae6c1e189331#diff-e0a29611df21f6d32a461e2d24db1585cdf3a8590f08d93b097f0dd84684ebc8R316), I did not revert it back thinking the reader will be closed and a new reader will be opened with the intended IOContext in this case random. Would you be able to share insights on reverting it back considering there will be new reader. As this is just an advise: When done with merging, just revert back. Opening new readers is too expensive and mostly not useful. In addition, you can't control if searchers using the index in parallel reopen the readers soon. @jpountz already discussed that. This largely depends on how often you reopen IndexReaders. So in general it would be a good idea to revert back to the original state if the IndexReader is still used for longer time. This really depends on the usage pattern. Reverting to normal use is as simple to implement as the initial change. Just change the advice on any of the open IndexInputs, no matter if it is shared by multiple readers and revert back at end. Thats totally uncoupled from the internals of IndexReaders. Uwe -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Include java21 source folders to gradle source sets [lucene]
dweiss commented on PR #13926: URL: https://github.com/apache/lucene/pull/13926#issuecomment-2421819235 (but java21 folders can definitely be folded in). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Include java21 source folders to gradle source sets [lucene]
dweiss commented on PR #13926: URL: https://github.com/apache/lucene/pull/13926#issuecomment-2421818871 Thank you, Luka. I think we may want to keep the build infrastructure for mr-jars - just in case it comes in handy in the future. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Change StringHelper from abstract to final. [lucene]
jpountz commented on PR #13928: URL: https://github.com/apache/lucene/pull/13928#issuecomment-2421863526 I believe that the abstract modifier aimed at preventing instantiation. Can you add a private constructor then? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Change StringHelper from abstract to final. [lucene]
vsop-479 commented on PR #13928: URL: https://github.com/apache/lucene/pull/13928#issuecomment-2421931690 > Can you add a private constructor then? There already is a private constructor in it (line 66). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] Should we avoid allocating a byte[] upfront for binary doc values [lucene]
rmuir commented on issue #13929: URL: https://github.com/apache/lucene/issues/13929#issuecomment-2422029281 I don't think we should optimize for abusive cases that are storing entire novels in this structure. We should be optimized for real use-cases that use a couple bytes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[PR] Use growNoCopy when copying bytes in BytesRefBuilder [lucene]
iverase opened a new pull request, #13930: URL: https://github.com/apache/lucene/pull/13930 I noticed in BytesRefBuilder that we have growNoCopy method, still when calling the methods #copyBytes (reseting the contents on the buffer) we are calling grow. It seems more logical to use in that case growNoCopy so this is what this commit is proposing. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Change StringHelper from abstract to final. [lucene]
uschindler commented on PR #13928: URL: https://github.com/apache/lucene/pull/13928#issuecomment-2422157253 I am not sure if this change is needed at all. There are multiple patterns to make static only classes. The most important one is to add a private ctor. The final or not doesn't really matter. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
