[jira] [Commented] (SOLR-13806) SolrJ QueryResponse._explainMap is incorrectly typed
[
https://issues.apache.org/jira/browse/SOLR-13806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985497#comment-16985497
]
Guna Sekhar Dora commented on SOLR-13806:
-
[~ab] Added a draft PR at [https://github.com/apache/lucene-solr/pull/1048] for
now. I will have to check if this can be unit tested.
> SolrJ QueryResponse._explainMap is incorrectly typed
>
>
> Key: SOLR-13806
> URL: https://issues.apache.org/jira/browse/SOLR-13806
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: newdev
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This field, and the corresponding getter, and the code that extracts debug
> information from the NamedList response in {{extractDebugInfo}}, all use a
> {{Map}} type.
> However, when {{debug.explain.structured=true}} is used the values returned
> in response are not String-s, instead they are {{SimpleOrderedMap}}-s. This
> causes the following exception to be thrown:
> {code}
> java.lang.ClassCastException: class
> org.apache.solr.common.util.SimpleOrderedMap cannot be cast to class
> java.lang.String (org.apache.solr.common.util.SimpleOrderedMap is in unnamed
> module of loader 'app'; java.lang.String is in module java.base of loader
> 'bootstrap')
> at
> __randomizedtesting.SeedInfo.seed([1D6FB4036A639051:173F5FF19E860E6F]:0)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractDebugInfo(QueryResponse.java:246)
> at
> org.apache.solr.client.solrj.response.QueryResponse.setResponse(QueryResponse.java:143)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
> at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
> ...
> {code}
> The simple fix is to change the type of this field to {{Map}}
> but this would change the public API of {{QueryResponse.getExplainMap()}} in
> incompatible way. Still, I would argue it's worth to change it - AFAIK this
> getter is not used anywhere in the Solr's codebase, and the change makes it
> more consistent with other getters.
--
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-13759) Optimize Queries when query filtering by TRA router.field
[ https://issues.apache.org/jira/browse/SOLR-13759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mosh updated SOLR-13759: Status: Open (was: Patch Available) > Optimize Queries when query filtering by TRA router.field > - > > Key: SOLR-13759 > URL: https://issues.apache.org/jira/browse/SOLR-13759 > Project: Solr > Issue Type: Sub-task >Reporter: mosh >Assignee: Gus Heck >Priority: Minor > > We are currently testing TRA using Solr 7.7, having >300 shards in the alias, > with much growth in the coming months. > The "hot" data(in our case, more recent) will be stored on stronger > nodes(SSD, more RAM, etc). > A proposal of optimizing queries will be by filtering query by date range, by > that we will be able to querying the specific TRA collections taking > advantage of the TRA mechanism of partitioning data based on date. -- 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] rmuir commented on a change in pull request #1043: LUCENE-9071: Speed up BM25 scores.
rmuir commented on a change in pull request #1043: LUCENE-9071: Speed up BM25
scores.
URL: https://github.com/apache/lucene-solr/pull/1043#discussion_r352336609
##
File path: lucene/core/src/java/org/apache/lucene/util/MathUtil.java
##
@@ -165,4 +165,32 @@ public static double sumRelativeErrorBound(int numValues)
{
return (numValues - 1) * u;
}
+ /**
+ * If this returns {@code true} then it means that the sum {@code x + y}
+ * doesn't need rounding to fit in a float. This method assumes two positive
+ * floats. No assumptions can be made if this method returns {@code false}.
+ */
+ public static boolean isSumAccurate(float x, float y) {
+assert x >= 0;
+assert y >= 0;
+int xBits = Float.floatToRawIntBits(x);
+int yBits = Float.floatToRawIntBits(y);
+int minBits = Math.min(xBits, yBits);
+int maxBits = Math.max(xBits, yBits);
+int maxBiasedExp = maxBits >>> 23;
+int minBiasedExp = minBits >>> 23;
+// The result of the sum will have an exponent that is equal to the
+// exponent of the maximum value, or the exponent of the maximum value plus
+// one. So if we can do a lossless conversion of both numbers to a float
+// that has the maximum exponent plus one as an exponent, then the sum is
+// accurate.
+int expDelta = maxBiasedExp - minBiasedExp;
+final boolean accurate = (maxBits & 0x01) == 0 &&
+// beware of overflows, a biased exponent of 254 is the greatest
exponent that is not Infinity or NaN
+maxBiasedExp < 254 &&
+expDelta <= 22 &&
+Integer.numberOfTrailingZeros(minBits) > expDelta;
+return accurate;
+ }
Review comment:
i have a tough time believing its worth it to do all this stuff to save a
cast to float. Are you sure benchmarks are working correctly? I think we should
also consider complexity as well...
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13759) Optimize Queries when query filtering by TRA router.field
[ https://issues.apache.org/jira/browse/SOLR-13759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mosh updated SOLR-13759: Attachment: SOLR-13759.patch > Optimize Queries when query filtering by TRA router.field > - > > Key: SOLR-13759 > URL: https://issues.apache.org/jira/browse/SOLR-13759 > Project: Solr > Issue Type: Sub-task >Reporter: mosh >Assignee: Gus Heck >Priority: Minor > Attachments: SOLR-13759.patch > > > We are currently testing TRA using Solr 7.7, having >300 shards in the alias, > with much growth in the coming months. > The "hot" data(in our case, more recent) will be stored on stronger > nodes(SSD, more RAM, etc). > A proposal of optimizing queries will be by filtering query by date range, by > that we will be able to querying the specific TRA collections taking > advantage of the TRA mechanism of partitioning data based on date. -- 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-13759) Optimize Queries when query filtering by TRA router.field
[ https://issues.apache.org/jira/browse/SOLR-13759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mosh updated SOLR-13759: Status: Patch Available (was: Open) > Optimize Queries when query filtering by TRA router.field > - > > Key: SOLR-13759 > URL: https://issues.apache.org/jira/browse/SOLR-13759 > Project: Solr > Issue Type: Sub-task >Reporter: mosh >Assignee: Gus Heck >Priority: Minor > Attachments: SOLR-13759.patch > > > We are currently testing TRA using Solr 7.7, having >300 shards in the alias, > with much growth in the coming months. > The "hot" data(in our case, more recent) will be stored on stronger > nodes(SSD, more RAM, etc). > A proposal of optimizing queries will be by filtering query by date range, by > that we will be able to querying the specific TRA collections taking > advantage of the TRA mechanism of partitioning data based on date. -- 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-13759) Optimize Queries when query filtering by TRA router.field
[ https://issues.apache.org/jira/browse/SOLR-13759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985544#comment-16985544 ] mosh commented on SOLR-13759: - [~gus], You are right, fixed it! The attached patch is ready for review. thanks! > Optimize Queries when query filtering by TRA router.field > - > > Key: SOLR-13759 > URL: https://issues.apache.org/jira/browse/SOLR-13759 > Project: Solr > Issue Type: Sub-task >Reporter: mosh >Assignee: Gus Heck >Priority: Minor > Attachments: SOLR-13759.patch > > > We are currently testing TRA using Solr 7.7, having >300 shards in the alias, > with much growth in the coming months. > The "hot" data(in our case, more recent) will be stored on stronger > nodes(SSD, more RAM, etc). > A proposal of optimizing queries will be by filtering query by date range, by > that we will be able to querying the specific TRA collections taking > advantage of the TRA mechanism of partitioning data based on date. -- 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-13988) Harden CreateCollectionCleanupTest
[
https://issues.apache.org/jira/browse/SOLR-13988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985575#comment-16985575
]
Lucene/Solr QA commented on SOLR-13988:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 3m 32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 3m 32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 3m 32s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 87m
20s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 98m 36s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13988 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12987223/SOLR-13988.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 5a69734 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/607/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/607/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Harden CreateCollectionCleanupTest
> --
>
> Key: SOLR-13988
> URL: https://issues.apache.org/jira/browse/SOLR-13988
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-13988.patch
>
>
> This test counts on being unable to create
> {code}
> /some_invalid_dir/foo
> {code}
> And if it does somehow succeed, it'll affect the filesystem (which it
> apparently can at least on Windows under some circumstances and maybe Unix if
> you're super-user).
> It seems safer to create a temp dir and explicitly disable write permissions
> on it and use that instead. See attached patch. While I don't have a Windows
> machine to test on, the javadocs assure me that I can disable write perms
> this way on Windows...
> [~anshum][~tflobbe] Does this seem OK to you?
--
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-8674) UnsupportedOperationException due to call to o.a.l.q.f.FunctionValues.floatVal
[
https://issues.apache.org/jira/browse/LUCENE-8674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985585#comment-16985585
]
Rahul Yadav commented on LUCENE-8674:
-
I was able to reproduce the issue.Getting the exception as described.
Analysis on-going
> UnsupportedOperationException due to call to o.a.l.q.f.FunctionValues.floatVal
> --
>
> Key: LUCENE-8674
> URL: https://issues.apache.org/jira/browse/LUCENE-8674
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/query/scoring
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection and reproducing the bug
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html].
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> curl -v “URL_BUG”
> {noformat}
> Please check the issue description below to find the “URL_BUG” that will
> allow you to reproduce the issue reported.
>Reporter: Johannes Kloos
>Priority: Minor
> Labels: diffblue, newdev
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?fq={!frange%20l=10%20u=100}or_version_s,directed_by
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.UnsupportedOperationException
> at
> org.apache.lucene.queries.function.FunctionValues.floatVal(FunctionValues.java:47)
> at
> org.apache.lucene.queries.function.FunctionValues$3.matches(FunctionValues.java:188)
> at
> org.apache.lucene.queries.function.ValueSourceScorer$1.matches(ValueSourceScorer.java:53)
> at
> org.apache.lucene.search.TwoPhaseIterator$TwoPhaseIteratorAsDocIdSetIterator.doNext(TwoPhaseIterator.java:89)
> at
> org.apache.lucene.search.TwoPhaseIterator$TwoPhaseIteratorAsDocIdSetIterator.nextDoc(TwoPhaseIterator.java:77)
> at org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:261)
> at org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:214)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:652)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:443)
> at org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:151)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:140)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1177)
> at
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:817)
> at
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1025)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1540)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1420)
> at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:567)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1434)
> {noformat}
> Sadly, I can't understand the logic of this code well enough to give any
> insights.
> To set up an environment to reproduce this bug, follow the description in the
> ‘Environment’ field.
> We found this issue and ~70 more like this using [Diffblue Microservices
> Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. Find more
> information on this [fuzz testing
> campaign|https://www.diffb
[jira] [Updated] (SOLR-13986) remove "execute" permission from solr-tests.policy
[ https://issues.apache.org/jira/browse/SOLR-13986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-13986: --- Attachment: SOLR-13986.patch > remove "execute" permission from solr-tests.policy > -- > > Key: SOLR-13986 > URL: https://issues.apache.org/jira/browse/SOLR-13986 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-13986-notyet.patch, SOLR-13986.patch, > SOLR-13986.patch, SOLR-13986.patch, SOLR-13986.patch > > > If we don't really need to execute processes, we can take the permission > away. That way any attempt to execute something results in a > SecurityException rather than running a process. > It is necessary to first fix the tests policy before thinking about > supporting securitymanager in solr. This way we can ensure functionality does > not break via our tests. -- 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-13986) remove "execute" permission from solr-tests.policy
[ https://issues.apache.org/jira/browse/SOLR-13986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985608#comment-16985608 ] Robert Muir commented on SOLR-13986: I worked my way thru all the slow/nightly tests with the current patch until everything was happy. the holes we have to punch for hadoop aren't pretty, but there really aren't many alternatives: * can't just grant execute to hadoop JAR only because it doesn't use doPriviledged or anything like that. * can't just whitelist certain executables because in most cases hadoop uses an unqualified path (e.g. $PATH), so it requires <> * can't just whitelist hadoop Shell stuff because it would just be a different vector for RCE (e.g. attacker use Shell instead of ProcessBuilder) So I only punched very specific holes to try to minimize risks, while keeping hadoop stuff still working. Still, its not good that these holes are needed for all solr users whether they use hadoop or not, so SOLR-13989 is a good one to solve. I can't promise no test will fail with this patch (I only ran tests over and over on mac), but I think its a good step. We can let jenkins do its thing, if there are terribly surprises we can revert the commit until they are figured out. > remove "execute" permission from solr-tests.policy > -- > > Key: SOLR-13986 > URL: https://issues.apache.org/jira/browse/SOLR-13986 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-13986-notyet.patch, SOLR-13986.patch, > SOLR-13986.patch, SOLR-13986.patch, SOLR-13986.patch > > > If we don't really need to execute processes, we can take the permission > away. That way any attempt to execute something results in a > SecurityException rather than running a process. > It is necessary to first fix the tests policy before thinking about > supporting securitymanager in solr. This way we can ensure functionality does > not break via our tests. -- 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-13988) Harden CreateCollectionCleanupTest
[
https://issues.apache.org/jira/browse/SOLR-13988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985615#comment-16985615
]
Dawid Weiss commented on SOLR-13988:
This is currently super annoying. An alternative take would be to create a
valid temp location (folder) and just append a non-existent subfolder to it.
> Harden CreateCollectionCleanupTest
> --
>
> Key: SOLR-13988
> URL: https://issues.apache.org/jira/browse/SOLR-13988
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-13988.patch
>
>
> This test counts on being unable to create
> {code}
> /some_invalid_dir/foo
> {code}
> And if it does somehow succeed, it'll affect the filesystem (which it
> apparently can at least on Windows under some circumstances and maybe Unix if
> you're super-user).
> It seems safer to create a temp dir and explicitly disable write permissions
> on it and use that instead. See attached patch. While I don't have a Windows
> machine to test on, the javadocs assure me that I can disable write perms
> this way on Windows...
> [~anshum][~tflobbe] Does this seem OK to you?
--
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-13988) Harden CreateCollectionCleanupTest
[
https://issues.apache.org/jira/browse/SOLR-13988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985661#comment-16985661
]
Erick Erickson commented on SOLR-13988:
---
bq. An alternative take would be to create a valid temp location...
That's the first thing I tried. The intermediate sub-folders apparently get
created (at least on my mac) and no exception gets thrown so the test fails as
written. It's an open question whether this change is true to the spirit of the
test though.
Do you see a problem with changing permissions?
> Harden CreateCollectionCleanupTest
> --
>
> Key: SOLR-13988
> URL: https://issues.apache.org/jira/browse/SOLR-13988
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-13988.patch
>
>
> This test counts on being unable to create
> {code}
> /some_invalid_dir/foo
> {code}
> And if it does somehow succeed, it'll affect the filesystem (which it
> apparently can at least on Windows under some circumstances and maybe Unix if
> you're super-user).
> It seems safer to create a temp dir and explicitly disable write permissions
> on it and use that instead. See attached patch. While I don't have a Windows
> machine to test on, the javadocs assure me that I can disable write perms
> this way on Windows...
> [~anshum][~tflobbe] Does this seem OK to you?
--
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-11706) JSON FacetModule can't compute stats (min,max,etc...) on multivalued fields
[ https://issues.apache.org/jira/browse/SOLR-11706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985664#comment-16985664 ] Mikhail Khludnev commented on SOLR-11706: - +1 > JSON FacetModule can't compute stats (min,max,etc...) on multivalued fields > --- > > Key: SOLR-11706 > URL: https://issues.apache.org/jira/browse/SOLR-11706 > Project: Solr > Issue Type: Bug > Components: Facet Module >Reporter: Chris M. Hostetter >Priority: Major > Attachments: SOLR-11706.patch, SOLR-11706.patch, SOLR-11706.patch, > SOLR-11706.patch, SOLR-11706.patch > > > While trying to write some tests demonstrating equivalences between the > StatsComponent and the JSON FacetModule i discovered that the FacetModules > stat functions (min, max, etc...) don't seem to work on multivalued fields. > Based on the stack traces, i gather the problem is because the FacetModule > seems to rely exclusively on using the "Function" parsers to get a value > source -- apparently w/o any other method of accumulating numeric stats from > multivalued (numeric) DocValues? -- 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-9073) IntervalQuery to respond field on toString and explain
[ https://issues.apache.org/jira/browse/LUCENE-9073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9073: - Status: Patch Available (was: Open) > IntervalQuery to respond field on toString and explain > -- > > Key: LUCENE-9073 > URL: https://issues.apache.org/jira/browse/LUCENE-9073 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/queries >Reporter: Mikhail Khludnev >Priority: Minor > Attachments: LUCENE-9073.patch > > > It seems like IntervalQuery doesnt' expose the field whether on toString() > nor via explain(). I think it's worth to return field for better visibility. > WDYT, [~romseygeek] ? -- 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-13988) Harden CreateCollectionCleanupTest
[
https://issues.apache.org/jira/browse/SOLR-13988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985667#comment-16985667
]
Dawid Weiss commented on SOLR-13988:
Theoretically the filesystem may not sport permissions... but it's unlikely so
I wouldn't worry about it.
> Harden CreateCollectionCleanupTest
> --
>
> Key: SOLR-13988
> URL: https://issues.apache.org/jira/browse/SOLR-13988
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-13988.patch
>
>
> This test counts on being unable to create
> {code}
> /some_invalid_dir/foo
> {code}
> And if it does somehow succeed, it'll affect the filesystem (which it
> apparently can at least on Windows under some circumstances and maybe Unix if
> you're super-user).
> It seems safer to create a temp dir and explicitly disable write permissions
> on it and use that instead. See attached patch. While I don't have a Windows
> machine to test on, the javadocs assure me that I can disable write perms
> this way on Windows...
> [~anshum][~tflobbe] Does this seem OK to you?
--
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] mkhludnev commented on issue #1045: LUCENE-9072: Find matching terms from Matches API
mkhludnev commented on issue #1045: LUCENE-9072: Find matching terms from Matches API URL: https://github.com/apache/lucene-solr/pull/1045#issuecomment-560154486 notice precommit failure 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13966) LatLonDocValuesField returns unparseable data
[ https://issues.apache.org/jira/browse/SOLR-13966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985689#comment-16985689 ] Thomas Wöckinger commented on SOLR-13966: - [~dsmiley] Did you already have time to look at the changes? > LatLonDocValuesField returns unparseable data > - > > Key: SOLR-13966 > URL: https://issues.apache.org/jira/browse/SOLR-13966 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Schema and Analysis, UpdateRequestProcessors >Affects Versions: master (9.0), 8.3, 8.3.1 >Reporter: Thomas Wöckinger >Assignee: David Smiley >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > LatLonDocValuesField is used by LatLonPointSpatialField field type to store > doc values. It does this by encoding the two double values into a long. If > the field is part of a document which takes place within a atomic update > operation RealTimeGetComponent is used to load the field values from the > index. > If the request is a nested request (line number 654: isNestedRequest is set > by DistributedUpdateProcessor to Resolution.ROOT_WITH_CHILDREN) all field > values from the schema are copied into a SolrInputDocument (line 678). > The copy is implemented by toSolrInputDocument method (line 728 of > RealTimeGetComponent). The method retrieves the FieldType of the SchemaField > and calls the toObject method (line 740). In case of LatLonPointSpatialField > type, when docValues is set to true and stored is set to false, the fieldData > is stored by a LatLonDocValuesField instance. > The toObject method is implemented by the base class FieldType toExternal > with the LatLonDocValuesField instance (line 373). In line 359 the method > stringValue of the Field is called. The default implementation (line 259) > checks if the fieldsData is either CharSequence or a Number and calls > fieldsData.toString. > Because fieldsData is of type Long in LatLonDocValuesField class the value is > not decoded correctly. > From my opinion LatLonDocValuesField must implement (override) the > stringValue method and return the decoded value. > > -- 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-13897) Unsafe publication of Terms object in ZkShardTerms
[
https://issues.apache.org/jira/browse/SOLR-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985795#comment-16985795
]
Lucene/Solr QA commented on SOLR-13897:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
2s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 1s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 44m
51s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 48m 40s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13897 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12987232/SOLR-13897.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 5a697344ed1 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/608/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/608/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Unsafe publication of Terms object in ZkShardTerms
> --
>
> Key: SOLR-13897
> URL: https://issues.apache.org/jira/browse/SOLR-13897
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.2, 8.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (9.0), 8.4
>
> Attachments: SOLR-13897.patch, SOLR-13897.patch, SOLR-13897.patch
>
>
> The Terms object in ZkShardTerms is written using a write lock but reading is
> allowed freely. This is not safe and can cause visibility issues and
> associated race conditions under contention.
--
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] [Issue Comment Deleted] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-11960: Comment: was deleted (was: I like this..) > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature >Reporter: Peter Rusko >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Blocker > Fix For: 7.3, 8.0 > > Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, > SOLR-11960.patch, SOLR-11960.patch, SOLR-11960_2.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- 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] [Issue Comment Deleted] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-11960: Comment: was deleted (was: I like your content very much. I wanted this only. I have seen it many times, I used to get the answer on your website. Well! let me tell you. I work at [Allegiant Airlines|https://airlinesreservation.org/allegiant-airlines/] If you ever want to book tickets in the future, Contact Us.) > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature >Reporter: Peter Rusko >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Blocker > Fix For: 7.3, 8.0 > > Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, > SOLR-11960.patch, SOLR-11960.patch, SOLR-11960_2.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- 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-7798) Improve robustness of ExpandComponent
[
https://issues.apache.org/jira/browse/SOLR-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985848#comment-16985848
]
Munendra S N commented on SOLR-7798:
Thanks [~mgibney] for the ping and pr. I will look into this
> Improve robustness of ExpandComponent
> -
>
> Key: SOLR-7798
> URL: https://issues.apache.org/jira/browse/SOLR-7798
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
>Reporter: Jörg Rathlev
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: expand-component.patch, expand-npe.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{ExpandComponent}} causes a {{NullPointerException}} if accidentally
> used without prior collapsing of results.
> If there are multiple documents in the result which have the same term value
> in the expand field, the size of the {{ordBytes}}/{{groupSet}} differs from
> the {{count}} value, and the {{getGroupQuery}} method creates an incompletely
> filled {{bytesRef}} array, which later causes a {{NullPointerException}} when
> trying to sort the terms.
> The attached patch extends the test to demonstrate the error, and modifies
> the {{getGroupQuery}} methods to create the array based on the size of the
> input maps.
--
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
