[GitHub] [lucene-solr] dweiss commented on pull request #1816: LUCENE-9497: Integerate Error Prone ( Static Analysis Tool ) during compilation
dweiss commented on pull request #1816: URL: https://github.com/apache/lucene-solr/pull/1816#issuecomment-686928388 I'll take a look later as to why this doesn't build. The problem with individual suppressions remains though - you can go by category but I think there will be still places where false positives need to be marked as such (so that they don't generate a warning). We will need a mechanism to individually flag such places as "valid use" - this applies to reference comparisons in particular (which may be a bug or may be intentional, depending on the intention of the programmer). 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. 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
[GitHub] [lucene-solr] dweiss commented on a change in pull request #1816: LUCENE-9497: Integerate Error Prone ( Static Analysis Tool ) during compilation
dweiss commented on a change in pull request #1816:
URL: https://github.com/apache/lucene-solr/pull/1816#discussion_r483402573
##
File path: build.gradle
##
@@ -127,6 +128,9 @@ apply from: file('gradle/ide/intellij-idea.gradle')
apply from: file('gradle/ide/eclipse.gradle')
// Validation tasks
+apply from: file('gradle/hacks/findbugs.gradle')
Review comment:
I think the problem may be in clashing JARs - errorprone annotations are
imported in a different place of the build (Erick worked on this), without any
static analysis. I can take a look but later.
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.
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
[GitHub] [lucene-solr] dweiss commented on a change in pull request #1816: LUCENE-9497: Integerate Error Prone ( Static Analysis Tool ) during compilation
dweiss commented on a change in pull request #1816:
URL: https://github.com/apache/lucene-solr/pull/1816#discussion_r483402784
##
File path: gradle/validation/error-prone.gradle
##
@@ -0,0 +1,146 @@
+/*
+ * 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.
+ */
+
+allprojects { prj ->
+plugins.withId("java", {
+prj.apply plugin: 'net.ltgt.errorprone'
+plugins.withType(JavaPlugin) {
Review comment:
you only need one - plugins.withId or plugins.withType. It's the same
thing here.
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.
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
[jira] [Commented] (SOLR-13652) Remove update from initParams in example solrconfig files that only mention "df"
[ https://issues.apache.org/jira/browse/SOLR-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190551#comment-17190551 ] David Smiley commented on SOLR-13652: - I'd think your SIP-10 should have this "learning config" https://cwiki.apache.org/confluence/display/SOLR/SIP-10+Improve+Getting+Started+experience (I'm just getting to read this now) > Remove update from initParams in example solrconfig files that only mention > "df" > > > Key: SOLR-13652 > URL: https://issues.apache.org/jira/browse/SOLR-13652 > Project: Solr > Issue Type: Improvement > Components: examples >Reporter: Erick Erickson >Priority: Minor > Labels: easyfix, newbie > > At least some of the solrconfig files we ship have this entry: > path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse,update"> > > text > > > > which has lead at least one user to wonder if there's some kind of automatic > way to have the df field populated for updates. I don't even know how you'd > send an update that didn't have a specific field. We should remove the > "update/**". -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14802) Sorting by min of two geodist functions
[
https://issues.apache.org/jira/browse/SOLR-14802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-14802:
Component/s: (was: query)
spatial
Affects Version/s: (was: 8.6.2)
Issue Type: Improvement (was: Bug)
Priority: Major (was: Minor)
> Sorting by min of two geodist functions
> ---
>
> Key: SOLR-14802
> URL: https://issues.apache.org/jira/browse/SOLR-14802
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: spatial
>Reporter: Shaun Storey
>Priority: Major
>
> Previously using geo field with type LatLonType you could implement a query
> like
> {code:java}
> /select?q=*:*=ID={!geofilt}=50=53.4721936,-2.24703=MAIN_LOCATION=min(geodist(),
> geodist(ALT_LOCATION,53.4721936,-2.24703)) asc{code}
> to sort results on minium distance from multiple different locations. Moving
> the fields to advised LatLonPointSpatialField gives
> "geodist() does not support field names in its arguments when stated fields
> are solr.LatLonPointSpatialField spatial type, requires sfield param instead"
> This has been reviewed before SOLR-11601 but not for my actual actual
> use-case so it seems the choice was to just change the error message rather
> than to implement the previous functionality. Can this be re-reviewed or let
> me know if there is another way to achieve the same result.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14802) Sorting by min of two geodist functions
[
https://issues.apache.org/jira/browse/SOLR-14802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190535#comment-17190535
]
David Smiley commented on SOLR-14802:
-
I think you're right; this ought to be supported and isn't possible with LLPSF.
The trouble is
org.apache.solr.search.function.distance.GeoDistValueSourceParser is so
complicated because of all the scenarios it supports, and mis-aligned
abstractions. I'm too busy with other things but I'd be happy to review &
commit a PR.
The test would be TestSolr4Spatial2, maybe using existing schema.
> Sorting by min of two geodist functions
> ---
>
> Key: SOLR-14802
> URL: https://issues.apache.org/jira/browse/SOLR-14802
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query
>Affects Versions: 8.6.2
>Reporter: Shaun Storey
>Priority: Minor
>
> Previously using geo field with type LatLonType you could implement a query
> like
> {code:java}
> /select?q=*:*=ID={!geofilt}=50=53.4721936,-2.24703=MAIN_LOCATION=min(geodist(),
> geodist(ALT_LOCATION,53.4721936,-2.24703)) asc{code}
> to sort results on minium distance from multiple different locations. Moving
> the fields to advised LatLonPointSpatialField gives
> "geodist() does not support field names in its arguments when stated fields
> are solr.LatLonPointSpatialField spatial type, requires sfield param instead"
> This has been reviewed before SOLR-11601 but not for my actual actual
> use-case so it seems the choice was to just change the error message rather
> than to implement the previous functionality. Can this be re-reviewed or let
> me know if there is another way to achieve the same result.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12298) Index Full nested document Hierarchy For Queries (umbrella issue)
[ https://issues.apache.org/jira/browse/SOLR-12298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190530#comment-17190530 ] David Smiley commented on SOLR-12298: - > Question on this work: if a child document is stored in a field "foobar", > must that field be present in schema? No, it should not. > if one document has one child and another two with the same name, the > resulting Json (or SolrJ!) structure will be inconsistent and cause parsing > issues. Hmmm; that could be a limitation. Though a reasonable one I think always use an array if there may be more than one for that named child relation. > Index Full nested document Hierarchy For Queries (umbrella issue) > - > > Key: SOLR-12298 > URL: https://issues.apache.org/jira/browse/SOLR-12298 > Project: Solr > Issue Type: Improvement >Reporter: mosh >Assignee: David Smiley >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Solr ought to have the ability to index deeply nested objects, while storing > the original document hierarchy. > Currently the client has to index the child document's full path and level > to manually reconstruct the original document structure, since the children > are flattened and returned in the reserved "__childDocuments__" key. > Ideally you could index a nested document, having Solr transparently add the > required fields while providing a document transformer to rebuild the > original document's hierarchy. > > This issue is an umbrella issue for the particular tasks that will make it > all happen – either subtasks or issue linking. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch updated SOLR-14829:
-
Component/s: examples
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, examples
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component}} package?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on a change in pull request #1827: SOLR-14792: Remove VelocityResponseWriter
chatman commented on a change in pull request #1827: URL: https://github.com/apache/lucene-solr/pull/1827#discussion_r483335351 ## File path: solr/example/files/conf/lang/stemdict_nl.txt ## @@ -1,6 +0,0 @@ -# Set of overrides for the dutch stemmer -# TODO: load this as a resource from the analyzer and sync it in build.xml -fiets fiets Review comment: Are these stemdict files velocity specific? 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. 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
[GitHub] [lucene-solr] erikhatcher opened a new pull request #1827: SOLR-14792: Remove VelocityResponseWriter
erikhatcher opened a new pull request #1827: URL: https://github.com/apache/lucene-solr/pull/1827 # Description Remove VelocityResponseWriter and its references and usages. # Solution Removed contrib/velocity and all related uses. # Tests Will ensured all Solr tests, precommit, and smoketesters pass. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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. 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
[GitHub] [lucene-solr] noblepaul commented on pull request #1684: SOLR-14613: strongly typed placement plugin interface and implementation
noblepaul commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-686839493 I see a consistent theme here. We are always combing through comments with a lens to see if the tone is correct, if somebody uses the correct case in typing or if the feedback is warm and fuzzy and caring. While it's a good in general, we miss the whole point of a review and feedback. The purpose is to ensure that the feature/change is - correct - performant/efficient - user-friendly The person who is doing a review is already doing a great favour by spending time to do a review. Let's be aware that the PR owner is probably paid to do that work and the reviewer is not. So, I have deep respect for anyone who reviews my PRs and gives suggestions (@dsmiley ) you are one of the devs who review a lot of my PRs and I'm grateful for what you do and you have the nicest demeanour while doing it. There are others like Uwe or Muir, who occasionally gives me a feedback without being very kind. I'm grateful to them because they have spent time to go through my PR using their personal time. They also bring a wealth of expertise that I probably don't have. The fact is, all of has the same objective: to make the product better. We are all not paid by the same employer or some of us may not even be paid at all. Let's focus more on the content and less on the form. cheers. 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. 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
[jira] [Created] (SOLR-14830) Synchronizing reference and master branches
Ishan Chattopadhyaya created SOLR-14830: --- Summary: Synchronizing reference and master branches Key: SOLR-14830 URL: https://issues.apache.org/jira/browse/SOLR-14830 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Ishan Chattopadhyaya Assignee: Ishan Chattopadhyaya Reference branch is behind master by quite a few commits. I plan to bring those changes back one by one to reference branch first, so that we can later bring the reference branch into master. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe commented on pull request #1816: LUCENE-9497: Integerate Error Prone ( Static Analysis Tool ) during compilation
tflobbe commented on pull request #1816: URL: https://github.com/apache/lucene-solr/pull/1816#issuecomment-686831857 Hey, just in case you haven't seen it, there is a related email in the dev list about static analysis using a Github App. See http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3CCAF_Lw0dt5jpLqyO3fwevjxbpduY_V6%2BWWyudBjkN4ZS5OHWjDA%40mail.gmail.com%3E 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. 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
[GitHub] [lucene-solr] vthacker commented on a change in pull request #1816: LUCENE-9497: Integerate Error Prone ( Static Analysis Tool ) during compilation
vthacker commented on a change in pull request #1816:
URL: https://github.com/apache/lucene-solr/pull/1816#discussion_r483318383
##
File path: build.gradle
##
@@ -127,6 +128,9 @@ apply from: file('gradle/ide/intellij-idea.gradle')
apply from: file('gradle/ide/eclipse.gradle')
// Validation tasks
+apply from: file('gradle/hacks/findbugs.gradle')
Review comment:
Hmm! Locally this made precommit happy
But
https://github.com/apache/lucene-solr/pull/1816/checks?check_run_id=1069510797
still is running into the same error 樂
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.
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
[jira] [Commented] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190430#comment-17190430
]
Ishan Chattopadhyaya commented on SOLR-14829:
-
Thanks [~jbaiter]. I'll take a look soon (unless Cassandra beats me to it).
bq. The names facet_module / FacetModule are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
bq.Why is the FacetModule class located in the search.facet package while
every single other search component included in the core is located in the
handler.component package?
These are very important concerns and something we need to tackle going forward
for better consistency. I can offer historical perspective on why it is this
way, but I think we should seriously think of streamlining this going forward
-- there is no reason why this inconsistency should persist. Would you like to
open a new JIRA issue on those concerns so that I can invite a wider discussion
around it from some of the committers who are in the best position to resolve
this (e.g. [~ctargett], [~hossman], [~yonik], et. al.)?
Just want to share your Twitter thread here, because I believe it is a very
illustrative example of where Solr needs improvement:
https://twitter.com/jbaiter_/status/1301518376246874116. FYI, [~arafalov] is
leading an effort for improving our examples. We have discussed some other
aspects of getting started documentation here:
https://issues.apache.org/jira/browse/SOLR-14726.
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component}} package?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya reassigned SOLR-14829:
---
Assignee: Ishan Chattopadhyaya
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component}} package?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman edited a comment on pull request #1684: SOLR-14613: strongly typed placement plugin interface and implementation
chatman edited a comment on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-686808345 > Wow. I'm not even sure that would be polite to say to a junior engineer (that may be presumed to not know concurrency) than a very senior one here. I don't understand your ideas of politeness, but if someone offered me help/advice in writing code in any area, no matter how "senior" or "junior" I am or he/she who is offering help is, I would be grateful. > I think you know full well that Ilan doesn't need your help writing concurrent code. Yet why would you offer help? I think this is a false offer (you know Ilan will not take you up on this); -- it's a pejorative offer that belittles who you offer it to as being beneath the abilities of your own. I wonder why you would say that? Maybe you don't believe it's worth it to make it easier for plugin writers at the expense of Solr having such concurrent code (i.e. where does the concurrency/complexity go) -- fare, but then just say that without belittling anyone's intelligence. Ilan is a reasonably new committer, so I am not fully aware of his background or his "seniority". I just offered help in writing concurrent code that I consider clean. But, now you have made couple of assertions that I will keep in mind: "Ilan doesn't need your help writing concurrent code" "Ilan will not take you up on this" > "pejorative offer that belittles who you offer it" > "as being beneath the abilities of your own" > "belittling [..] intelligence" Even though I won't stop you representing/misrepresenting Ilan as you have done above (by claiming he is not open to help in this area), at least please don't put misrepresent me with the motives behind my words. Just to clarify: I thought Ilan was inclined towards having tons of classes (and thereby "polluting solr-core") because he wanted to avoid having the plugins make concurrent requests, since I thought he perceived doing so as complicated. I am of course not doubting anyone's ability to write concurrent code (and of course not "belittling anyone's intelligence"), but I wanted to offer suggestions on doing so *cleanly* (without complications). 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. 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
[GitHub] [lucene-solr] chatman commented on pull request #1684: SOLR-14613: strongly typed placement plugin interface and implementation
chatman commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-686808345 > Wow. I'm not even sure that would be polite to say to a junior engineer (that may be presumed to not know concurrency) than a very senior one here. I think you know full well that Ilan doesn't need your help writing concurrent code. Yet why would you offer help? I think this is a false offer (you know Ilan will not take you up on this); -- it's a pejorative offer that belittles who you offer it to as being beneath the abilities of your own. I wonder why you would say that? Maybe you don't believe it's worth it to make it easier for plugin writers at the expense of Solr having such concurrent code (i.e. where does the concurrency/complexity go) -- fare, but then just say that without belittling anyone's intelligence. Ilan is a reasonably new committer, so I am not fully aware of his background or his "seniority". I just offered help in writing concurrent code that I consider clean. But, now you have made couple of assertions that I will keep in mind: "Ilan doesn't need your help writing concurrent code" "Ilan will not take you up on this" > "pejorative offer that belittles who you offer it" > "as being beneath the abilities of your own" > "belittling [..] intelligence" Even though I won't stop you representing/misrepresenting Ilan as you have done above (by claiming he is not open to help in this area), at least please don't put misrepresent me with the motives behind my words. Just to clarify: I thought Ilan was inclined towards having tons of classes (and thereby "polluting solr-core") because he wanted to avoid having the plugins make concurrent requests, since I thought he perceived doing so as complicated. I am of course not doubting anyone's ability to write concurrent code (and of course not "belittling anyone's intelligence"), but I wanted to offer suggestions on doing so *cleanly* (without complications). 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. 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
[jira] [Updated] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Baiter updated SOLR-14829:
---
Description:
In the reference guide, the list of search components that are enabled by
default is missing the {{facet_module}} and {{terms}} components. The terms
component is instead listed under "other useful components", while the
{{FacetModule}} is never listed anywhere in the documentation, despite it being
neccessary for the JSON Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component}} package?
was:
In the reference guide, the list of search components that are enabled by
default is missing the {{facet_module}} and {{terms}} components. The terms
component is instead listed under "other useful components", while the
{{FacetModule}} is never listed anywhere in the documentation, despite it being
neccessary for the JSON Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component package}}?
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component}} package?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail:
[jira] [Updated] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Baiter updated SOLR-14829:
---
Priority: Minor (was: Major)
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component package}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Baiter updated SOLR-14829:
---
Description:
In the reference guide, the list of search components that are enabled by
default is missing the {{facet_module}} and {{terms}} components. The terms
component is instead listed under "other useful components", while the
{{FacetModule}} is never listed anywhere in the documentation, despite it being
neccessary for the JSON Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component package}}?
was:
The list of search components that are enabled by default is missing the
{{facet_module}} and {{terms}} components. The terms component is instead
listed under "other useful components", while the {{FacetModule}} is never
listed anywhere in the documentation, despite it being neccessary for the JSON
Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component package}}?
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Priority: Major
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component package}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For
[jira] [Updated] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Baiter updated SOLR-14829:
---
Description:
The list of search components that are enabled by default is missing the
{{facet_module}} and {{terms}} components. The terms component is instead
listed under "other useful components", while the {{FacetModule}} is never
listed anywhere in the documentation, despite it being neccessary for the JSON
Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component package}}?
was:
The list of search components that are enabled by default is missing the
{{facet_module}} and {{terms }}components. The terms component is instead
listed under "other useful components", while the {{FacetModule}} is never
listed anywhere in the documentation, despite it being neccessary for the JSON
Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component package}}?
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Priority: Major
> Attachments: SOLR-14829.patch
>
>
> The list of search components that are enabled by default is missing the
> {{facet_module}} and {{terms}} components. The terms component is instead
> listed under "other useful components", while the {{FacetModule}} is never
> listed anywhere in the documentation, despite it being neccessary for the
> JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component package}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail:
[jira] [Updated] (SOLR-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Baiter updated SOLR-14829:
---
Attachment: SOLR-14829.patch
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Priority: Major
> Attachments: SOLR-14829.patch
>
>
> The list of search components that are enabled by default is missing the
> {{facet_module}} and {{terms }}components. The terms component is instead
> listed under "other useful components", while the {{FacetModule}} is never
> listed anywhere in the documentation, despite it being neccessary for the
> JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component package}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14829) Default components are missing facet_module and terms in documentation
Johannes Baiter created SOLR-14829:
--
Summary: Default components are missing facet_module and terms in
documentation
Key: SOLR-14829
URL: https://issues.apache.org/jira/browse/SOLR-14829
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: documentation
Affects Versions: 8.6.2
Reporter: Johannes Baiter
The list of search components that are enabled by default is missing the
{{facet_module}} and {{terms }}components. The terms component is instead
listed under "other useful components", while the {{FacetModule}} is never
listed anywhere in the documentation, despite it being neccessary for the JSON
Facet API to work.
This is also how I stumbled upon this, I spent hours trying to figure out why
JSON-based faceting was not working with my setup, after taking a glance at the
{{SearchHandler}} source code based on a hunch, it became clear that my custom
list of search components (created based on the list in the reference guide)
was to blame.
A patch for the documentation gap is attached, but I think there are some other
issues with the naming/documentation around the two faceting APIs that may be
worth discussing:
* The names {{facet_module}} / {{FacetModule}} are very misleading, since the
documentation is always talking about the "JSON Facet API", but the term "JSON"
does not appear in the name of the component nor does the component have any
documentation attached that mentions this
* Why is the {{FacetModule}} class located in the {{search.facet}} package
while every single other search component included in the core is located in
the {{handler.component package}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9418) Ordered intervals can give inaccurate hits on interleaved terms
[
https://issues.apache.org/jira/browse/LUCENE-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190420#comment-17190420
]
Brian Coverstone edited comment on LUCENE-9418 at 9/3/20, 10:46 PM:
I believe this may still be an issue in 8.6.0, as I'm finding the last slot can
often have an incorrect record.
I found a workaround, and that is to always select 1 more than needed.
Here is some pseudo code to demonstrate:
{quote}ComplexPhraseQueryParser cpqp = new
ComplexPhraseQueryParser("somefield", analyzer);
Query query = cpqp.parse("somevalue");
pageSize = 10;
pageNum = 1;
requestedRecords = pageSize * pageNum + 1; //+1 workaround
startOffset = (pageNum - 1) * pageSize;
FieldComparatorSource fsc = new FieldComparatorSource() {
aOverride
public FieldComparator newComparator(String fieldname, int
numhits, int sortPos, boolean reversed) {
return new StringValComparatorIgnoreCase(numhits, fieldname);
}
};
Sort sort = new Sort(new SortField("firstname", fsc, false));
IndexSearcher searcher = new IndexSearcher(reader);
TopFieldCollector tfcollector = TopFieldCollector.create(sort,
requestedRecords, Integer.MAX_VALUE);
searcher.search(query, tfcollector);
ScoreDoc[] hits = tfcollector.topDocs(startOffset, pageSize).scoreDocs;
{quote}
At this point "hits" is correct. However, if I remove the "+1" from the
requestedRecords above, the last item in "hits" is often incorrect.
was (Author: brain2000):
I believe this may still be an issue in 8.6.0, as I'm finding the last slot can
often have an incorrect record.
I found a workaround, and that is to always select 1 more than needed.
Here is some pseudo code to demonstrate:
{quote}ComplexPhraseQueryParser cpqp = new
ComplexPhraseQueryParser("somefield", analyzer);
Query query = cpqp.parse("somevalue");
pageSize = 10;
pageNum = 1;
requestedRecords = pageSize * pageNum + 1; //+1 workaround
startOffset = (pageNum - 1) * pageSize;
FieldComparatorSource fsc = new FieldComparatorSource() {
@Override
public FieldComparator newComparator(String fieldname, int
numhits, int sortPos, boolean reversed)
Unknown macro: \{ return new StringValComparatorIgnoreCase(numhits,
fieldname); }
};
Sort sort = new Sort(new SortField("firstname", fsc, false));
IndexSearcher searcher = new IndexSearcher(reader);
TopFieldCollector tfcollector = TopFieldCollector.create(sort,
requestedRecords, Integer.MAX_VALUE);
searcher.search(query, tfcollector);
ScoreDoc[] hits = tfcollector.topDocs(startOffset, pageSize).scoreDocs;
{quote}
At this point "hits" is correct. However, if I remove the "+1" from the
requestedRecords above, the last item in "hits" is often incorrect.
> Ordered intervals can give inaccurate hits on interleaved terms
> ---
>
> Key: LUCENE-9418
> URL: https://issues.apache.org/jira/browse/LUCENE-9418
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Given the text 'A B A C', an ordered interval over 'A B C' will return the
> inaccurate interval [2, 3], due to the way minimization is handled after
> matches are found.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9418) Ordered intervals can give inaccurate hits on interleaved terms
[
https://issues.apache.org/jira/browse/LUCENE-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190420#comment-17190420
]
Brian Coverstone edited comment on LUCENE-9418 at 9/3/20, 10:46 PM:
I believe this may still be an issue in 8.6.0, as I'm finding the last slot can
often have an incorrect record.
I found a workaround, and that is to always select 1 more than needed.
Here is some pseudo code to demonstrate:
{quote}ComplexPhraseQueryParser cpqp = new
ComplexPhraseQueryParser("somefield", analyzer);
Query query = cpqp.parse("somevalue");
pageSize = 10;
pageNum = 1;
requestedRecords = pageSize * pageNum + 1; //+1 workaround
startOffset = (pageNum - 1) * pageSize;
FieldComparatorSource fsc = new FieldComparatorSource() {
@Override
public FieldComparator newComparator(String fieldname, int
numhits, int sortPos, boolean reversed) {
return new StringValComparatorIgnoreCase(numhits, fieldname);
}
};
Sort sort = new Sort(new SortField("firstname", fsc, false));
IndexSearcher searcher = new IndexSearcher(reader);
TopFieldCollector tfcollector = TopFieldCollector.create(sort,
requestedRecords, Integer.MAX_VALUE);
searcher.search(query, tfcollector);
ScoreDoc[] hits = tfcollector.topDocs(startOffset, pageSize).scoreDocs;
{quote}
At this point "hits" is correct. However, if I remove the "+1" from the
requestedRecords above, the last item in "hits" is often incorrect.
was (Author: brain2000):
I believe this may still be an issue in 8.6.0, as I'm finding the last slot can
often have an incorrect record.
I found a workaround, and that is to always select 1 more than needed.
Here is some pseudo code to demonstrate:
{quote}ComplexPhraseQueryParser cpqp = new
ComplexPhraseQueryParser("somefield", analyzer);
Query query = cpqp.parse("somevalue");
pageSize = 10;
pageNum = 1;
requestedRecords = pageSize * pageNum + 1; //+1 workaround
startOffset = (pageNum - 1) * pageSize;
FieldComparatorSource fsc = new FieldComparatorSource() {
aOverride
public FieldComparator newComparator(String fieldname, int
numhits, int sortPos, boolean reversed) {
return new StringValComparatorIgnoreCase(numhits, fieldname);
}
};
Sort sort = new Sort(new SortField("firstname", fsc, false));
IndexSearcher searcher = new IndexSearcher(reader);
TopFieldCollector tfcollector = TopFieldCollector.create(sort,
requestedRecords, Integer.MAX_VALUE);
searcher.search(query, tfcollector);
ScoreDoc[] hits = tfcollector.topDocs(startOffset, pageSize).scoreDocs;
{quote}
At this point "hits" is correct. However, if I remove the "+1" from the
requestedRecords above, the last item in "hits" is often incorrect.
> Ordered intervals can give inaccurate hits on interleaved terms
> ---
>
> Key: LUCENE-9418
> URL: https://issues.apache.org/jira/browse/LUCENE-9418
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Given the text 'A B A C', an ordered interval over 'A B C' will return the
> inaccurate interval [2, 3], due to the way minimization is handled after
> matches are found.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9418) Ordered intervals can give inaccurate hits on interleaved terms
[
https://issues.apache.org/jira/browse/LUCENE-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190420#comment-17190420
]
Brian Coverstone edited comment on LUCENE-9418 at 9/3/20, 10:44 PM:
I believe this may still be an issue in 8.6.0, as I'm finding the last slot can
often have an incorrect record.
I found a workaround, and that is to always select 1 more than needed.
Here is some pseudo code to demonstrate:
{quote}ComplexPhraseQueryParser cpqp = new
ComplexPhraseQueryParser("somefield", analyzer);
Query query = cpqp.parse("somevalue");
pageSize = 10;
pageNum = 1;
requestedRecords = pageSize * pageNum + 1; //+1 workaround
startOffset = (pageNum - 1) * pageSize;
FieldComparatorSource fsc = new FieldComparatorSource() {
@Override
public FieldComparator newComparator(String fieldname, int
numhits, int sortPos, boolean reversed)
{
return new StringValComparatorIgnoreCase(numhits, fieldname);
}
};
Sort sort = new Sort(new SortField("firstname", fsc, false));
IndexSearcher searcher = new IndexSearcher(reader);
TopFieldCollector tfcollector = TopFieldCollector.create(sort,
requestedRecords + 1, Integer.MAX_VALUE);
searcher.search(query, tfcollector);
ScoreDoc[] hits = tfcollector.topDocs(startOffset, pageSize).scoreDocs;
{quote}
At this point "hits" is correct. However, if I remove the "+1" from the
requestedRecords above, the last item in "hits" is often incorrect.
was (Author: brain2000):
I believe this may still be an issue in 8.6.0, as I'm finding the last slot can
often have an incorrect record.
I found a workaround, and that is to always select 1 more than needed.
Here is some pseudo code to demonstrate:
{quote}ComplexPhraseQueryParser cpqp = new
ComplexPhraseQueryParser("somefield", analyzer);
Query query = cpqp.parse("somevalue");
pageSize = 10;
pageNum = 1;
requestedRecords = pageSize * pageNum + 1; //+1 workaround
startOffset = (pageNum - 1) * pageSize;
FieldComparatorSource fsc = new FieldComparatorSource() {
@Override
public FieldComparator newComparator(String fieldname, int
numhits, int sortPos, boolean reversed) {
return new StringValComparatorIgnoreCase(numhits, fieldname);
}
};
Sort sort = new Sort(new SortField("firstname", fsc, false));
IndexSearcher searcher = new IndexSearcher(reader);
TopFieldCollector tfcollector = TopFieldCollector.create(sort,
requestedRecords + 1, Integer.MAX_VALUE);
searcher.search(query, tfcollector);
ScoreDoc[] hits = tfcollector.topDocs(startOffset, pageSize).scoreDocs;
{quote}
At this point "hits" is correct. However, if I remove the "+1" from the
requestedRecords above, the last item in "hits" is often incorrect.
> Ordered intervals can give inaccurate hits on interleaved terms
> ---
>
> Key: LUCENE-9418
> URL: https://issues.apache.org/jira/browse/LUCENE-9418
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Given the text 'A B A C', an ordered interval over 'A B C' will return the
> inaccurate interval [2, 3], due to the way minimization is handled after
> matches are found.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9418) Ordered intervals can give inaccurate hits on interleaved terms
[
https://issues.apache.org/jira/browse/LUCENE-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190420#comment-17190420
]
Brian Coverstone edited comment on LUCENE-9418 at 9/3/20, 10:44 PM:
I believe this may still be an issue in 8.6.0, as I'm finding the last slot can
often have an incorrect record.
I found a workaround, and that is to always select 1 more than needed.
Here is some pseudo code to demonstrate:
{quote}ComplexPhraseQueryParser cpqp = new
ComplexPhraseQueryParser("somefield", analyzer);
Query query = cpqp.parse("somevalue");
pageSize = 10;
pageNum = 1;
requestedRecords = pageSize * pageNum + 1; //+1 workaround
startOffset = (pageNum - 1) * pageSize;
FieldComparatorSource fsc = new FieldComparatorSource() {
@Override
public FieldComparator newComparator(String fieldname, int
numhits, int sortPos, boolean reversed)
Unknown macro: \{ return new StringValComparatorIgnoreCase(numhits,
fieldname); }
};
Sort sort = new Sort(new SortField("firstname", fsc, false));
IndexSearcher searcher = new IndexSearcher(reader);
TopFieldCollector tfcollector = TopFieldCollector.create(sort,
requestedRecords, Integer.MAX_VALUE);
searcher.search(query, tfcollector);
ScoreDoc[] hits = tfcollector.topDocs(startOffset, pageSize).scoreDocs;
{quote}
At this point "hits" is correct. However, if I remove the "+1" from the
requestedRecords above, the last item in "hits" is often incorrect.
was (Author: brain2000):
I believe this may still be an issue in 8.6.0, as I'm finding the last slot can
often have an incorrect record.
I found a workaround, and that is to always select 1 more than needed.
Here is some pseudo code to demonstrate:
{quote}ComplexPhraseQueryParser cpqp = new
ComplexPhraseQueryParser("somefield", analyzer);
Query query = cpqp.parse("somevalue");
pageSize = 10;
pageNum = 1;
requestedRecords = pageSize * pageNum + 1; //+1 workaround
startOffset = (pageNum - 1) * pageSize;
FieldComparatorSource fsc = new FieldComparatorSource() {
@Override
public FieldComparator newComparator(String fieldname, int
numhits, int sortPos, boolean reversed)
{
return new StringValComparatorIgnoreCase(numhits, fieldname);
}
};
Sort sort = new Sort(new SortField("firstname", fsc, false));
IndexSearcher searcher = new IndexSearcher(reader);
TopFieldCollector tfcollector = TopFieldCollector.create(sort,
requestedRecords + 1, Integer.MAX_VALUE);
searcher.search(query, tfcollector);
ScoreDoc[] hits = tfcollector.topDocs(startOffset, pageSize).scoreDocs;
{quote}
At this point "hits" is correct. However, if I remove the "+1" from the
requestedRecords above, the last item in "hits" is often incorrect.
> Ordered intervals can give inaccurate hits on interleaved terms
> ---
>
> Key: LUCENE-9418
> URL: https://issues.apache.org/jira/browse/LUCENE-9418
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Given the text 'A B A C', an ordered interval over 'A B C' will return the
> inaccurate interval [2, 3], due to the way minimization is handled after
> matches are found.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9418) Ordered intervals can give inaccurate hits on interleaved terms
[
https://issues.apache.org/jira/browse/LUCENE-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190420#comment-17190420
]
Brian Coverstone edited comment on LUCENE-9418 at 9/3/20, 10:43 PM:
I believe this may still be an issue in 8.6.0, as I'm finding the last slot can
often have an incorrect record.
I found a workaround, and that is to always select 1 more than needed.
Here is some pseudo code to demonstrate:
{quote}ComplexPhraseQueryParser cpqp = new
ComplexPhraseQueryParser("somefield", analyzer);
Query query = cpqp.parse("somevalue");
pageSize = 10;
pageNum = 1;
requestedRecords = pageSize * pageNum + 1; //+1 workaround
startOffset = (pageNum - 1) * pageSize;
FieldComparatorSource fsc = new FieldComparatorSource() {
@Override
public FieldComparator newComparator(String fieldname, int
numhits, int sortPos, boolean reversed) {
return new StringValComparatorIgnoreCase(numhits, fieldname);
}
};
Sort sort = new Sort(new SortField("firstname", fsc, false));
IndexSearcher searcher = new IndexSearcher(reader);
TopFieldCollector tfcollector = TopFieldCollector.create(sort,
requestedRecords + 1, Integer.MAX_VALUE);
searcher.search(query, tfcollector);
ScoreDoc[] hits = tfcollector.topDocs(startOffset, pageSize).scoreDocs;
{quote}
At this point "hits" is correct. However, if I remove the "+1" from the
requestedRecords above, the last item in "hits" is often incorrect.
was (Author: brain2000):
I believe this may still be an issue in 8.6.0, as I'm finding the last slot can
often have an incorrect record.
I found a workaround, and that is to always select 1 more than needed.
Here is some pseudo code to demonstrate:
{quote}ComplexPhraseQueryParser cpqp = new
ComplexPhraseQueryParser("somefield", analyzer);
Query query = cpqp.parse("somevalue");
pageSize = 10;
pageNum = 1;
requestedRecords = pageSize * pageNum + 1; //+1 workaround
startOffset = (pageNum - 1) * pageSize;
FieldComparatorSource fsc = new FieldComparatorSource() {
@Override
public FieldComparator newComparator(String fieldname, int numhits,
int sortPos, boolean reversed) {
return new StringValComparatorIgnoreCase(numhits, fieldname);
}
};
Sort sort = new Sort(new SortField("firstname", fsc, false));
IndexSearcher searcher = new IndexSearcher(reader);
TopFieldCollector tfcollector = TopFieldCollector.create(sort, requestedRecords
+ 1, Integer.MAX_VALUE);
searcher.search(query, tfcollector);
ScoreDoc[] hits = tfcollector.topDocs(startOffset, pageSize).scoreDocs;
{quote}
At this point "hits" is correct. However, if I remove the "+1" from the
requestedRecords above, the last item in "hits" is often incorrect.
> Ordered intervals can give inaccurate hits on interleaved terms
> ---
>
> Key: LUCENE-9418
> URL: https://issues.apache.org/jira/browse/LUCENE-9418
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Given the text 'A B A C', an ordered interval over 'A B C' will return the
> inaccurate interval [2, 3], due to the way minimization is handled after
> matches are found.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9418) Ordered intervals can give inaccurate hits on interleaved terms
[
https://issues.apache.org/jira/browse/LUCENE-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190420#comment-17190420
]
Brian Coverstone commented on LUCENE-9418:
--
I believe this may still be an issue in 8.6.0, as I'm finding the last slot can
often have an incorrect record.
I found a workaround, and that is to always select 1 more than needed.
Here is some pseudo code to demonstrate:
{quote}ComplexPhraseQueryParser cpqp = new
ComplexPhraseQueryParser("somefield", analyzer);
Query query = cpqp.parse("somevalue");
pageSize = 10;
pageNum = 1;
requestedRecords = pageSize * pageNum + 1; //+1 workaround
startOffset = (pageNum - 1) * pageSize;
FieldComparatorSource fsc = new FieldComparatorSource() {
@Override
public FieldComparator newComparator(String fieldname, int numhits,
int sortPos, boolean reversed) {
return new StringValComparatorIgnoreCase(numhits, fieldname);
}
};
Sort sort = new Sort(new SortField("firstname", fsc, false));
IndexSearcher searcher = new IndexSearcher(reader);
TopFieldCollector tfcollector = TopFieldCollector.create(sort, requestedRecords
+ 1, Integer.MAX_VALUE);
searcher.search(query, tfcollector);
ScoreDoc[] hits = tfcollector.topDocs(startOffset, pageSize).scoreDocs;
{quote}
At this point "hits" is correct. However, if I remove the "+1" from the
requestedRecords above, the last item in "hits" is often incorrect.
> Ordered intervals can give inaccurate hits on interleaved terms
> ---
>
> Key: LUCENE-9418
> URL: https://issues.apache.org/jira/browse/LUCENE-9418
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Given the text 'A B A C', an ordered interval over 'A B C' will return the
> inaccurate interval [2, 3], due to the way minimization is handled after
> matches are found.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14776) Precompute the fingerprint during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190410#comment-17190410 ] Mike Drob commented on SOLR-14776: -- Thinking about this more, is the big win that we compute our own fingerprint during the time that would normally be spent waiting, and we decrease latency that way? > Precompute the fingerprint during PeerSync > -- > > Key: SOLR-14776 > URL: https://issues.apache.org/jira/browse/SOLR-14776 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Computing fingerprint can very costly and take time. But the current > implementation will send requests for getting fingerprint for multiple > replicas, then on the first response it will then compute its own fingerprint > for comparison. A very simple but effective improvement here is compute its > own fingerprint right after send requests to other replicas. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14776) Precompute the fingerprint during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190408#comment-17190408 ] Mike Drob commented on SOLR-14776: -- Is there a chance that the core is changing between subsequent calls and so it is not safe to use the same, maybe from incoming updates? It looks like there is already caching on SolrCore.getIndexFingerprint, is that broken or insufficient in some way? > Precompute the fingerprint during PeerSync > -- > > Key: SOLR-14776 > URL: https://issues.apache.org/jira/browse/SOLR-14776 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Computing fingerprint can very costly and take time. But the current > implementation will send requests for getting fingerprint for multiple > replicas, then on the first response it will then compute its own fingerprint > for comparison. A very simple but effective improvement here is compute its > own fingerprint right after send requests to other replicas. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-9504) DocumentsWriterDeleteQueue.forceApplyGlobalSlice has needless locking
[
https://issues.apache.org/jira/browse/LUCENE-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob reassigned LUCENE-9504:
-
Assignee: Mike Drob
> DocumentsWriterDeleteQueue.forceApplyGlobalSlice has needless locking
> -
>
> Key: LUCENE-9504
> URL: https://issues.apache.org/jira/browse/LUCENE-9504
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DocumentsWriterDeleteQueue.forceApplyGlobalSlice}} is only called from
> {{getBufferedUpdateTermsSize}} so we end up doing double the locking. It's
> not a huge problem because re-entrant locks are cheap, but we can probably
> unwrap the methods a little bit here.
> This may impact HotSpot inlining, I haven't tried measuring that yet. If that
> is a concern, please let me know.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14579) Comment SolrJ 'Utils' generic map functions
[ https://issues.apache.org/jira/browse/SOLR-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190401#comment-17190401 ] Erick Erickson commented on SOLR-14579: --- [~uschindler] bq. why did you re-apply the 8.x comments? They are as wrong as in master. I have no recollection of doing so, certainly not intentionally. A fresh pull of 8x about 60 seconds ago shows no comments in 8x, and the git history shows no re-revert, un-revert or any other indication of this, at least on my machine. So I don't know what you're talking about. As far as I can tell you're hallucinating ;). > Comment SolrJ 'Utils' generic map functions > --- > > Key: SOLR-14579 > URL: https://issues.apache.org/jira/browse/SOLR-14579 > Project: Solr > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Megan Carey >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14579.patch > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Remove the map functions like `NEW_HASHMAP_FUN` from the Utils class in solrj > module to reduce warnings and improve code quality. > [https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Utils.java#L92] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] vthacker commented on pull request #1816: LUCENE-9497: Integerate Error Prone ( Static Analysis Tool ) during compilation
vthacker commented on pull request #1816: URL: https://github.com/apache/lucene-solr/pull/1816#issuecomment-686774814 Latest change applies errorprone to all modules ( thanks `forbidden-apis.gradle` for the example ) Also explicitly disable all warnings 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. 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
[GitHub] [lucene-solr] tflobbe commented on a change in pull request #1815: SOLR-14151: Bug fixes
tflobbe commented on a change in pull request #1815:
URL: https://github.com/apache/lucene-solr/pull/1815#discussion_r483251942
##
File path: solr/core/src/java/org/apache/solr/core/ConfigSetService.java
##
@@ -81,8 +81,7 @@ public final ConfigSet loadConfigSet(CoreDescriptor dcore) {
) ? false: true;
SolrConfig solrConfig = createSolrConfig(dcore, coreLoader, trusted);
- IndexSchema indexSchema = createIndexSchema(dcore, solrConfig, false);
- return new ConfigSet(configSetName(dcore), solrConfig, force ->
indexSchema, properties, trusted);
+ return new ConfigSet(configSetName(dcore), solrConfig, force ->
createIndexSchema(dcore, solrConfig, force), properties, trusted);
Review comment:
Does this mean that every call to `configSet.getIndexSchema()` will
create a new schema object (if shared schema is not enabled)?
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.
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
[GitHub] [lucene-solr] tflobbe commented on a change in pull request #1815: SOLR-14151: Bug fixes
tflobbe commented on a change in pull request #1815:
URL: https://github.com/apache/lucene-solr/pull/1815#discussion_r483251942
##
File path: solr/core/src/java/org/apache/solr/core/ConfigSetService.java
##
@@ -81,8 +81,7 @@ public final ConfigSet loadConfigSet(CoreDescriptor dcore) {
) ? false: true;
SolrConfig solrConfig = createSolrConfig(dcore, coreLoader, trusted);
- IndexSchema indexSchema = createIndexSchema(dcore, solrConfig, false);
- return new ConfigSet(configSetName(dcore), solrConfig, force ->
indexSchema, properties, trusted);
+ return new ConfigSet(configSetName(dcore), solrConfig, force ->
createIndexSchema(dcore, solrConfig, force), properties, trusted);
Review comment:
Does this mean that every call to `configSet.getIndexSchema()` will
create a new schema object?
##
File path: solr/core/src/java/org/apache/solr/core/SolrCores.java
##
@@ -282,15 +283,19 @@ protected SolrCore remove(String name) {
return ret;
}
}
+ SolrCore getCoreFromAnyList(String name, boolean incRefCount) {
+return getCoreFromAnyList(name, incRefCount, null);
+ }
/* If you don't increment the reference count, someone could close the core
before you use it. */
- SolrCore getCoreFromAnyList(String name, boolean incRefCount) {
+ SolrCore getCoreFromAnyList(String name, boolean incRefCount, UUID coreId) {
synchronized (modifyLock) {
SolrCore core = cores.get(name);
if (core == null && getTransientCacheHandler() != null) {
core = getTransientCacheHandler().getCore(name);
}
+ if(core != null && coreId != null && coreId != core.uniqueId) return
null;
Review comment:
mind putting the space after the `if` (here and in the rest of your
changes)? that's the standard across the rest of the code AFAIK
##
File path: solr/core/src/java/org/apache/solr/core/CoreContainer.java
##
@@ -1582,6 +1582,13 @@ private CoreDescriptor
reloadCoreDescriptor(CoreDescriptor oldDesc) {
public void reload(String name) {
reload(name, null);
}
+ public void reload(String name, UUID coreId, boolean async) {
+if(async) {
+ runAsync(() -> reload(name, coreId));
+} else {
+ reload(name, coreId);
+}
+ }
Review comment:
Why is this method added? you don't seem to be doing any async reloads.
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.
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
[GitHub] [lucene-solr] vthacker commented on pull request #1816: LUCENE-9497: Integerate Error Prone ( Static Analysis Tool ) during compilation
vthacker commented on pull request #1816: URL: https://github.com/apache/lucene-solr/pull/1816#issuecomment-686719941 > but I'd like to see how to mark valid code with suppressions first so that we can correct the errors, exclude false-positives somehow and then enable this plugin to run by default. Instead of marking code with supressions, what if we excluded all the warning types that are there in our codebase explicitly ``` options.errorprone.errorproneArgs = ['-Xep:ClassCanBeStatic:OFF', '-Xep:InvalidInlineTag:OFF', ``` That would ensure 1. No new warnings creep in 1. We don't need to remove `-Werror` and the compile output doesn't throw a bunch of warnings that no one looks at Then in subsequent PRs we can remove one warning type and fix the code usage by either addressing them or suppressing them in 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. 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
[jira] [Resolved] (SOLR-14658) SolrJ COLSTATUS interface returns all collections when specifying one
[
https://issues.apache.org/jira/browse/SOLR-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-14658.
-
Fix Version/s: 8.7
Resolution: Fixed
Thanks Andy!
> SolrJ COLSTATUS interface returns all collections when specifying one
> -
>
> Key: SOLR-14658
> URL: https://issues.apache.org/jira/browse/SOLR-14658
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: master (9.0), 8.3
>Reporter: Andy Vuong
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.7
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In SolrJ, using the interface available for making COLSTATUS collection calls
> will return the collection status for all collections on the cluster as
> opposed to just one when specifying the collection.
> The API in question is CollectionAdminRequest.collectionStatus(collection)
> in the class [CollectionAdminRequest.java|#L903]]. This will create and
> return a new CollectionAdminRequest#ColStatus instance that extends
> AsyncCollectionSpecificAdminRequest.
> The constructor of that class will pass the collection passed in to the
> [parent|#L250]] class and keep it in a param “collection”.
> When we call AsyncCollectionSpecificAdminRequest.getParams(), we return:
> {code:java}
> @Override
> public SolrParams getParams() {
> ModifiableSolrParams params = new ModifiableSolrParams(super.getParams());
>
> params.set(CoreAdminParams.NAME, collection);
> params.setNonNull(CollectionAdminParams.FOLLOW_ALIASES, followAliases);
> return params;
> }{code}
> With “name” set to the collection name. In
> [CollectionsHandler|https://github.com/apache/lucene-solr/blob/03d658a7bc306370cfce6ef92f34f151db7ad3dc/solr/core/src/java/org/apache/solr/handler/admin/CollectionsHandler.java#L514]
> where Solr handles the collection API operation request, it only copies the
> follow params if they exist into a new map of properties. Notice how it is
> missing “name” so we'll never copy that param even if it's included.
> We then call ColStatus.java#getColStatus in the same block, getColStatus
> method will try to retrieve "collection" but will always return null since
> it's not used in the solrj interfaces and therefore grab the status from all
> collections vs the one specified when using solrj.
> {code:java}
> String col = props.getStr(ZkStateReader.COLLECTION_PROP);
> if (col == null) {
> collections = new HashSet<>(clusterState.getCollectionsMap().keySet());
> } else {
> collections = Collections.singleton(col);
> }
> {code}
> [ColStatus.java|#L514]]
> This is unfortunate as the command will send a request to every leader
> replica per collection when that was not the intention.
> This can be reproduced by spinning up a cluster with 2+ collections and a
> short snippet of code which will return the status for all collections as
> opposed to one:
> {code:java}
> String host = "http://localhost:8983/solr;;
> HttpSolrClient.Builder builder = new HttpSolrClient.Builder(host);
> HttpSolrClient solrClient = builder.build(); String collection = "test";
> final NamedList response =
>solrClient.request(CollectionAdminRequest.collectionStatus(collection));
> System.out.println(response);{code}
> I think the simplest fix is to just add "NAME" to the list of params that get
> copied in CollectionsHandler and can try that a bit later.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14658) SolrJ COLSTATUS interface returns all collections when specifying one
[
https://issues.apache.org/jira/browse/SOLR-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190346#comment-17190346
]
ASF subversion and git services commented on SOLR-14658:
Commit 61ea26ac758ea8048177b197d2fdeddbe7cc5df0 in lucene-solr's branch
refs/heads/branch_8x from Andy Vuong
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=61ea26a ]
SOLR-14658: SolrJ collectionStatus(col) should only fetch one status (#1687)
An optimization or a perf-bug depending on point of view
(cherry picked from commit 2544df8f6d9a23e285d899c6a754611dd830f68f)
> SolrJ COLSTATUS interface returns all collections when specifying one
> -
>
> Key: SOLR-14658
> URL: https://issues.apache.org/jira/browse/SOLR-14658
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: master (9.0), 8.3
>Reporter: Andy Vuong
>Assignee: David Smiley
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In SolrJ, using the interface available for making COLSTATUS collection calls
> will return the collection status for all collections on the cluster as
> opposed to just one when specifying the collection.
> The API in question is CollectionAdminRequest.collectionStatus(collection)
> in the class [CollectionAdminRequest.java|#L903]]. This will create and
> return a new CollectionAdminRequest#ColStatus instance that extends
> AsyncCollectionSpecificAdminRequest.
> The constructor of that class will pass the collection passed in to the
> [parent|#L250]] class and keep it in a param “collection”.
> When we call AsyncCollectionSpecificAdminRequest.getParams(), we return:
> {code:java}
> @Override
> public SolrParams getParams() {
> ModifiableSolrParams params = new ModifiableSolrParams(super.getParams());
>
> params.set(CoreAdminParams.NAME, collection);
> params.setNonNull(CollectionAdminParams.FOLLOW_ALIASES, followAliases);
> return params;
> }{code}
> With “name” set to the collection name. In
> [CollectionsHandler|https://github.com/apache/lucene-solr/blob/03d658a7bc306370cfce6ef92f34f151db7ad3dc/solr/core/src/java/org/apache/solr/handler/admin/CollectionsHandler.java#L514]
> where Solr handles the collection API operation request, it only copies the
> follow params if they exist into a new map of properties. Notice how it is
> missing “name” so we'll never copy that param even if it's included.
> We then call ColStatus.java#getColStatus in the same block, getColStatus
> method will try to retrieve "collection" but will always return null since
> it's not used in the solrj interfaces and therefore grab the status from all
> collections vs the one specified when using solrj.
> {code:java}
> String col = props.getStr(ZkStateReader.COLLECTION_PROP);
> if (col == null) {
> collections = new HashSet<>(clusterState.getCollectionsMap().keySet());
> } else {
> collections = Collections.singleton(col);
> }
> {code}
> [ColStatus.java|#L514]]
> This is unfortunate as the command will send a request to every leader
> replica per collection when that was not the intention.
> This can be reproduced by spinning up a cluster with 2+ collections and a
> short snippet of code which will return the status for all collections as
> opposed to one:
> {code:java}
> String host = "http://localhost:8983/solr;;
> HttpSolrClient.Builder builder = new HttpSolrClient.Builder(host);
> HttpSolrClient solrClient = builder.build(); String collection = "test";
> final NamedList response =
>solrClient.request(CollectionAdminRequest.collectionStatus(collection));
> System.out.println(response);{code}
> I think the simplest fix is to just add "NAME" to the list of params that get
> copied in CollectionsHandler and can try that a bit later.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14658) SolrJ COLSTATUS interface returns all collections when specifying one
[
https://issues.apache.org/jira/browse/SOLR-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190345#comment-17190345
]
ASF subversion and git services commented on SOLR-14658:
Commit 2544df8f6d9a23e285d899c6a754611dd830f68f in lucene-solr's branch
refs/heads/master from Andy Vuong
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2544df8 ]
SOLR-14658: SolrJ collectionStatus(col) should only fetch one status (#1687)
An optimization or a perf-bug depending on point of view
> SolrJ COLSTATUS interface returns all collections when specifying one
> -
>
> Key: SOLR-14658
> URL: https://issues.apache.org/jira/browse/SOLR-14658
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: master (9.0), 8.3
>Reporter: Andy Vuong
>Assignee: David Smiley
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In SolrJ, using the interface available for making COLSTATUS collection calls
> will return the collection status for all collections on the cluster as
> opposed to just one when specifying the collection.
> The API in question is CollectionAdminRequest.collectionStatus(collection)
> in the class [CollectionAdminRequest.java|#L903]]. This will create and
> return a new CollectionAdminRequest#ColStatus instance that extends
> AsyncCollectionSpecificAdminRequest.
> The constructor of that class will pass the collection passed in to the
> [parent|#L250]] class and keep it in a param “collection”.
> When we call AsyncCollectionSpecificAdminRequest.getParams(), we return:
> {code:java}
> @Override
> public SolrParams getParams() {
> ModifiableSolrParams params = new ModifiableSolrParams(super.getParams());
>
> params.set(CoreAdminParams.NAME, collection);
> params.setNonNull(CollectionAdminParams.FOLLOW_ALIASES, followAliases);
> return params;
> }{code}
> With “name” set to the collection name. In
> [CollectionsHandler|https://github.com/apache/lucene-solr/blob/03d658a7bc306370cfce6ef92f34f151db7ad3dc/solr/core/src/java/org/apache/solr/handler/admin/CollectionsHandler.java#L514]
> where Solr handles the collection API operation request, it only copies the
> follow params if they exist into a new map of properties. Notice how it is
> missing “name” so we'll never copy that param even if it's included.
> We then call ColStatus.java#getColStatus in the same block, getColStatus
> method will try to retrieve "collection" but will always return null since
> it's not used in the solrj interfaces and therefore grab the status from all
> collections vs the one specified when using solrj.
> {code:java}
> String col = props.getStr(ZkStateReader.COLLECTION_PROP);
> if (col == null) {
> collections = new HashSet<>(clusterState.getCollectionsMap().keySet());
> } else {
> collections = Collections.singleton(col);
> }
> {code}
> [ColStatus.java|#L514]]
> This is unfortunate as the command will send a request to every leader
> replica per collection when that was not the intention.
> This can be reproduced by spinning up a cluster with 2+ collections and a
> short snippet of code which will return the status for all collections as
> opposed to one:
> {code:java}
> String host = "http://localhost:8983/solr;;
> HttpSolrClient.Builder builder = new HttpSolrClient.Builder(host);
> HttpSolrClient solrClient = builder.build(); String collection = "test";
> final NamedList response =
>solrClient.request(CollectionAdminRequest.collectionStatus(collection));
> System.out.println(response);{code}
> I think the simplest fix is to just add "NAME" to the list of params that get
> copied in CollectionsHandler and can try that a bit later.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley merged pull request #1687: SOLR-14658: Fix colstatus solrj interfaces to return one or all collections
dsmiley merged pull request #1687: URL: https://github.com/apache/lucene-solr/pull/1687 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. 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
[jira] [Comment Edited] (LUCENE-9444) Need an API to easily fetch facet labels for a field in a document
[ https://issues.apache.org/jira/browse/LUCENE-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190342#comment-17190342 ] Ankur edited comment on LUCENE-9444 at 9/3/20, 6:09 PM: Patch has been available for 1+ day, not sure why automated patch testing has not picked it up yet. was (Author: goankur): Patch has been available for 1+ day, not sure why automated patch testing has picked it up yet. > Need an API to easily fetch facet labels for a field in a document > -- > > Key: LUCENE-9444 > URL: https://issues.apache.org/jira/browse/LUCENE-9444 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/facet >Affects Versions: 8.6 >Reporter: Ankur >Priority: Major > Labels: facet > Attachments: LUCENE-9444.patch > > > A facet field may be included in the list of fields whose values are to be > returned for each hit. > In order to get the facet labels for each hit we need to > # Create an instance of _DocValuesOrdinalsReader_ and invoke > _getReader(LeafReaderContext context)_ method to obtain an instance of > _OrdinalsSegmentReader()_ > # _OrdinalsSegmentReader.get(int docID, IntsRef ordinals)_ method is then > used to fetch and decode the binary payload in the document's BinaryDocValues > field. This provides the ordinals that refer to facet labels in the > taxonomy.** > # Lastly TaxonomyReader.getPath(ord) is used to fetch the labels to be > returned. > > Ideally there should be a simple API - *String[] getLabels(docId)* that hides > all the above details and gives us the string labels. This can be part of > *TaxonomyFacets* but that's just one idea. > I am opening this issue to get community feedback and suggestions. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9444) Need an API to easily fetch facet labels for a field in a document
[ https://issues.apache.org/jira/browse/LUCENE-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190342#comment-17190342 ] Ankur commented on LUCENE-9444: --- Patch has been available for 1+ day, not sure why automated patch testing has picked it up yet. > Need an API to easily fetch facet labels for a field in a document > -- > > Key: LUCENE-9444 > URL: https://issues.apache.org/jira/browse/LUCENE-9444 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/facet >Affects Versions: 8.6 >Reporter: Ankur >Priority: Major > Labels: facet > Attachments: LUCENE-9444.patch > > > A facet field may be included in the list of fields whose values are to be > returned for each hit. > In order to get the facet labels for each hit we need to > # Create an instance of _DocValuesOrdinalsReader_ and invoke > _getReader(LeafReaderContext context)_ method to obtain an instance of > _OrdinalsSegmentReader()_ > # _OrdinalsSegmentReader.get(int docID, IntsRef ordinals)_ method is then > used to fetch and decode the binary payload in the document's BinaryDocValues > field. This provides the ordinals that refer to facet labels in the > taxonomy.** > # Lastly TaxonomyReader.getPath(ord) is used to fetch the labels to be > returned. > > Ideally there should be a simple API - *String[] getLabels(docId)* that hides > all the above details and gives us the string labels. This can be part of > *TaxonomyFacets* but that's just one idea. > I am opening this issue to get community feedback and suggestions. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob opened a new pull request #1826: LUCENE-9504 Remove extra lock in DocumentsWriterDeleteQueue
madrob opened a new pull request #1826: URL: https://github.com/apache/lucene-solr/pull/1826 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. 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
[jira] [Created] (LUCENE-9504) DocumentsWriterDeleteQueue.forceApplyGlobalSlice has needless locking
Mike Drob created LUCENE-9504:
-
Summary: DocumentsWriterDeleteQueue.forceApplyGlobalSlice has
needless locking
Key: LUCENE-9504
URL: https://issues.apache.org/jira/browse/LUCENE-9504
Project: Lucene - Core
Issue Type: Improvement
Components: core/index
Reporter: Mike Drob
{{DocumentsWriterDeleteQueue.forceApplyGlobalSlice}} is only called from
{{getBufferedUpdateTermsSize}} so we end up doing double the locking. It's not
a huge problem because re-entrant locks are cheap, but we can probably unwrap
the methods a little bit here.
This may impact HotSpot inlining, I haven't tried measuring that yet. If that
is a concern, please let me know.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190318#comment-17190318
]
Erick Erickson commented on SOLR-14723:
---
Please do!
Find all of the solrconfig.xml files (unix find . -name solrconfig.xml) and
replace the above with
{code}
{code}
Really, just remove the "class=" bits from all the cache entries. There should
be 3-4 of them in each solrconfig.xml file.
You should run "gw check" on the code afterwards. If some tests fail, try
rerunning the test with the commands that'll be printed out "reproduce
with". there are some tests that sometimes fail (we're working on it). The
point here is don't automatically assume that your changes caused the failure
unless it reproduces consistently.
Then create a patch or a PR if you're git-savvy and attach it to this JIRA. Git
will automatically do the associations for a PR if you include "SOLR-14723:
Rremove the class atribute for the caches in the _default/example configsets"
in the title.
If you choose to attach a patch file, just call it SOLR-14723.patch. Subsequent
patches should have the same name, the JIRA system will automatically handle it.
Then ping this JIRA asking for review/commit.
Thanks for volunttering! This will be a good thing to get your feet wet,
understand the build system, how to run tests and all that.
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190304#comment-17190304
]
Shashank Shekhar commented on SOLR-14723:
-
As a newdev I am enthusiastic to take this up. Hoping its something that I can
manage. How should I proceed with this ?
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] cpoerschke opened a new pull request #1825: SOLR-14828: reduce 'error' logging noise in BaseCloudSolrClient.requestWithRetryOnStaleState
cpoerschke opened a new pull request #1825: URL: https://github.com/apache/lucene-solr/pull/1825 https://issues.apache.org/jira/browse/SOLR-14828 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. 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
[jira] [Created] (SOLR-14828) reduce 'error' logging noise in BaseCloudSolrClient.requestWithRetryOnStaleState
Christine Poerschke created SOLR-14828: -- Summary: reduce 'error' logging noise in BaseCloudSolrClient.requestWithRetryOnStaleState Key: SOLR-14828 URL: https://issues.apache.org/jira/browse/SOLR-14828 Project: Solr Issue Type: Task Components: SolrJ Reporter: Christine Poerschke Assignee: Christine Poerschke Currently -- e.g. https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.2/solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseCloudSolrClient.java#L960-L961 -- an error is logged even if request retrying will happen (and hopefully succeed). This task proposes to 'info' or 'warn' rather than 'error' log if the request will be retried. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on pull request #1684: SOLR-14613: strongly typed placement plugin interface and implementation
dsmiley commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-686588314 I am a conflict-avoider (not a good thing) but need to say I fully agree with @sigram 's impression of the tone. I can tell, personally, as a subjective measure in how my own body reacts. When I read conflict, my heart starts racing (fight/flight response?), and it started racing on some of Noble's comments and Ishan alike. It can be hard to objectively measure tone; I think it's fundamentally subjective, though some particulars we point to can be illustrative of behavioral problems. I will be specific: @chatman wrote > Plugin making concurrent requests is "complicated"? Java is hard, but I can help you write a plugin that can make concurrent requests cleanly. Please don't pollute solr-core because of your perceived inability to do so cleanly from a plugin. Wow. I'm not even sure that would be polite to say to a junior engineer (that may be presumed to not know concurrency) than a very senior one here. I think you know full well that Ilan doesn't need your help writing concurrent code. Yet why would you offer help? I think this is a false offer (you know Ilan will not take you up on this); -- it's a pejorative offer that belittles who you offer it to as being beneath the abilities of your own. I wonder why you would say that? Maybe you don't believe it's worth it to make it easier for plugin writers at the expense of Solr having such concurrent code (i.e. where does the concurrency/complexity go) -- fare, but then just say that without belittling anyone's intelligence. At least at the moment it seems we're at a point of better understanding. p.s. This PR is so big/long that my browser (Safari) struggles to keep up as I type here. I copy-paste from a text-editor.t 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. 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
[jira] [Updated] (LUCENE-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-9500: -- Affects Version/s: 8.7 8.x > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: 8.x, master (9.0), 8.7 >Reporter: Adrien Grand >Assignee: Uwe Schindler >Priority: Minor > Labels: Java13, Java14, Java15, java11, jdk11, jdk13, jdk14, > jdk15 > Fix For: 8.x, master (9.0), 8.7 > > Attachments: PresetDictTest.java, test_data.txt > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-9500: -- Priority: Critical (was: Minor) > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: 8.x, master (9.0), 8.7 >Reporter: Adrien Grand >Assignee: Uwe Schindler >Priority: Critical > Labels: Java13, Java14, Java15, java11, jdk11, jdk13, jdk14, > jdk15 > Fix For: 8.x, master (9.0), 8.7 > > Attachments: PresetDictTest.java, test_data.txt > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-9500: -- Fix Version/s: 8.7 8.x > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: master (9.0) >Reporter: Adrien Grand >Assignee: Uwe Schindler >Priority: Minor > Labels: Java13, Java14, Java15, java11, jdk11, jdk13, jdk14, > jdk15 > Fix For: 8.x, master (9.0), 8.7 > > Attachments: PresetDictTest.java, test_data.txt > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-9500: -- Fix Version/s: master (9.0) > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: master (9.0) >Reporter: Adrien Grand >Assignee: Uwe Schindler >Priority: Minor > Labels: Java13, Java14, Java15, java11, jdk11, jdk13, jdk14, > jdk15 > Fix For: master (9.0) > > Attachments: PresetDictTest.java, test_data.txt > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190207#comment-17190207 ] Uwe Schindler commented on LUCENE-9500: --- Thanks to all for help! > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: master (9.0) >Reporter: Adrien Grand >Assignee: Uwe Schindler >Priority: Minor > Labels: Java13, Java14, Java15, java11, jdk11, jdk13, jdk14, > jdk15 > Attachments: PresetDictTest.java, test_data.txt > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-9500. --- Resolution: Fixed > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: master (9.0) >Reporter: Adrien Grand >Assignee: Uwe Schindler >Priority: Minor > Labels: Java13, Java14, Java15, java11, jdk11, jdk13, jdk14, > jdk15 > Attachments: PresetDictTest.java, test_data.txt > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] dsmiley commented on pull request #29: Cve 2020 13941
dsmiley commented on pull request #29: URL: https://github.com/apache/lucene-site/pull/29#issuecomment-686556863 Updated. I didn't add "Vendor" which seems pointless. Where did this template/convention come from? 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. 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
[jira] [Commented] (LUCENE-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190203#comment-17190203 ] ASF subversion and git services commented on LUCENE-9500: - Commit d031f8e7bd62eb3a894cf436f81d398e3d7db493 in lucene-solr's branch refs/heads/branch_8x from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d031f8e ] LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater (#1824) > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: master (9.0) >Reporter: Adrien Grand >Assignee: Uwe Schindler >Priority: Minor > Labels: Java13, Java14, Java15, java11, jdk11, jdk13, jdk14, > jdk15 > Attachments: PresetDictTest.java, test_data.txt > > Time Spent: 2h 10m > Remaining Estimate: 0h > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler commented on pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
uschindler commented on pull request #1824: URL: https://github.com/apache/lucene-solr/pull/1824#issuecomment-686556365 Short info: After backporting to 8.x, of course JDK 8u192 was detected as **non-buggy**. 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. 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
[jira] [Created] (LUCENE-9503) Fix comment explaining reason for 8KB buffered/chunked writes
Henning Andersen created LUCENE-9503:
Summary: Fix comment explaining reason for 8KB buffered/chunked
writes
Key: LUCENE-9503
URL: https://issues.apache.org/jira/browse/LUCENE-9503
Project: Lucene - Core
Issue Type: Improvement
Components: core/store
Affects Versions: 8.6.2
Reporter: Henning Andersen
Attachments: LUCENE-8kb-comment.patch
FSDirectory uses an 8KB buffer and chunk size when writing to disk. The class
has a comment explaining how file channels would do mallocs for larger chunks.
However, that comment was originally introduced when RandomAccessFile and later
FileOutputStream was used. Since the switch to file channels, there is no
longer any difference (except the size of the buffer) for different
buffer/chunk sizes.
Attached patch keeps the comment, clarifying that it is a historic reason.
Including my research here for background information in case this helps
validate the change:
# The stack buffer for 8KB or below in the JDK is here:
[https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjava/io_util.c#L150]
This is used by both {{FileOutputStream}} and {{RandomAccessFile}}.
# This was applicable when the comment to lucene was added and later changed
to {{FileOutputStream}}:
[https://github.com/apache/lucene-solr/commit/c4bdb2dad0abd85427f36732f4b1be66787b9815#diff-dc399b5658d57753fffdad7539f22e50R344]
# Lucene cut over to nio here:
[https://github.com/apache/lucene-solr/commit/3eb66fb19ca2aa3d9dce53661f3233b6c9d3f974#diff-dc399b5658d57753fffdad7539f22e50R324]
and the comment was later changed to say {{file channels}} here:
[https://github.com/apache/lucene-solr/commit/cf845b1335af05f27d746a38a043bd815821a69f]
# File channels use thread local direct buffers instead, see
sun.nio.ch.IOUtil.write, which uses Util.getTemporaryDirectBuffer to get a
thread local buffer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14827) Refactor schema loading to not use XPath
[ https://issues.apache.org/jira/browse/SOLR-14827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-14827: -- Labels: perfomance (was: ) > Refactor schema loading to not use XPath > > > Key: SOLR-14827 > URL: https://issues.apache.org/jira/browse/SOLR-14827 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Labels: perfomance > > XPath is slower compared to DOM. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14827) Refactor schema loading to not use XPath
Noble Paul created SOLR-14827: - Summary: Refactor schema loading to not use XPath Key: SOLR-14827 URL: https://issues.apache.org/jira/browse/SOLR-14827 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul Assignee: Noble Paul XPath is slower compared to DOM. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190200#comment-17190200 ] ASF subversion and git services commented on LUCENE-9500: - Commit 99df3814abff7c40e80530edc90a2f008a3b92b5 in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=99df381 ] LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater (#1824) > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: master (9.0) >Reporter: Adrien Grand >Assignee: Uwe Schindler >Priority: Minor > Labels: Java13, Java14, Java15, java11, jdk11, jdk13, jdk14, > jdk15 > Attachments: PresetDictTest.java, test_data.txt > > Time Spent: 2h 10m > Remaining Estimate: 0h > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler merged pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
uschindler merged pull request #1824: URL: https://github.com/apache/lucene-solr/pull/1824 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. 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
[GitHub] [lucene-solr] uschindler commented on pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
uschindler commented on pull request #1824: URL: https://github.com/apache/lucene-solr/pull/1824#issuecomment-686528216 Hi, I did further tests (except Java 8, I need to merge first), Results looking fine: - OpenJDK JDK 11.0.2 reports **non-buggy** - AdoptJDK 11.0.5 reports **buggy** - Oracle JDK 11.0.8 reports **buggy** - JDK 12 reports **non-buggy** - JDK 13 reports **buggy** - JDK 14 reports **buggy** I keep the class for now as package private. Thoughts: - If Elasticsearch or Solr want to report on startup that the JDK they are using is buggy and they should upgrade (once they have a fix available, a fix for JDK 11 looks promising as this was a regression!), we can make the class public, so startup code has access to the boolean flag - We may print a Info in the test, so when running tests you get informed about the issue (useful for quick testing a new JDK release) 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. 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
[jira] [Commented] (LUCENE-9502) Can we remove JaspellLookup?
[ https://issues.apache.org/jira/browse/LUCENE-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190170#comment-17190170 ] Cassandra Targett commented on LUCENE-9502: --- I linked SOLR-13230, the issue to figure out what to do with Jaspell in Solr. It is related to LUCENE-8638 and SOLR-13138, both ongoing efforts to clean up and remove deprecated code from master before 9.0. > Can we remove JaspellLookup? > > > Key: LUCENE-9502 > URL: https://issues.apache.org/jira/browse/LUCENE-9502 > Project: Lucene - Core > Issue Type: Wish >Affects Versions: master (9.0) >Reporter: Simon Willnauer >Priority: Major > > We deprecated JaspellLookup in version 4.9 - I do wonder if it's time to get > rid of it? I can see it's still used in solr but I don't see if it's > deprecated there. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13230) Move JaSpell code into Solr and deprecate the factory
[ https://issues.apache.org/jira/browse/SOLR-13230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190168#comment-17190168 ] Cassandra Targett commented on SOLR-13230: -- Linking a very old issue SOLR-6178 which was for deprecating Jaspell way back in 4.9 when it was deprecated in Lucene. I think we could probably close the older one? > Move JaSpell code into Solr and deprecate the factory > - > > Key: SOLR-13230 > URL: https://issues.apache.org/jira/browse/SOLR-13230 > Project: Solr > Issue Type: Task >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13230.patch > > > The JaSpell suggester is deprecated, and will be removed from the lucene > codebase. However, it's currently the default implementation for suggesters > in Solr, and its Solr factory is *not* deprecated, so users won't have been > receiving any warnings. > I suggest that we deprecate the factory, and move the relevant bits of code > from lucene into Solr, as a first step. In a follow-up we should change the > default implementation (possibly by just removing the default, and forcing > people to choose a factory?) and remove the deprecated code form Solr as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-11875) merge SolrConfigXml wiki into Solr Reference Guide
[
https://issues.apache.org/jira/browse/SOLR-11875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190166#comment-17190166
]
Alexandre Rafalovitch commented on SOLR-11875:
--
Could we revisit this issue for 9 and with gradle? Or make a decision to just
link to the latest (non-versioned) url for the RefGuide.
The (twice-old) wiki links are definitely no longer worth having.
I would like to update all documentation links to RefGuide and away from wiki.
> merge SolrConfigXml wiki into Solr Reference Guide
> --
>
> Key: SOLR-11875
> URL: https://issues.apache.org/jira/browse/SOLR-11875
> Project: Solr
> Issue Type: Task
> Components: documentation, website
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11875.patch
>
>
> The default and example solrconfig.xml currently point to the
> https://wiki.apache.org/solr/SolrConfigXml page, might we change that perhaps
> to point into the Solr Reference Guide (and merge content from the wiki into
> the ref guide where appropriate)?
> {code}
>
> {code}
> Implementation detail: the {{7_x}} in the above would need to be an actual
> {{7_3}} etc. version in each release.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11875) merge SolrConfigXml wiki into Solr Reference Guide
[
https://issues.apache.org/jira/browse/SOLR-11875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch reassigned SOLR-11875:
Assignee: Alexandre Rafalovitch
> merge SolrConfigXml wiki into Solr Reference Guide
> --
>
> Key: SOLR-11875
> URL: https://issues.apache.org/jira/browse/SOLR-11875
> Project: Solr
> Issue Type: Task
> Components: documentation, website
>Reporter: Christine Poerschke
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Attachments: SOLR-11875.patch
>
>
> The default and example solrconfig.xml currently point to the
> https://wiki.apache.org/solr/SolrConfigXml page, might we change that perhaps
> to point into the Solr Reference Guide (and merge content from the wiki into
> the ref guide where appropriate)?
> {code}
>
> {code}
> Implementation detail: the {{7_x}} in the above would need to be an actual
> {{7_3}} etc. version in each release.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14826) Clean up package name conflicts between modules (split packages)
Tomoko Uchida created SOLR-14826: Summary: Clean up package name conflicts between modules (split packages) Key: SOLR-14826 URL: https://issues.apache.org/jira/browse/SOLR-14826 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: master (9.0) Reporter: Tomoko Uchida We have lots of package name conflicts (shared package names) between modules in the source tree. It is not only annoying for devs/users but also indeed bad practice since Java 9 (according to my understanding), and we already have some problems with Javadocs due to these splitted packages as some of us would know. Also split packages make migrating to the Java 9 module system impossible. This is the placeholder to fix all package name conflicts in Solr. See the dev list thread for more background. [https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E] Modules that need to be fixed / cleaned up: * velocity * analysis-extras * analytics * langid * solrj * (test-framework: this can be excluded for the moment) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
jpountz commented on a change in pull request #1824:
URL: https://github.com/apache/lucene-solr/pull/1824#discussion_r482963038
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene87/BugfixDeflater_JDK8252739.java
##
@@ -0,0 +1,102 @@
+/*
+ * 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.codecs.lucene87;
+
+import java.util.Arrays;
+import java.util.zip.DataFormatException;
+import java.util.zip.Deflater;
+import java.util.zip.Inflater;
+
+/**
+ * This class is a workaround for JDK bug
+ * https://bugs.openjdk.java.net/browse/JDK-8252739;>JDK-8252739.
+ */
+final class BugfixDeflater_JDK8252739 extends Deflater {
+
+ private final byte[] dictBytesScratch;
+
+ private BugfixDeflater_JDK8252739(int level, boolean nowrap, int dictLength)
{
+super(level, nowrap);
+this.dictBytesScratch = new byte[dictLength];
+ }
+
+ @Override
+ public void setDictionary(byte[] dictBytes, int off, int len) {
+if (off > 0) {
+ System.arraycopy(dictBytes, off, dictBytesScratch, 0, len);
+ super.setDictionary(dictBytesScratch, 0, len);
+} else {
+ super.setDictionary(dictBytes, off, len);
+}
+ }
+
+ public static Deflater createDeflaterInstance(int level, boolean nowrap, int
dictLength) {
+if (dictLength < 0) {
+ throw new IllegalArgumentException("dictLength must be >= 0");
+}
+if (IS_BUGGY_JDK) {
+ return new BugfixDeflater_JDK8252739(level, nowrap, dictLength);
+} else {
+ return new Deflater(level, nowrap);
+}
+ }
+
+ private static boolean detectBuggyJDK() {
+final byte[] testData = new byte[] { 1, 2, 3, 4, 5, 6, 7, 8 };
+final byte[] compressed = new byte[32]; // way enough space
+final Deflater deflater = new Deflater(6, true);
+try {
+ deflater.reset();
+ deflater.setDictionary(testData, 4, 4);
+ deflater.setInput(testData);
+ deflater.finish();
+ deflater.deflate(compressed, 0, compressed.length, Deflater.FULL_FLUSH);
+} finally {
+ deflater.end();
+}
+
+final Inflater inflater = new Inflater(true);
+final byte[] restored = new byte[testData.length];
+try {
+ inflater.reset();
+ inflater.setDictionary(testData, 4, 4);
+ inflater.setInput(compressed);
+ final int restoredLength = inflater.inflate(restored);
+ if (restoredLength != testData.length) {
+return true;
+ }
+} catch (DataFormatException e) {
+ return true;
+} finally {
+ inflater.end();
+}
+
+if (Arrays.equals(testData, restored) == false) {
+ return true;
+}
+
+// all fine
+return false;
+ }
Review comment:
likewise, nevermind
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.
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
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
jpountz commented on a change in pull request #1824:
URL: https://github.com/apache/lucene-solr/pull/1824#discussion_r482962830
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene87/BugfixDeflater_JDK8252739.java
##
@@ -0,0 +1,102 @@
+/*
+ * 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.codecs.lucene87;
+
+import java.util.Arrays;
+import java.util.zip.DataFormatException;
+import java.util.zip.Deflater;
+import java.util.zip.Inflater;
+
+/**
+ * This class is a workaround for JDK bug
+ * https://bugs.openjdk.java.net/browse/JDK-8252739;>JDK-8252739.
+ */
+final class BugfixDeflater_JDK8252739 extends Deflater {
+
+ private final byte[] dictBytesScratch;
+
+ private BugfixDeflater_JDK8252739(int level, boolean nowrap, int dictLength)
{
+super(level, nowrap);
+this.dictBytesScratch = new byte[dictLength];
+ }
+
+ @Override
+ public void setDictionary(byte[] dictBytes, int off, int len) {
+if (off > 0) {
+ System.arraycopy(dictBytes, off, dictBytesScratch, 0, len);
+ super.setDictionary(dictBytesScratch, 0, len);
+} else {
+ super.setDictionary(dictBytes, off, len);
+}
+ }
+
+ public static Deflater createDeflaterInstance(int level, boolean nowrap, int
dictLength) {
+if (dictLength < 0) {
+ throw new IllegalArgumentException("dictLength must be >= 0");
+}
+if (IS_BUGGY_JDK) {
+ return new BugfixDeflater_JDK8252739(level, nowrap, dictLength);
+} else {
+ return new Deflater(level, nowrap);
+}
+ }
+
+ private static boolean detectBuggyJDK() {
+final byte[] testData = new byte[] { 1, 2, 3, 4, 5, 6, 7, 8 };
+final byte[] compressed = new byte[32]; // way enough space
+final Deflater deflater = new Deflater(6, true);
+try {
+ deflater.reset();
+ deflater.setDictionary(testData, 4, 4);
+ deflater.setInput(testData);
+ deflater.finish();
+ deflater.deflate(compressed, 0, compressed.length, Deflater.FULL_FLUSH);
+} finally {
+ deflater.end();
+}
+
+final Inflater inflater = new Inflater(true);
+final byte[] restored = new byte[testData.length];
+try {
+ inflater.reset();
+ inflater.setDictionary(testData, 4, 4);
+ inflater.setInput(compressed);
+ final int restoredLength = inflater.inflate(restored);
+ if (restoredLength != testData.length) {
+return true;
+ }
+} catch (DataFormatException e) {
+ return true;
+} finally {
+ inflater.end();
+}
+
+if (Arrays.equals(testData, restored) == false) {
+ return true;
+}
+
+// all fine
+return false;
+ }
+
+ public static final boolean IS_BUGGY_JDK = detectBuggyJDK();
+
+ static {
+System.err.println("JDK is buggy: " + IS_BUGGY_JDK);
Review comment:
oops nevermind I just read your other 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.
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
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
jpountz commented on a change in pull request #1824:
URL: https://github.com/apache/lucene-solr/pull/1824#discussion_r482960153
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene87/BugfixDeflater_JDK8252739.java
##
@@ -0,0 +1,102 @@
+/*
+ * 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.codecs.lucene87;
+
+import java.util.Arrays;
+import java.util.zip.DataFormatException;
+import java.util.zip.Deflater;
+import java.util.zip.Inflater;
+
+/**
+ * This class is a workaround for JDK bug
+ * https://bugs.openjdk.java.net/browse/JDK-8252739;>JDK-8252739.
+ */
+final class BugfixDeflater_JDK8252739 extends Deflater {
+
+ private final byte[] dictBytesScratch;
+
+ private BugfixDeflater_JDK8252739(int level, boolean nowrap, int dictLength)
{
+super(level, nowrap);
+this.dictBytesScratch = new byte[dictLength];
+ }
+
+ @Override
+ public void setDictionary(byte[] dictBytes, int off, int len) {
+if (off > 0) {
+ System.arraycopy(dictBytes, off, dictBytesScratch, 0, len);
+ super.setDictionary(dictBytesScratch, 0, len);
+} else {
+ super.setDictionary(dictBytes, off, len);
+}
+ }
+
+ public static Deflater createDeflaterInstance(int level, boolean nowrap, int
dictLength) {
+if (dictLength < 0) {
+ throw new IllegalArgumentException("dictLength must be >= 0");
+}
+if (IS_BUGGY_JDK) {
+ return new BugfixDeflater_JDK8252739(level, nowrap, dictLength);
+} else {
+ return new Deflater(level, nowrap);
+}
+ }
+
+ private static boolean detectBuggyJDK() {
+final byte[] testData = new byte[] { 1, 2, 3, 4, 5, 6, 7, 8 };
+final byte[] compressed = new byte[32]; // way enough space
+final Deflater deflater = new Deflater(6, true);
+try {
+ deflater.reset();
+ deflater.setDictionary(testData, 4, 4);
+ deflater.setInput(testData);
+ deflater.finish();
+ deflater.deflate(compressed, 0, compressed.length, Deflater.FULL_FLUSH);
+} finally {
+ deflater.end();
+}
+
+final Inflater inflater = new Inflater(true);
+final byte[] restored = new byte[testData.length];
+try {
+ inflater.reset();
+ inflater.setDictionary(testData, 4, 4);
+ inflater.setInput(compressed);
+ final int restoredLength = inflater.inflate(restored);
+ if (restoredLength != testData.length) {
+return true;
+ }
+} catch (DataFormatException e) {
+ return true;
+} finally {
+ inflater.end();
+}
+
+if (Arrays.equals(testData, restored) == false) {
+ return true;
+}
+
+// all fine
+return false;
+ }
+
+ public static final boolean IS_BUGGY_JDK = detectBuggyJDK();
+
+ static {
+System.err.println("JDK is buggy: " + IS_BUGGY_JDK);
Review comment:
Did you only mean to use this for debugging?
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene87/BugfixDeflater_JDK8252739.java
##
@@ -0,0 +1,102 @@
+/*
+ * 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.codecs.lucene87;
+
+import java.util.Arrays;
+import java.util.zip.DataFormatException;
+import java.util.zip.Deflater;
+import java.util.zip.Inflater;
+
+/**
+ * This class is a workaround for JDK bug
+ * https://bugs.openjdk.java.net/browse/JDK-8252739;>JDK-8252739.
+ */
+final class BugfixDeflater_JDK8252739 extends Deflater {
+
+ private final
[GitHub] [lucene-solr] uschindler commented on pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
uschindler commented on pull request #1824: URL: https://github.com/apache/lucene-solr/pull/1824#issuecomment-686471292 I converted this to a draf, because checks failed with precommit. But this should stay in for doing quick checks by @jpountz like commented before! 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. 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
[GitHub] [lucene-solr] uschindler commented on pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
uschindler commented on pull request #1824: URL: https://github.com/apache/lucene-solr/pull/1824#issuecomment-686468187 Hi, I added detectction in my latest commit: ``` C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1>java -version openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1>gradlew -Ptests.verbose=true :lucene:core:test --tests TestLucene87StoredFieldsFormatHighCompression | grep buggy 2> JDK is buggy: false ``` vs. ``` C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1>java -version openjdk version "13" 2019-09-17 OpenJDK Runtime Environment (build 13+33) OpenJDK 64-Bit Server VM (build 13+33, mixed mode, sharing) C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1>gradlew -Ptests.verbose=true :lucene:core:test --tests TestLucene87StoredFieldsFormatHighCompression | grep buggy 2> JDK is buggy: true ``` The `System.err.println()` needs of course be removed before merge :-) 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. 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
[GitHub] [lucene-solr] uschindler commented on a change in pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
uschindler commented on a change in pull request #1824:
URL: https://github.com/apache/lucene-solr/pull/1824#discussion_r482952318
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene87/DeflateWithPresetDictCompressionMode.java
##
@@ -155,16 +155,15 @@ public Decompressor clone() {
private static class DeflateWithPresetDictCompressor extends Compressor {
-final byte[] dictBytes;
-final int blockLength;
+private final int dictLength, blockLength;
final Deflater compressor;
byte[] compressed;
boolean closed;
DeflateWithPresetDictCompressor(int level, int dictLength, int
blockLength) {
- compressor = new Deflater(level, true);
Review comment:
I added detection in latest commit. Works with 8 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.
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
[GitHub] [lucene-solr] uschindler commented on a change in pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
uschindler commented on a change in pull request #1824:
URL: https://github.com/apache/lucene-solr/pull/1824#discussion_r482923181
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene87/DeflateWithPresetDictCompressionMode.java
##
@@ -155,16 +155,15 @@ public Decompressor clone() {
private static class DeflateWithPresetDictCompressor extends Compressor {
-final byte[] dictBytes;
-final int blockLength;
+private final int dictLength, blockLength;
final Deflater compressor;
byte[] compressed;
boolean closed;
DeflateWithPresetDictCompressor(int level, int dictLength, int
blockLength) {
- compressor = new Deflater(level, true);
Review comment:
that's also my idea! I am working on probing at the moment. like 128
bytes of dict and 128 bytes of data. If result is correct the factory method i
implemented uses the plain Deflater instead of the workaround class.
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.
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
[GitHub] [lucene-solr] uschindler commented on a change in pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
uschindler commented on a change in pull request #1824:
URL: https://github.com/apache/lucene-solr/pull/1824#discussion_r482923181
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene87/DeflateWithPresetDictCompressionMode.java
##
@@ -155,16 +155,15 @@ public Decompressor clone() {
private static class DeflateWithPresetDictCompressor extends Compressor {
-final byte[] dictBytes;
-final int blockLength;
+private final int dictLength, blockLength;
final Deflater compressor;
byte[] compressed;
boolean closed;
DeflateWithPresetDictCompressor(int level, int dictLength, int
blockLength) {
- compressor = new Deflater(level, true);
Review comment:
that's also my idea! I am working on probing at the moment. like 128
bytes of dict and 128 bytes of data. If result is correct the factory method i
implemented uses the plain Deflater.
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.
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
[GitHub] [lucene-solr] dweiss commented on a change in pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
dweiss commented on a change in pull request #1824:
URL: https://github.com/apache/lucene-solr/pull/1824#discussion_r482922248
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene87/DeflateWithPresetDictCompressionMode.java
##
@@ -155,16 +155,15 @@ public Decompressor clone() {
private static class DeflateWithPresetDictCompressor extends Compressor {
-final byte[] dictBytes;
-final int blockLength;
+private final int dictLength, blockLength;
final Deflater compressor;
byte[] compressed;
boolean closed;
DeflateWithPresetDictCompressor(int level, int dictLength, int
blockLength) {
- compressor = new Deflater(level, true);
Review comment:
Just a thought, really.
If it's a bug that can be probed for (and it can be - see Adrian's repro)
then it could as well be a static initialization of a supplier of Deflater
instances; if we probe for a buggy JVM, we return the wrapper. If we don't we
return the Deflater. This way on non-affected JVMs nothing happens and if we do
use the wrapper, we know the JVM is broken.
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.
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
[GitHub] [lucene-solr] uschindler commented on pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
uschindler commented on pull request #1824: URL: https://github.com/apache/lucene-solr/pull/1824#issuecomment-686427056 This effectively reverts @jpountz's hotfix commit, but as he moved classes around in the meantime, I had to do it manually. 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. 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
[jira] [Assigned] (LUCENE-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reassigned LUCENE-9500: - Assignee: Uwe Schindler > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: master (9.0) >Reporter: Adrien Grand >Assignee: Uwe Schindler >Priority: Minor > Labels: Java13, Java14, Java15, java11, jdk11, jdk13, jdk14, > jdk15 > Attachments: PresetDictTest.java, test_data.txt > > Time Spent: 10m > Remaining Estimate: 0h > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190063#comment-17190063 ] Uwe Schindler commented on LUCENE-9500: --- Here is a pull request that separates the hack from the lucene code, this makes maintenance easier: https://github.com/apache/lucene-solr/pull/1824 We can now add conditions about Java versions to the factory method returning the Deflater instance. Interestingly in master we still have Constants.JDK_8 or JDK_7 (we need to remove, haha). > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: master (9.0) >Reporter: Adrien Grand >Priority: Minor > Labels: Java13, Java14, Java15, java11, jdk11, jdk13, jdk14, > jdk15 > Attachments: PresetDictTest.java, test_data.txt > > Time Spent: 10m > Remaining Estimate: 0h > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler opened a new pull request #1824: LUCENE-9500: Separate the Deflater hack from the Lucene code to a subclass of java.util.zip.Deflater
uschindler opened a new pull request #1824: URL: https://github.com/apache/lucene-solr/pull/1824 A factory method allows to return a different instance depending on Java version (for now everything after Java 11 is disallowed). We can improve this when we exactly know which versions are affected. Once the bug is fixed and Lucene uses a later minimum version, we can easily remove the class. TODO: We should add a forbiddenapis to disallow direct use of deflater by disallowing its constructor. 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. 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
[jira] [Commented] (LUCENE-9484) Allow index sorting to happen after the fact
[ https://issues.apache.org/jira/browse/LUCENE-9484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190053#comment-17190053 ] ASF subversion and git services commented on LUCENE-9484: - Commit a7bdc6893e21954ed9f6d8bce256a4a9c917310b in lucene-solr's branch refs/heads/branch_8x from Simon Willnauer [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a7bdc68 ] LUCENE-9484: Allow sorting an index after the fact (#1789) Today we need to decide on an index sorting before we create the index. In some situations it might make a lot of sense to sort an index afterwards when the index doesn't change anymore or to compress older indices. This change adds the ability to wrap readers from an unsorted index and merge it into a sorted index by using IW#addIndices. > Allow index sorting to happen after the fact > > > Key: LUCENE-9484 > URL: https://issues.apache.org/jira/browse/LUCENE-9484 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Simon Willnauer >Priority: Major > Time Spent: 2h 10m > Remaining Estimate: 0h > > I did look into sorting an index after it was created and found that with > some smallish modifications we can actually allow that by piggibacking on > SortingLeafReader and addIndices in a pretty straight-forward and simple way. > With some smallish modifications / fixes to SortingLeafReader we can just > merge and unsorted index into a sorted index using a fresh index writer. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] sigram edited a comment on pull request #1813: SOLR-14613: No new APIs. use the existing APIs
sigram edited a comment on pull request #1813: URL: https://github.com/apache/lucene-solr/pull/1813#issuecomment-686410621 > Honestly nobody will do that. People would rather happily do the computation in client code Really? This is like saying that we only ever need collection admin APIs and we don't need any autoscaling. That may be the case for some people, but not for others. Also, not everybody would go and implement their own plugin, instead they would likely use someone else's plugin that is known to work for a particular scenario. I think the opposite of what you said is true - the expectation is that Solr will behave in a sane way and automatically do what's needed to "properly" use available resources, without too much manual handholding. The problem is of course that the definition of "properly" depends on the point of view and the scale of the problem - that's why we're having the discussion about plugins at all. Take Salesforce's case for example: they had to hack around the existing AssignStrategy to implement their own, because the default ones didn't work for them. In the process they had to learn and mess around with a lot of Solr internals. It would have been clearly better if they could just implement it as an installable plugin, using an abstract API that doesn't expose too many Solr internals. Edit: oh, and obviously one of the valid strategies would be to rely on provided placements (basically a do-nothing-strategy), but having this option as a plugin with a clean API is clearly better than just a bunch of messy hardcoded conditionals. 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. 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
[jira] [Resolved] (LUCENE-9483) Disable per-thread caching of buffers for stored fields
[ https://issues.apache.org/jira/browse/LUCENE-9483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-9483. -- Resolution: Fixed > Disable per-thread caching of buffers for stored fields > --- > > Key: LUCENE-9483 > URL: https://issues.apache.org/jira/browse/LUCENE-9483 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Fix For: 8.7 > > Time Spent: 20m > Remaining Estimate: 0h > > Stored fields currently cache buffers that are used to decompress data. > However with one buffer per thread per segment, these buffers can start using > non-negligible amounts of data. > I think we should keep them for merges, but either remove them completely for > regular reads, or sharing them across all segments. As I'd like to avoid > relying on global threadlocals, I'm leaning towards removing them. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9486) Explore using preset dictionaries with LZ4 for stored fields
[ https://issues.apache.org/jira/browse/LUCENE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-9486. -- Fix Version/s: 8.7 Resolution: Fixed > Explore using preset dictionaries with LZ4 for stored fields > > > Key: LUCENE-9486 > URL: https://issues.apache.org/jira/browse/LUCENE-9486 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Fix For: 8.7 > > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of LUCENE-9447: using preset dictionaries with DEFLATE provided > very significant gains. Adding support for preset dictionaries with LZ4 would > be easy so let's give it a try? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] s1monw merged pull request #1789: LUCENE-9484: Allow sorting an index after the fact
s1monw merged pull request #1789: URL: https://github.com/apache/lucene-solr/pull/1789 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. 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
[GitHub] [lucene-solr] sigram commented on pull request #1813: SOLR-14613: No new APIs. use the existing APIs
sigram commented on pull request #1813: URL: https://github.com/apache/lucene-solr/pull/1813#issuecomment-686410621 > Honestly nobody will do that. People would rather happily do the computation in client code Really? This is like saying that we only ever need collection admin APIs and we don't need any autoscaling. That may be the case for some people, but not for others. Also, not everybody would go and implement their own plugin, instead they would likely use someone else's plugin that is known to work for a particular scenario. I think the opposite of what you said is true - the expectation is that Solr will behave in a sane way and automatically do what's needed to "properly" use available resources, without too much manual handholding. The problem is of course that the definition of "properly" depends on the point of view and the scale of the problem - that's why we're having the discussion about plugins at all. Take Salesforce's case for example: they had to hack around the existing AssignStrategy to implement their own, because the default ones didn't work for them. In the process they had to learn and mess around with a lot of Solr internals. It would have been clearly better if they could just implement it as an installable plugin, using an abstract API that doesn't expose too many Solr internals. 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. 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
[jira] [Commented] (LUCENE-9486) Explore using preset dictionaries with LZ4 for stored fields
[ https://issues.apache.org/jira/browse/LUCENE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190049#comment-17190049 ] ASF subversion and git services commented on LUCENE-9486: - Commit 4cedd92dee0ad1e9e3c8f655574d2af8ab1abd37 in lucene-solr's branch refs/heads/branch_8x from Adrien Grand [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4cedd92 ] LUCENE-9486: Use preset dictionaries with LZ4 for BEST_SPEED. (#1793) > Explore using preset dictionaries with LZ4 for stored fields > > > Key: LUCENE-9486 > URL: https://issues.apache.org/jira/browse/LUCENE-9486 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of LUCENE-9447: using preset dictionaries with DEFLATE provided > very significant gains. Adding support for preset dictionaries with LZ4 would > be easy so let's give it a try? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9486) Explore using preset dictionaries with LZ4 for stored fields
[ https://issues.apache.org/jira/browse/LUCENE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190048#comment-17190048 ] ASF subversion and git services commented on LUCENE-9486: - Commit 73371cb4b6365c4aca2700c2e14e20cdbf1e0c12 in lucene-solr's branch refs/heads/master from Adrien Grand [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=73371cb ] LUCENE-9486: Fix TestTieredMergePolicy failure. > Explore using preset dictionaries with LZ4 for stored fields > > > Key: LUCENE-9486 > URL: https://issues.apache.org/jira/browse/LUCENE-9486 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of LUCENE-9447: using preset dictionaries with DEFLATE provided > very significant gains. Adding support for preset dictionaries with LZ4 would > be easy so let's give it a try? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14819) SOLR has linear log operations that could trivially be linear
[ https://issues.apache.org/jira/browse/SOLR-14819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Roustant resolved SOLR-14819. --- Fix Version/s: 8.7 Resolution: Fixed Thanks Thomas for this fix. Please share the info about this detection tool in Lucene/Solr dev list ([https://lucene.apache.org/solr/community.html#mailing-lists-irc]) for a wider audience and discussion. Personally I find the report verbose, so I wonder how verbose it would be on a specific Jira issue. Clearly the difficulty is to avoid too much false detections. > SOLR has linear log operations that could trivially be linear > - > > Key: SOLR-14819 > URL: https://issues.apache.org/jira/browse/SOLR-14819 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Thomas DuBuisson >Priority: Trivial > Fix For: 8.7 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The SOLR code has a few linear log operations that could be linear. That is, > operations of > > ``` > for(key in hashmap) doThing(hashmap.get(key)); > > ``` > > vs just `for(value in hashmap) doThing(value)` > > I have a PR incoming on GitHub to fix a couple of these issue as [found by > Infer on > Muse|https://console.muse.dev/result/TomMD/lucene-solr/01EH5WXS6C1RH1NFYHP6ATXTZ9?search=JsonSchemaValidator=results]. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on pull request #1813: SOLR-14613: No new APIs. use the existing APIs
noblepaul commented on pull request #1813: URL: https://github.com/apache/lucene-solr/pull/1813#issuecomment-686400974 > However, for master/trunk we need a better design anyway. I would say that most users are actually happy if they do not have to implement a bunch of java interfaces, package a jar add it to Solr to just add a replica in the right place. Honestly nobody will do that. People would rather happily do the computation in client code and send that information as a input. If a DSL is available, they may use it. If not this will be of no interest to most users 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. 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
[jira] [Commented] (SOLR-14819) SOLR has linear log operations that could trivially be linear
[ https://issues.apache.org/jira/browse/SOLR-14819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190034#comment-17190034 ] ASF subversion and git services commented on SOLR-14819: Commit c8fcf1b5b301b1b83852ccc60f228f12833d8287 in lucene-solr's branch refs/heads/branch_8x from Bruno Roustant [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c8fcf1b ] SOLR-14819: Fix inefficient iterator pattern in JsonSchemaValidator. > SOLR has linear log operations that could trivially be linear > - > > Key: SOLR-14819 > URL: https://issues.apache.org/jira/browse/SOLR-14819 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Thomas DuBuisson >Priority: Trivial > Time Spent: 1h 10m > Remaining Estimate: 0h > > The SOLR code has a few linear log operations that could be linear. That is, > operations of > > ``` > for(key in hashmap) doThing(hashmap.get(key)); > > ``` > > vs just `for(value in hashmap) doThing(value)` > > I have a PR incoming on GitHub to fix a couple of these issue as [found by > Infer on > Muse|https://console.muse.dev/result/TomMD/lucene-solr/01EH5WXS6C1RH1NFYHP6ATXTZ9?search=JsonSchemaValidator=results]. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14588) Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker
[ https://issues.apache.org/jira/browse/SOLR-14588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190033#comment-17190033 ] Ishan Chattopadhyaya commented on SOLR-14588: - bq. Fixed configuration in https://github.com/apache/lucene-solr/commit/6a7da3cd508f5b1e445df08aa2f1fa926d586e99 [~atris], please use JIRA id in every commit (and not commit anything other than minor ref guide changes without a JIRA). Doing so not only ensures that some bot puts in a helpful comment here, but also helps us port issues to other branches (e.g. if someone needed this feature in 7x). > Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker > -- > > Key: SOLR-14588 > URL: https://issues.apache.org/jira/browse/SOLR-14588 > Project: Solr > Issue Type: Improvement >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Blocker > Fix For: master (9.0), 8.7 > > Time Spent: 13h 50m > Remaining Estimate: 0h > > This Jira tracks addition of circuit breakers in the search path and > implements JVM based circuit breaker which rejects incoming search requests > if the JVM heap usage exceeds a defined percentage. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8500) smokeTestRelease still expects KEYS file in distribution
[
https://issues.apache.org/jira/browse/LUCENE-8500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190032#comment-17190032
]
Adrien Grand commented on LUCENE-8500:
--
Woops, wrong JIRA, this should have been LUCENE-9500.
> smokeTestRelease still expects KEYS file in distribution
>
>
> Key: LUCENE-8500
> URL: https://issues.apache.org/jira/browse/LUCENE-8500
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Fix For: 7.5, 8.0
>
> Attachments: LUCENE-8500.patch
>
>
> KEYS file have been removed from the distribution (LUCENE-5143) but the maven
> verification in smokeTestRelease still refers to these files. The smoke tests
> failed with this exception:
> {code}
> rllib.error.URLError: '/Users/jimczi/Projects/lucene_7_5/release/lucene-solr-7.5.0-RC1-rev3b3d27574c424d5fccb6172dfa8f99584c41e56b/lucene/KEYS'>
> The above exception was the direct cause of the following exception:
> Traceback (most recent call last):
> File "dev-tools/scripts/smokeTestRelease.py", line 1530, in
> main()
> File "dev-tools/scripts/smokeTestRelease.py", line 1471, in main
> smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed,
> c.local_keys, ' '.join(c.test_args))
> File "dev-tools/scripts/smokeTestRelease.py", line 1524, in smokeTest
> checkMaven(solrSrcUnpackPath, baseURL, tmpDir, gitRevision, version,
> isSigned)
> File "dev-tools/scripts/smokeTestRelease.py", line 999, in checkMaven
> verifyMavenSigs(baseURL, tmpDir, artifacts)
> File "dev-tools/scripts/smokeTestRelease.py", line 1127, in verifyMavenSigs
> download('%s.KEYS' % project, keysURL, tmpDir, quiet=True)
> File "dev-tools/scripts/smokeTestRelease.py", line 128, in download
> raise RuntimeError('failed to download url "%s"' % urlString) from e
> RuntimeError: failed to download url
> "file:///Users/jimczi/Projects/lucene_7_5/release/lucene-solr-7.5.0-RC1-rev3b3d27574c424d5fccb6172dfa8f99584c41e56b/lucene/KEYS"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190030#comment-17190030 ] Adrien Grand commented on LUCENE-9500: -- [~uschindler] This code was backported already but not released yet indeed, which is why I didn't add a CHANGES entry for it. > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: master (9.0) >Reporter: Adrien Grand >Priority: Minor > Labels: Java13, Java14, Java15, java11, jdk11, jdk13, jdk14, > jdk15 > Attachments: PresetDictTest.java, test_data.txt > > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9486) Explore using preset dictionaries with LZ4 for stored fields
[ https://issues.apache.org/jira/browse/LUCENE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190029#comment-17190029 ] ASF subversion and git services commented on LUCENE-9486: - Commit 27aa5c5f59e8cb03316efa504f0351decd41d61c in lucene-solr's branch refs/heads/master from Adrien Grand [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=27aa5c5 ] LUCENE-9486: Use preset dictionaries with LZ4 for BEST_SPEED. (#1793) > Explore using preset dictionaries with LZ4 for stored fields > > > Key: LUCENE-9486 > URL: https://issues.apache.org/jira/browse/LUCENE-9486 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of LUCENE-9447: using preset dictionaries with DEFLATE provided > very significant gains. Adding support for preset dictionaries with LZ4 would > be easy so let's give it a try? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz merged pull request #1793: LUCENE-9486: Use preset dictionaries with LZ4 for BEST_SPEED.
jpountz merged pull request #1793: URL: https://github.com/apache/lucene-solr/pull/1793 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. 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
