Deepika0510 commented on PR #12345:
URL: https://github.com/apache/lucene/pull/12345#issuecomment-1784082772
However, to get that `TimeoutLeafReader` in use, we would need to go through
the `ReaderContext` class route(?). In a way we would need some mechanism in
`ReaderClass` to know if tim
gf2121 opened a new pull request, #12733:
URL: https://github.com/apache/lucene/pull/12733
(no comment)
--
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-ma
mikemccand commented on PR #12345:
URL: https://github.com/apache/lucene/pull/12345#issuecomment-1784151630
Hmm I'm confused: why would you need to get to the `TimeoutLeafReader`?
Don't you create this timeout reader, passing the timeout to it (which will
apply to all queries) and then you
mikemccand commented on issue #12576:
URL: https://github.com/apache/lucene/issues/12576#issuecomment-1784152872
Could we make the collection dynamic? Collect into a sparse structure at
first, and if it gets too big, switch to dense.
--
This is an automated message from the Apache Git Se
mikemccand commented on PR #12506:
URL: https://github.com/apache/lucene/pull/12506#issuecomment-1784153400
+1 to move to `oal.index`, and make it package private if possible?
`ByteSlicePool` name sounds good to me :) Naming is the hardest part!
--
This is an automated message from the
mikemccand commented on code in PR #12506:
URL: https://github.com/apache/lucene/pull/12506#discussion_r1375466035
##
lucene/core/src/java/org/apache/lucene/util/ByteBlockPool.java:
##
@@ -129,21 +143,22 @@ public ByteBlockPool(Allocator allocator) {
}
/**
- * Resets t
mikemccand commented on PR #12427:
URL: https://github.com/apache/lucene/pull/12427#issuecomment-1784156071
> Below are the results(looks all good to me). Let me know what do you
think? Thanks!
+1 -- looks like just noise to me.
--
This is an automated message from the Apache Git S
stefanvodita opened a new issue, #12734:
URL: https://github.com/apache/lucene/issues/12734
### Description
`ByteBlockPool.reset` can fill the buffers we're recycling with zeros.
1. Do we need the buffers to be filled with zeros? Is there some implicit
assumption if we were to reus
stefanvodita commented on code in PR #12506:
URL: https://github.com/apache/lucene/pull/12506#discussion_r1375520679
##
lucene/core/src/java/org/apache/lucene/util/ByteBlockPool.java:
##
@@ -129,21 +143,22 @@ public ByteBlockPool(Allocator allocator) {
}
/**
- * Resets
stefanvodita commented on PR #12506:
URL: https://github.com/apache/lucene/pull/12506#issuecomment-1784239004
Thanks @mikemccand! I just pushed a commit that does that move.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and
dungba88 commented on issue #12714:
URL: https://github.com/apache/lucene/issues/12714#issuecomment-1784418885
If we are to move to value-based LRU cache and no longer fall back to
reading FST when items are not in the map, I'm wondering why wouldn't we just
use LinkedHashMap (or any doubly
11 matches
Mail list logo
