Re: [PR] upgrade commons codec from 1.13.0 to 1.16.0 [lucene]
rmuir closed pull request #13269: upgrade commons codec from 1.13.0 to 1.16.0 URL: https://github.com/apache/lucene/pull/13269 -- 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] upgrade commons codec from 1.13.0 to 1.16.0 [lucene]
rmuir commented on PR #13269: URL: https://github.com/apache/lucene/pull/13269#issuecomment-2868962207 outdated PR: we're now on commons-codec 1.18.0 with update PRs assisted with dependabot -- 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] update commons-compress from 1.19 to 1.21 [lucene]
rmuir closed pull request #13270: update commons-compress from 1.19 to 1.21 URL: https://github.com/apache/lucene/pull/13270 -- 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] update commons-compress from 1.19 to 1.21 [lucene]
rmuir commented on PR #13270: URL: https://github.com/apache/lucene/pull/13270#issuecomment-2868962747 outdated PR: we're now on commons-compress 1.27.1 with updates assisted by dependabot -- 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] removing constructor with deprecated attribute 'onlyLongestMatch [lucene]
rmuir commented on PR #14356: URL: https://github.com/apache/lucene/pull/14356#issuecomment-2868997493 Thank you @renatoh ! -- 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] removing constructor with deprecated attribute 'onlyLongestMatch [lucene]
rmuir merged PR #14356: URL: https://github.com/apache/lucene/pull/14356 -- 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] Catch and re-throw Throwable rather than using a success boolean [lucene]
rmuir commented on PR #14633: URL: https://github.com/apache/lucene/pull/14633#issuecomment-2869000472 > > I thought it did not work with multi-catch, but that it works here. Of course you could make a more horrible hack, but some people don't like this in the Lucene community (its known as sneaky rethrow). But what if the horrible hack (sneakythrow) could be contained to just be inside these utility methods (IOUtils), to simplify exception handling elsewhere? IMO this would be worth it, even if it saves just one line at these call sites. Historically the exception handling code has been problematic (easy to leak files or mask important information, accidentally suppress the wrong thing, etc etc)... Maybe we should look into it as a followup? -- 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] Relax Lucene Index Upgrade Policy to Allow Safe Upgrades Across Multiple Major Versions [lucene]
vigyasharma commented on issue #13797: URL: https://github.com/apache/lucene/issues/13797#issuecomment-2869271879 Thanks for the example Mark, that was helpful. I think the proposal makes sense. It makes upgrades across versions easier without adding significant backward compatibility overhead. I'm not sure I fully grok Adrien's concerns. It seems to me that this change doesn't really _increase_ backward compatibility of already written data. We can bump up the `MIN_SUPPORTED_MAJOR_VERSION` whenever breaking changes are made, effectively only keeping compatibility with the last format change. Users will still need to reindex when they jump multiple incompatible versions. We just don't force a reindex when it's not needed. Am I missing something? -- 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] Expressions: Avoid creating a dynamic constant with BSM if MethodHandle descriptor can be used [lucene]
uschindler closed pull request #14642: Expressions: Avoid creating a dynamic constant with BSM if MethodHandle descriptor can be used URL: https://github.com/apache/lucene/pull/14642 -- 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] Expressions: Avoid creating a dynamic constant with BSM if MethodHandle descriptor can be used [lucene]
uschindler commented on PR #14642: URL: https://github.com/apache/lucene/pull/14642#issuecomment-2869223919 I am not really happy with that PR because it adds complexity for nonsense: The improvements are not really there because we move the MethodHandle access checks and cracking to the compiler while with the BSM it happens at linking time. When we create the expression we create and link anyways, so it is not a big difference. One can only say that we don't use a MethodHandle at all if the call is direct, but this is no longer relevant (it was in Java 7 / Java 8). So I'd like to stay on safe side and close this. The PR can be used for others to get further inspiration - as playground. -- 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] Expressions: Avoid creating a dynamic constant with BSM if MethodHandle descriptor can be used [lucene]
uschindler commented on PR #14642: URL: https://github.com/apache/lucene/pull/14642#issuecomment-2869229169 I just added the improved test (with a really private method/class) to main: 04126613864 -- 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] Expressions: Avoid creating a dynamic constant with BSM if MethodHandle descriptor can be used [lucene]
uschindler closed pull request #14642: Expressions: Avoid creating a dynamic constant with BSM if MethodHandle descriptor can be used URL: https://github.com/apache/lucene/pull/14642 -- 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
[I] Segment count (merging) can impact recall on KNN ParentJoin queries [lucene]
vigyasharma opened a new issue, #14643:
URL: https://github.com/apache/lucene/issues/14643
I've been running benchmarks on the KNN parent-join query to get comparison
numbers for multi-vectors (https://github.com/apache/lucene/pull/14173). I see
a pretty notable difference in recall when merging was disabled on the writer.
I would've expected latency to be somewhat impacted (although the impact here
seems too high), but not recall. Creating an issue to dig more into this.
Setup
1. Both lucene and luceneutil jar are on `main` branch
2. To disable merges, I configured the writer's merge policy to
`NoMergePolicy.INSTANCE`. So while we still configure a
`ConcurrentMergeScheduler`, the merge policy does not find any merges,
effectively disabling merging.
More specifically, I added the following line to `KnnIndexer.java`:
```java
iwc.setMergePolicy(NoMergePolicy.INSTANCE);
```
3. There is no other change b/w the two setups compared here.
Benchmark Results
```ruby
# Parent Join Queries
# merging enabled
recall latency(ms)nDoc topK fanout maxConn beamWidth quantized
index(s) index_docs/s num_segments index_size(MB) vec_disk(MB) vec_RAM(MB)
indexType
0.2284.697 50 100 50 64250 no
113.17 4418.09 7 1473.92 1464.844 1464.844
HNSW
0.1793.043 100 100 50 64250 no
244.78 4085.27 5 2948.15 2929.688 2929.688
HNSW
0.2023.735 200 100 50 64250 no
469.05 4263.91 9 5896.90 5859.375 5859.375
HNSW
# merges disabled: note num_segments value
recall latency(ms) nDoc topK fanout maxConn beamWidth quantized
index(s) index_docs/s num_segments index_size(MB) vec_disk(MB) vec_RAM(MB)
indexType
0.378 13.976 50 100 50 64250 no
107.52 4650.4316 1473.82 1464.844 1464.844
HNSW
0.415 21.928 100 100 50 64250 no
225.22 4440.1232 2947.82 2929.688 2929.688
HNSW
0.466 33.751 200 100 50 64250 no
478.83 4176.8363 5896.20 5859.375 5859.375
HNSW
```
---
This doesn't look like a problem with regular KNN vector queries, only
appears with parent-join query benchmarks.
```ruby
# Regular KNNFloatVectorQuery Benchmarks
# merging enabled
recall latency(ms)nDoc topK fanout maxConn beamWidth quantized
index(s) index_docs/s num_segments index_size(MB) vec_disk(MB) vec_RAM(MB)
indexType
0.969 23.109 50 100 50 64250 no
394.34 1267.93 8 1501.47 1464.844 1464.844
HNSW
0.916 11.001 100 100 50 64250 no
1869.89534.79 3 3017.29 2929.688 2929.688
HNSW
0.951 30.394 200 100 50 64250 no
2756.49725.5610 6027.67 5859.375 5859.375
HNSW
# merging disabled: : note num_segments value
recall latency(ms)nDoc topK fanout maxConn beamWidth quantized
index(s) index_docs/s num_segments index_size(MB) vec_disk(MB) vec_RAM(MB)
indexType
0.705 51.087 50 100 50 64250 no
95.62 5229.1489 1489.43 1464.844 1464.844
HNSW
0.960 90.863 100 100 50 64250 no
192.26 5201.37 175 2980.16 2929.688 2929.688
HNSW
0.971 178.730 200 100 50 64250 no
396.67 5042.00 346 5962.90 5859.375 5859.375
HNSW
```
Recall and latency with merges disabled is comparable if I increase
`setRAMBufferSizeMB` for the writer and create fewer segments.
--
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.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] Relax Lucene Index Upgrade Policy to Allow Safe Upgrades Across Multiple Major Versions [lucene]
rmuir commented on issue #13797: URL: https://github.com/apache/lucene/issues/13797#issuecomment-2869305562 I think there may be confusion around: 1. minimum created version <-- reflects lucene version that first created the index 2. minimum version of any segment <-- reflects what actual backwards compat code we need to support. The first one here, we can be lazy about and only bump when certain rarer changes are made (such as lossy parts around norms, maybe corruption bugs). Today we "bump it" implicitly even if there isn't a good reason. I think the changes that require this are rare, but we do need to retain the facility to make such changes. If we are lazy about the minimum created version, and only bump it when we need to, users can merge segments, rather than reindex, to get to the latest version in most cases. And it doesn't require additional costs such as dragging extra backwards codecs around. -- 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] apache jenkins: Failed to save the JUnit test result [lucene]
dweiss commented on issue #14617: URL: https://github.com/apache/lucene/issues/14617#issuecomment-2869139385 Cannot be reproduced and happens only occasionally though. Strange. -- 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] Support adaptive refresh in Searcher Managers. [lucene]
vigyasharma commented on code in PR #14443:
URL: https://github.com/apache/lucene/pull/14443#discussion_r2083301651
##
lucene/core/src/java/org/apache/lucene/search/RefreshCommitSupplier.java:
##
@@ -0,0 +1,39 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.search;
+
+import java.io.IOException;
+import org.apache.lucene.index.DirectoryReader;
+import org.apache.lucene.index.IndexCommit;
+
+/**
+ * Expert: Interface to supply commit for searcher refresh.
+ *
+ * @lucene.experimental
+ */
+public interface RefreshCommitSupplier {
Review Comment:
I went through original discussions in
[LUCENE-3761](https://issues.apache.org/jira/browse/LUCENE-3761) where
SearcherManager was added.. The choice to make it final seems to have been from
the beginning, I didn't find any discussion explicitly about this.
Overriding this class safely does require a sound understanding of the
`ReferenceManager` base class which has threading/synchronization code. I feel
it's safer to leave this class as final, in line with the original intent.
--
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] Expressions: Avoid creating a dynamic constant with BSM if MethodHandle descriptor can be used [lucene]
uschindler opened a new pull request, #14642: URL: https://github.com/apache/lucene/pull/14642 This is an optimization to avoid using a bootstrap when creting the MethodHandle constant. This won't be backported as it's not easy possible to do with ASM. Basically, if the `MethodHandle` in our function list is a direct one and reachable from system classloader, we push a reference to it directly to stack. This is the common case for static (named) functions and all methods in the default functions. The classfile API makes it easy, because if a `MethodHandle` is direct and reachable by system classloader, it returns a non-empty `describeConstable()`. This won't improve performance for the execution (as it is a constant before and after), but it should improve startup time. -- 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] Multireader Support in Searcher Manager [lucene]
vigyasharma commented on PR #13976: URL: https://github.com/apache/lucene/pull/13976#issuecomment-2869263962 Bumping up since the PR went stale. Should I finalize the changes in #14486 ? -- 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] TopFieldCollector mistakenly assumes that all leaves share the same index sort [lucene]
jpountz commented on issue #14399: URL: https://github.com/apache/lucene/issues/14399#issuecomment-2869526058 I don't see an obvious solution either. My preference would be to remove the cache and make this decision on a per-segment basis, but this would require moving some methods around, e.g. `Comparator#disableSkipping` -> `LeafComparator#disableSkipping`. -- 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
[I] Fix bad interaction between optimistic query and query timeout [lucene]
msokolov opened a new issue, #14639: URL: https://github.com/apache/lucene/issues/14639 ### Description org.apache.lucene.search.TestSeededKnnFloatVectorQuery.testTimeout test failures demonstrate that when we early terminate (timeout) query execution, the optimistic strategy still tries to collect more hits, but fails because the timeout prevents it, and can then return 0 hits. > NOTE: reproduce with: gradlew test --tests TestSeededKnnFloatVectorQuery.testTimeout -Dtests.seed=FBB7AD01C7763E0 -Dtests.multiplier=3 -Dtests.nightly=true -Dtests.locale=dz-Tibt-BT -Dtests.timezone=Canada/Saskatchewan -Dtests.asserts=true -Dtests.file.encoding=UTF-8 ### Version and environment details _No response_ -- 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.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] Don't perform additional KNN querying after timeout, fixes #14639 [lucene]
msokolov opened a new pull request, #14640: URL: https://github.com/apache/lucene/pull/14640 This fixes the test failure and seems correct to me. My only question is whether `TotalHits.Relation.EQUAL_TO` is a reliable indicator that we did not `earlyTerminate()` -- 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] Expressions: Avoid creating a dynamic constant with BSM if MethodHandle descriptor can be used [lucene]
uschindler commented on PR #14642: URL: https://github.com/apache/lucene/pull/14642#issuecomment-2869217876 This code is more complex, but does the right thing. Only if the MethodHandle is direct and works witho our own lookup, we translate the method call to a invokestatic directly. This is basically similar to the code we had in the very first version of the Expressions module, but this one can do type checking better and uses the mechanisms of classfile library to generate the opcodes. -- 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] Support adaptive refresh in Searcher Managers. [lucene]
vigyasharma commented on PR #14443: URL: https://github.com/apache/lucene/pull/14443#issuecomment-2869220781 Thanks for the review, @mikemccand . I've updated the PR with changes. I did a rebase on `main` since it had moved quite a bit. There was no conflict for the files here, but since rebase rewrote commit history, you may not be able to see just the changes since your last review. Apologies for the inconvenience, hopefully the PR is small enough to manage. -- 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] apache jenkins: Failed to save the JUnit test result [lucene]
rmuir commented on issue #14617: URL: https://github.com/apache/lucene/issues/14617#issuecomment-2869067023 > Caused by: [com.thoughtworks.xstream.io](http://com.thoughtworks.xstream.io/).StreamException: Invalid character 0xd83a in XML stream probably caused by an unpaired surrogate in the test output? -- 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] Remove deprecations in expressions [lucene]
uschindler opened a new pull request, #14641: URL: https://github.com/apache/lucene/pull/14641 nothing to add -- 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] Remove deprecations in expressions [lucene]
uschindler merged PR #14641: URL: https://github.com/apache/lucene/pull/14641 -- 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] Support adaptive refresh in Searcher Managers. [lucene]
vigyasharma commented on code in PR #14443:
URL: https://github.com/apache/lucene/pull/14443#discussion_r2083302934
##
lucene/core/src/java/org/apache/lucene/search/SearcherManager.java:
##
@@ -131,17 +133,32 @@ public SearcherManager(DirectoryReader reader,
SearcherFactory searcherFactory)
this.current = getSearcher(searcherFactory, reader, null);
}
+ /** Set supplier for selecting commits to refresh on */
+ public void setRefreshCommitSupplier(RefreshCommitSupplier
refreshCommitSupplier) {
+this.refreshCommitSupplier = refreshCommitSupplier;
+ }
+
@Override
protected void decRef(IndexSearcher reference) throws IOException {
reference.getIndexReader().decRef();
}
+ /** Return index commit generation for current searcher */
+ public long getSearcherCommitGeneration() throws IOException {
Review Comment:
Good point. I was exposing this as a hook for callers to monitor the
searcher commit generation at a point in time, but it could be confusing. It's
also just a utility functions that consumers can define outside of this class.
Will remove 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] Expressions: Avoid creating a dynamic constant with BSM if MethodHandle descriptor can be used [lucene]
uschindler commented on PR #14642: URL: https://github.com/apache/lucene/pull/14642#issuecomment-2869214522 There is a problem with that commit, because it does not work with private lookup. Theres an additional check needed. The problem is that `describeConstable()` uses a full-trusted lookup and not the one of our code. I have another branch here which does this correct and uses a direct static call instead of a method handle, if possible. This one here looked more elegant, but I forgot to port my 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: [I] Relax Lucene Index Upgrade Policy to Allow Safe Upgrades Across Multiple Major Versions [lucene]
markrmiller commented on issue #13797: URL: https://github.com/apache/lucene/issues/13797#issuecomment-2869364967 Yeah, that would be preferable to a bunch of versioned code that essentially all reads the same format. I suppose I was thinking of using the config for "what is the minimum version I can read" over "what version was this written with" because my immediate thought was you are lying about the version with the latter - but you would of course just consider it the index format version it was written with rather than the actual Lucene version. -- 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
