[jira] [Created] (SOLR-14108) Package Manager: verify command should be optional
Ishan Chattopadhyaya created SOLR-14108: --- Summary: Package Manager: verify command should be optional Key: SOLR-14108 URL: https://issues.apache.org/jira/browse/SOLR-14108 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Ishan Chattopadhyaya The command to verify a package after deployment should be made optional. It was originally intended to be that way, but got missed out in the implementation. The workaround for now is to have a condition in the verify command that always evaluates to true :-( -- 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-6678) jdk1.9.0-ea-b72 JVM failures
[ https://issues.apache.org/jira/browse/LUCENE-6678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998913#comment-16998913 ] Dawid Weiss commented on LUCENE-6678: - I just have. We won't go back to it. > jdk1.9.0-ea-b72 JVM failures > > > Key: LUCENE-6678 > URL: https://issues.apache.org/jira/browse/LUCENE-6678 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Trivial > Attachments: hs_err_pid7402.log, hs_err_pid7407.log, > hs_err_pid7408.log, hs_err_pid7608.log > > > A placeholder for JDK1.9.0-ea-b72 failures. > Linked issues: > [8129961 : SIGSEGV when copying to survivor space] > https://bugs.openjdk.java.net/browse/JDK-8129961 -- 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-6678) jdk1.9.0-ea-b72 JVM failures
[ https://issues.apache.org/jira/browse/LUCENE-6678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-6678. - Resolution: Cannot Reproduce > jdk1.9.0-ea-b72 JVM failures > > > Key: LUCENE-6678 > URL: https://issues.apache.org/jira/browse/LUCENE-6678 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Trivial > Attachments: hs_err_pid7402.log, hs_err_pid7407.log, > hs_err_pid7408.log, hs_err_pid7608.log > > > A placeholder for JDK1.9.0-ea-b72 failures. > Linked issues: > [8129961 : SIGSEGV when copying to survivor space] > https://bugs.openjdk.java.net/browse/JDK-8129961 -- 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-13749) Implement support for joining across collections with multiple shards ( XCJF )
[
https://issues.apache.org/jira/browse/SOLR-13749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998915#comment-16998915
]
ASF subversion and git services commented on SOLR-13749:
Commit 46e5e1372870f6b46925a86ec7c0461c7cb888bb in lucene-solr's branch
refs/heads/master from Gus Heck
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=46e5e13 ]
SOLR-13749 Cross collection join filter (XCJF)
Squashed commit of the following: commit
ffa68a8adb9c5dc16578ab26f731da247533c980
> Implement support for joining across collections with multiple shards ( XCJF )
> --
>
> Key: SOLR-13749
> URL: https://issues.apache.org/jira/browse/SOLR-13749
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Kevin Watters
>Assignee: Gus Heck
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This ticket includes 2 query parsers.
> The first one is the "Cross collection join filter" (XCJF) parser. This is
> the "Cross-collection join filter" query parser. It can do a call out to a
> remote collection to get a set of join keys to be used as a filter against
> the local collection.
> The second one is the Hash Range query parser that you can specify a field
> name and a hash range, the result is that only the documents that would have
> hashed to that range will be returned.
> This query parser will do an intersection based on join keys between 2
> collections.
> The local collection is the collection that you are searching against.
> The remote collection is the collection that contains the join keys that you
> want to use as a filter.
> Each shard participating in the distributed request will execute a query
> against the remote collection. If the local collection is setup with the
> compositeId router to be routed on the join key field, a hash range query is
> applied to the remote collection query to only match the documents that
> contain a potential match for the documents that are in the local shard/core.
>
>
> Here's some vocab to help with the descriptions of the various parameters.
> ||Term||Description||
> |Local Collection|This is the main collection that is being queried.|
> |Remote Collection|This is the collection that the XCJFQuery will query to
> resolve the join keys.|
> |XCJFQuery|The lucene query that executes a search to get back a set of join
> keys from a remote collection|
> |HashRangeQuery|The lucene query that matches only the documents whose hash
> code on a field falls within a specified range.|
>
>
> ||Param ||Required ||Description||
> |collection|Required|The name of the external Solr collection to be queried
> to retrieve the set of join key values ( required )|
> |zkHost|Optional|The connection string to be used to connect to Zookeeper.
> zkHost and solrUrl are both optional parameters, and at most one of them
> should be specified.
> If neither of zkHost or solrUrl are specified, the local Zookeeper cluster
> will be used. ( optional )|
> |solrUrl|Optional|The URL of the external Solr node to be queried ( optional
> )|
> |from|Required|The join key field name in the external collection ( required
> )|
> |to|Required|The join key field name in the local collection|
> |v|See Note|The query to be executed against the external Solr collection to
> retrieve the set of join key values.
> Note: The original query can be passed at the end of the string or as the
> "v" parameter.
> It's recommended to use query parameter substitution with the "v" parameter
> to ensure no issues arise with the default query parsers.|
> |routed| |true / false. If true, the XCJF query will use each shard's hash
> range to determine the set of join keys to retrieve for that shard.
> This parameter improves the performance of the cross-collection join, but
> it depends on the local collection being routed by the toField. If this
> parameter is not specified,
> the XCJF query will try to determine the correct value automatically.|
> |ttl| |The length of time that an XCJF query in the cache will be considered
> valid, in seconds. Defaults to 3600 (one hour).
> The XCJF query will not be aware of changes to the remote collection, so
> if the remote collection is updated, cached XCJF queries may give inaccurate
> results.
> After the ttl period has expired, the XCJF query will re-execute the join
> against the remote collection.|
> |_All others_| |Any normal Solr parameter can also be specified as a local
> param.|
>
> Example Solr Config.xml changes:
>
> {{<}}{{cache}} {{name}}{{=}}{{"hash_vin"}}
> {{ }}{{class}}{{=}}{{"solr.LRUCache"}}
> {{ }}{{size}}{{=}}{{"128"}}
> {{ }}{{i
[jira] [Commented] (SOLR-14103) hadoop-minicluster dependency is not used anywhere?
[ https://issues.apache.org/jira/browse/SOLR-14103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998917#comment-16998917 ] Dawid Weiss commented on SOLR-14103: I have explored it by running all tests... Ok, I didn't run nightlies or monsters. Windows is my preferred work environment but that doesn't mean I'm using it for running tests (they're flaky) -- all tests pass on Linux without these dependencies (and since they've been missing from the gradle build since the beginning I'm guessing they were never needed). Netty packages are imported from solrj and solr-core depends on it. I am applying this patch to master. Things need a shakeup to see what is actually used. Please ping me if something starts to fail because of this. > hadoop-minicluster dependency is not used anywhere? > --- > > Key: SOLR-14103 > URL: https://issues.apache.org/jira/browse/SOLR-14103 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Priority: Major > > Hmm... hadoop-minicluster is a dependency. Strangely I don't declare it in > Gradle build and it's just fine. Is this something required? Maybe we can get > rid of it on ant side 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-14092) Deprecate BlockJoinFacetComponent&BlockJoinDocSetFacetComponent in 8.5
[ https://issues.apache.org/jira/browse/SOLR-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998918#comment-16998918 ] ASF subversion and git services commented on SOLR-14092: Commit cc00e1dcef727653224c95072ea76a169bd9cbed in lucene-solr's branch refs/heads/branch_8x from Mikhail Khludnev [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cc00e1d ] SOLR-14092: Mark BlockJoinFacetComponent as deprecated. > Deprecate BlockJoinFacetComponent&BlockJoinDocSetFacetComponent in 8.5 > -- > > Key: SOLR-14092 > URL: https://issues.apache.org/jira/browse/SOLR-14092 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Attachments: SOLR-14092.branch_8x.00.patch > > > Please migrate to SOLR-8998 and SOLR-9510 -- 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-13749) Implement support for joining across collections with multiple shards ( XCJF )
[
https://issues.apache.org/jira/browse/SOLR-13749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck resolved SOLR-13749.
-
Fix Version/s: master (9.0)
Resolution: Implemented
Committed to master with above tweak and a correction to unit tests that I
found at the last minute, plus a little bit of wordsmithing in the docs.
Possibly could be talked into porting it back to 8.5 if folks think it's worth
the effort.
> Implement support for joining across collections with multiple shards ( XCJF )
> --
>
> Key: SOLR-13749
> URL: https://issues.apache.org/jira/browse/SOLR-13749
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Kevin Watters
>Assignee: Gus Heck
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This ticket includes 2 query parsers.
> The first one is the "Cross collection join filter" (XCJF) parser. This is
> the "Cross-collection join filter" query parser. It can do a call out to a
> remote collection to get a set of join keys to be used as a filter against
> the local collection.
> The second one is the Hash Range query parser that you can specify a field
> name and a hash range, the result is that only the documents that would have
> hashed to that range will be returned.
> This query parser will do an intersection based on join keys between 2
> collections.
> The local collection is the collection that you are searching against.
> The remote collection is the collection that contains the join keys that you
> want to use as a filter.
> Each shard participating in the distributed request will execute a query
> against the remote collection. If the local collection is setup with the
> compositeId router to be routed on the join key field, a hash range query is
> applied to the remote collection query to only match the documents that
> contain a potential match for the documents that are in the local shard/core.
>
>
> Here's some vocab to help with the descriptions of the various parameters.
> ||Term||Description||
> |Local Collection|This is the main collection that is being queried.|
> |Remote Collection|This is the collection that the XCJFQuery will query to
> resolve the join keys.|
> |XCJFQuery|The lucene query that executes a search to get back a set of join
> keys from a remote collection|
> |HashRangeQuery|The lucene query that matches only the documents whose hash
> code on a field falls within a specified range.|
>
>
> ||Param ||Required ||Description||
> |collection|Required|The name of the external Solr collection to be queried
> to retrieve the set of join key values ( required )|
> |zkHost|Optional|The connection string to be used to connect to Zookeeper.
> zkHost and solrUrl are both optional parameters, and at most one of them
> should be specified.
> If neither of zkHost or solrUrl are specified, the local Zookeeper cluster
> will be used. ( optional )|
> |solrUrl|Optional|The URL of the external Solr node to be queried ( optional
> )|
> |from|Required|The join key field name in the external collection ( required
> )|
> |to|Required|The join key field name in the local collection|
> |v|See Note|The query to be executed against the external Solr collection to
> retrieve the set of join key values.
> Note: The original query can be passed at the end of the string or as the
> "v" parameter.
> It's recommended to use query parameter substitution with the "v" parameter
> to ensure no issues arise with the default query parsers.|
> |routed| |true / false. If true, the XCJF query will use each shard's hash
> range to determine the set of join keys to retrieve for that shard.
> This parameter improves the performance of the cross-collection join, but
> it depends on the local collection being routed by the toField. If this
> parameter is not specified,
> the XCJF query will try to determine the correct value automatically.|
> |ttl| |The length of time that an XCJF query in the cache will be considered
> valid, in seconds. Defaults to 3600 (one hour).
> The XCJF query will not be aware of changes to the remote collection, so
> if the remote collection is updated, cached XCJF queries may give inaccurate
> results.
> After the ttl period has expired, the XCJF query will re-execute the join
> against the remote collection.|
> |_All others_| |Any normal Solr parameter can also be specified as a local
> param.|
>
> Example Solr Config.xml changes:
>
> {{<}}{{cache}} {{name}}{{=}}{{"hash_vin"}}
> {{ }}{{class}}{{=}}{{"solr.LRUCache"}}
> {{ }}{{size}}{{=}}{{"128"}}
> {{ }}{{initialSize}}{{=}}{{"0"}}
> {{ }}{{regenerator}}{{=}}{{"sol
[jira] [Updated] (SOLR-14092) Deprecate BlockJoinFacetComponent&BlockJoinDocSetFacetComponent in 8.5
[ https://issues.apache.org/jira/browse/SOLR-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-14092: Fix Version/s: 8.5 > Deprecate BlockJoinFacetComponent&BlockJoinDocSetFacetComponent in 8.5 > -- > > Key: SOLR-14092 > URL: https://issues.apache.org/jira/browse/SOLR-14092 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.5 > > Attachments: SOLR-14092.branch_8x.00.patch > > > Please migrate to SOLR-8998 and SOLR-9510 -- 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-14051) Remove BlockJoinFacetComponent&BlockJoinDocSetFacetComponent in 9.0
[ https://issues.apache.org/jira/browse/SOLR-14051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-14051: Fix Version/s: master (9.0) > Remove BlockJoinFacetComponent&BlockJoinDocSetFacetComponent in 9.0 > --- > > Key: SOLR-14051 > URL: https://issues.apache.org/jira/browse/SOLR-14051 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-14051.patch > > > Please migrate to SOLR-8998 and SOLR-9510 -- 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-14051) Remove BlockJoinFacetComponent&BlockJoinDocSetFacetComponent in 9.0
[ https://issues.apache.org/jira/browse/SOLR-14051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998922#comment-16998922 ] ASF subversion and git services commented on SOLR-14051: Commit b0e532b7f32c1822e93325ddcf43d772c7ae8073 in lucene-solr's branch refs/heads/master from Mikhail Khludnev [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b0e532b ] SOLR-14051: removing Block Join Facet Component in favor of uniqueBlock(\_root_). > Remove BlockJoinFacetComponent&BlockJoinDocSetFacetComponent in 9.0 > --- > > Key: SOLR-14051 > URL: https://issues.apache.org/jira/browse/SOLR-14051 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Attachments: SOLR-14051.patch > > > Please migrate to SOLR-8998 and SOLR-9510 -- 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-14103) hadoop-minicluster dependency is not used anywhere?
[ https://issues.apache.org/jira/browse/SOLR-14103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998923#comment-16998923 ] ASF subversion and git services commented on SOLR-14103: Commit 71a5714e29b8d2636abc6aecffac39d30734a21f in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=71a5714 ] SOLR-14103: remove extra unused dependencies (jersey-core, jersey-server, netty-all). > hadoop-minicluster dependency is not used anywhere? > --- > > Key: SOLR-14103 > URL: https://issues.apache.org/jira/browse/SOLR-14103 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Priority: Major > > Hmm... hadoop-minicluster is a dependency. Strangely I don't declare it in > Gradle build and it's just fine. Is this something required? Maybe we can get > rid of it on ant side 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-14099) @LogLevel annotation not properly reseting after end of test (causes LoggingHandlerTest.testLogLevelHandlerOutput failures)
[
https://issues.apache.org/jira/browse/SOLR-14099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998929#comment-16998929
]
Dawid Weiss commented on SOLR-14099:
[~hossman] Chris - shouldn't this be moved into BeforeClass block?
{code}
+ /**
+ * We don't want a hardocded assumption here because it may change based on
how the user runs the test.
+ */
+ public static final Level DEFAULT_LOG_LEVEL =
LogManager.getRootLogger().getLevel();
{code}
A static class initializer will be invoked once (per JVM) whereas a BeforeClass
block runs before each test class (even if it's in a shared superclass).
Don't know what the intention is here but my gut feeling is that this should be
moved inside the initialization block.
> @LogLevel annotation not properly reseting after end of test (causes
> LoggingHandlerTest.testLogLevelHandlerOutput failures)
> ---
>
> Key: SOLR-14099
> URL: https://issues.apache.org/jira/browse/SOLR-14099
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Fix For: master (9.0), 8.5
>
> Attachments: SOLR-14099.patch, SOLR-14099.patch,
> SOLR-14099_test_workaround.patch
>
>
> We've seen a recent uptick in jenkins failures from
> {{LoggingHandlerTest.testLogLevelHandlerOutput}} that indicate the @LogLevel
> usage in other tests that have run earlier in the same JVM are _NOT_ properly
> being reset when those tests complete.
--
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-14103) hadoop-minicluster dependency is not used anywhere?
[ https://issues.apache.org/jira/browse/SOLR-14103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved SOLR-14103. Fix Version/s: master (9.0) Assignee: Dawid Weiss Resolution: Fixed > hadoop-minicluster dependency is not used anywhere? > --- > > Key: SOLR-14103 > URL: https://issues.apache.org/jira/browse/SOLR-14103 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > > Hmm... hadoop-minicluster is a dependency. Strangely I don't declare it in > Gradle build and it's just fine. Is this something required? Maybe we can get > rid of it on ant side 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] (LUCENE-7566) BooleanQuery.Builder shouldn't clone added clauses
[ https://issues.apache.org/jira/browse/LUCENE-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998936#comment-16998936 ] Adrien Grand commented on LUCENE-7566: -- Indeed, this was fixed as a side-effect of making queries immutable. > BooleanQuery.Builder shouldn't clone added clauses > -- > > Key: LUCENE-7566 > URL: https://issues.apache.org/jira/browse/LUCENE-7566 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Yonik Seeley >Priority: Trivial > > Minor GC improvement: There's no reason to clone BooleanClause in > BooleanQuery.Builder.add() -- 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998950#comment-16998950 ] Dawid Weiss commented on SOLR-14054: Why did you add commons-csv, Tim? I don't think it is required (it wasn't before and tests pass for me without it). > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-14051) Remove BlockJoinFacetComponent&BlockJoinDocSetFacetComponent in 9.0
[ https://issues.apache.org/jira/browse/SOLR-14051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998956#comment-16998956 ] ASF subversion and git services commented on SOLR-14051: Commit b0e532b7f32c1822e93325ddcf43d772c7ae8073 in lucene-solr's branch refs/heads/gradle-master from Mikhail Khludnev [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b0e532b ] SOLR-14051: removing Block Join Facet Component in favor of uniqueBlock(\_root_). > Remove BlockJoinFacetComponent&BlockJoinDocSetFacetComponent in 9.0 > --- > > Key: SOLR-14051 > URL: https://issues.apache.org/jira/browse/SOLR-14051 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-14051.patch > > > Please migrate to SOLR-8998 and SOLR-9510 -- 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-13749) Implement support for joining across collections with multiple shards ( XCJF )
[
https://issues.apache.org/jira/browse/SOLR-13749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998955#comment-16998955
]
ASF subversion and git services commented on SOLR-13749:
Commit 46e5e1372870f6b46925a86ec7c0461c7cb888bb in lucene-solr's branch
refs/heads/gradle-master from Gus Heck
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=46e5e13 ]
SOLR-13749 Cross collection join filter (XCJF)
Squashed commit of the following: commit
ffa68a8adb9c5dc16578ab26f731da247533c980
> Implement support for joining across collections with multiple shards ( XCJF )
> --
>
> Key: SOLR-13749
> URL: https://issues.apache.org/jira/browse/SOLR-13749
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Kevin Watters
>Assignee: Gus Heck
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This ticket includes 2 query parsers.
> The first one is the "Cross collection join filter" (XCJF) parser. This is
> the "Cross-collection join filter" query parser. It can do a call out to a
> remote collection to get a set of join keys to be used as a filter against
> the local collection.
> The second one is the Hash Range query parser that you can specify a field
> name and a hash range, the result is that only the documents that would have
> hashed to that range will be returned.
> This query parser will do an intersection based on join keys between 2
> collections.
> The local collection is the collection that you are searching against.
> The remote collection is the collection that contains the join keys that you
> want to use as a filter.
> Each shard participating in the distributed request will execute a query
> against the remote collection. If the local collection is setup with the
> compositeId router to be routed on the join key field, a hash range query is
> applied to the remote collection query to only match the documents that
> contain a potential match for the documents that are in the local shard/core.
>
>
> Here's some vocab to help with the descriptions of the various parameters.
> ||Term||Description||
> |Local Collection|This is the main collection that is being queried.|
> |Remote Collection|This is the collection that the XCJFQuery will query to
> resolve the join keys.|
> |XCJFQuery|The lucene query that executes a search to get back a set of join
> keys from a remote collection|
> |HashRangeQuery|The lucene query that matches only the documents whose hash
> code on a field falls within a specified range.|
>
>
> ||Param ||Required ||Description||
> |collection|Required|The name of the external Solr collection to be queried
> to retrieve the set of join key values ( required )|
> |zkHost|Optional|The connection string to be used to connect to Zookeeper.
> zkHost and solrUrl are both optional parameters, and at most one of them
> should be specified.
> If neither of zkHost or solrUrl are specified, the local Zookeeper cluster
> will be used. ( optional )|
> |solrUrl|Optional|The URL of the external Solr node to be queried ( optional
> )|
> |from|Required|The join key field name in the external collection ( required
> )|
> |to|Required|The join key field name in the local collection|
> |v|See Note|The query to be executed against the external Solr collection to
> retrieve the set of join key values.
> Note: The original query can be passed at the end of the string or as the
> "v" parameter.
> It's recommended to use query parameter substitution with the "v" parameter
> to ensure no issues arise with the default query parsers.|
> |routed| |true / false. If true, the XCJF query will use each shard's hash
> range to determine the set of join keys to retrieve for that shard.
> This parameter improves the performance of the cross-collection join, but
> it depends on the local collection being routed by the toField. If this
> parameter is not specified,
> the XCJF query will try to determine the correct value automatically.|
> |ttl| |The length of time that an XCJF query in the cache will be considered
> valid, in seconds. Defaults to 3600 (one hour).
> The XCJF query will not be aware of changes to the remote collection, so
> if the remote collection is updated, cached XCJF queries may give inaccurate
> results.
> After the ttl period has expired, the XCJF query will re-execute the join
> against the remote collection.|
> |_All others_| |Any normal Solr parameter can also be specified as a local
> param.|
>
> Example Solr Config.xml changes:
>
> {{<}}{{cache}} {{name}}{{=}}{{"hash_vin"}}
> {{ }}{{class}}{{=}}{{"solr.LRUCache"}}
> {{
[jira] [Commented] (SOLR-14103) hadoop-minicluster dependency is not used anywhere?
[ https://issues.apache.org/jira/browse/SOLR-14103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998957#comment-16998957 ] ASF subversion and git services commented on SOLR-14103: Commit 71a5714e29b8d2636abc6aecffac39d30734a21f in lucene-solr's branch refs/heads/gradle-master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=71a5714 ] SOLR-14103: remove extra unused dependencies (jersey-core, jersey-server, netty-all). > hadoop-minicluster dependency is not used anywhere? > --- > > Key: SOLR-14103 > URL: https://issues.apache.org/jira/browse/SOLR-14103 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > > Hmm... hadoop-minicluster is a dependency. Strangely I don't declare it in > Gradle build and it's just fine. Is this something required? Maybe we can get > rid of it on ant side 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-14099) @LogLevel annotation not properly reseting after end of test (causes LoggingHandlerTest.testLogLevelHandlerOutput failures)
[
https://issues.apache.org/jira/browse/SOLR-14099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998954#comment-16998954
]
ASF subversion and git services commented on SOLR-14099:
Commit cc4262a8ec37b2420e1d80a392c5e8019f43e24c in lucene-solr's branch
refs/heads/gradle-master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cc4262a ]
SOLR-14099: Fixed @LogLevel annotation in test-framework to correctly 'unset'
Loggers after test
> @LogLevel annotation not properly reseting after end of test (causes
> LoggingHandlerTest.testLogLevelHandlerOutput failures)
> ---
>
> Key: SOLR-14099
> URL: https://issues.apache.org/jira/browse/SOLR-14099
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Fix For: master (9.0), 8.5
>
> Attachments: SOLR-14099.patch, SOLR-14099.patch,
> SOLR-14099_test_workaround.patch
>
>
> We've seen a recent uptick in jenkins failures from
> {{LoggingHandlerTest.testLogLevelHandlerOutput}} that indicate the @LogLevel
> usage in other tests that have run earlier in the same JVM are _NOT_ properly
> being reset when those tests complete.
--
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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998952#comment-16998952 ] ASF subversion and git services commented on SOLR-14054: Commit 279a391cf3b38354f94e721297b8bc6563b8c4ce in lucene-solr's branch refs/heads/gradle-master from Tim Allison [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=279a391 ] SOLR-14054 -- upgrade to Tika 1.23 (and its dependencies) (#1092) * SOLR-14054 -- upgrade to Tika 1.23 (and its dependencies) * fix CHANGES.txt file > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998953#comment-16998953 ] ASF subversion and git services commented on SOLR-14054: Commit 279a391cf3b38354f94e721297b8bc6563b8c4ce in lucene-solr's branch refs/heads/gradle-master from Tim Allison [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=279a391 ] SOLR-14054 -- upgrade to Tika 1.23 (and its dependencies) (#1092) * SOLR-14054 -- upgrade to Tika 1.23 (and its dependencies) * fix CHANGES.txt file > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-14106) SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
[
https://issues.apache.org/jira/browse/SOLR-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998964#comment-16998964
]
Jan Høydahl commented on SOLR-14106:
This proves that the upgrade to jetty 9.4.19 was premature and incomplete. I
think the safest action would be to quickly after 8.4.0 release a 8.4.1 with
the only change being a revert of SOLR-13541, i.e. go back to jetty 9.4.14. The
revert applies cleanly and works here, need some full test suite runs of course.
And then the 8.5 release will upgrade to jetty 9.4.24 in one go, including
fixing all the Server/Client stuff, replace deprecated methods etc.
Actually, the project should pay more attention to deprecation warnings. That
would have caught this mess during development of SOLR-13541, because Jetty has
been spitting out deprecation warnings ever since 8.2.0 which was a warning
sign that the upgrade was not complete. I'll flag this on the dev list.
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Attachments: SOLR-14106.patch, deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {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] (SOLR-14096) DistribPackageStore attempts to create filestore in read-only directory
[
https://issues.apache.org/jira/browse/SOLR-14096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998969#comment-16998969
]
Dawid Weiss commented on SOLR-14096:
bq. So long story short - SolrTestCaseJ4 TEST_HOME needs to be fixed.
+1.
> DistribPackageStore attempts to create filestore in read-only directory
> ---
>
> Key: SOLR-14096
> URL: https://issues.apache.org/jira/browse/SOLR-14096
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Dawid Weiss
>Priority: Major
>
> I see this in the logs when running with security manager:
> {code}
> 1645805 WARN (SUITE-LoggingHandlerTest-seed#[DEADBEEF]-worker) [ ]
> o.a.s.f.DistribPackageStore Unable to create
> [/home/dweiss/work-ssd/lucene-solr/solr/core/build/resources/test/solr/.filestore]
> directory in SOLR_HOME
> [/home/dweiss/work-ssd/lucene-solr/solr/core/build/resources/test/solr].
> Features requiring this directory may fail.
> => java.security.AccessControlException: access denied
> ("java.io.FilePermission"
> "/home/dweiss/work-ssd/lucene-solr/solr/core/build/resources/test/solr/.filestore"
> "write")
> at
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> java.security.AccessControlException: access denied ("java.io.FilePermission"
> "/home/dweiss/work-ssd/lucene-solr/solr/core/build/resources/test/solr/.filestore"
> "write")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> ~[?:?]
> at
> java.security.AccessController.checkPermission(AccessController.java:897)
> ~[?:?]
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
> ~[?:?]
> at java.lang.SecurityManager.checkWrite(SecurityManager.java:752) ~[?:?]
> at java.io.File.mkdir(File.java:1323) ~[?:?]
> at java.io.File.mkdirs(File.java:1355) ~[?:?]
> at
> org.apache.solr.filestore.DistribPackageStore.ensurePackageStoreDir(DistribPackageStore.java:476)
> ~[main/:?]
> at
> org.apache.solr.filestore.DistribPackageStore.(DistribPackageStore.java:65)
> ~[main/:?]
> at
> org.apache.solr.filestore.PackageStoreAPI.(PackageStoreAPI.java:78)
> ~[main/:?]
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:619)
> ~[main/:?]
> {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] [Created] (SOLR-14109) zkcli.sh and zkcli.bat barfs when LOG4J_PROPS is set
Jan Høydahl created SOLR-14109:
--
Summary: zkcli.sh and zkcli.bat barfs when LOG4J_PROPS is set
Key: SOLR-14109
URL: https://issues.apache.org/jira/browse/SOLR-14109
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: scripts and tools
Reporter: Jan Høydahl
I noticed this when running {{zkcli.sh}} from solr's docker image. [The docker
image sets the variable
{{LOG4J_PROPS}}|https://github.com/docker-solr/docker-solr/blob/master/8.3/Dockerfile],
causing the zkcli script to pick up and use that logger instead of the console
logger. Problem with that is that Solr's log4j2 config relies on the
{{solr.log.dir}} sysprop being set, which it is not when running this script.
So either fix the wrapper script to set {{solr.log.dir}} or, better, always log
to stdout.
--
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] janhoy opened a new pull request #1096: SOLR-14109 Always log to stdout from zkcli.sh
janhoy opened a new pull request #1096: SOLR-14109 Always log to stdout from zkcli.sh URL: https://github.com/apache/lucene-solr/pull/1096 There should be no reason to log anywhere else. This fixes a problem with bogous logging when running the tool from Solr's Docker image. 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-14109) zkcli.sh and zkcli.bat barfs when LOG4J_PROPS is set
[
https://issues.apache.org/jira/browse/SOLR-14109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998982#comment-16998982
]
Jan Høydahl commented on SOLR-14109:
Linking SOLR-9047 [~gchanan] since that is where the env var was introduced.
Since that we got a centralized stdout logger config, and I cannot see a reason
for not always using that for a CLI tool like this.
> zkcli.sh and zkcli.bat barfs when LOG4J_PROPS is set
>
>
> Key: SOLR-14109
> URL: https://issues.apache.org/jira/browse/SOLR-14109
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Reporter: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I noticed this when running {{zkcli.sh}} from solr's docker image. [The
> docker image sets the variable
> {{LOG4J_PROPS}}|https://github.com/docker-solr/docker-solr/blob/master/8.3/Dockerfile],
> causing the zkcli script to pick up and use that logger instead of the
> console logger. Problem with that is that Solr's log4j2 config relies on the
> {{solr.log.dir}} sysprop being set, which it is not when running this script.
> So either fix the wrapper script to set {{solr.log.dir}} or, better, always
> log to stdout.
--
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-14109) zkcli.sh and zkcli.bat barfs when LOG4J_PROPS is set
[
https://issues.apache.org/jira/browse/SOLR-14109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-14109:
--
Assignee: Jan Høydahl
> zkcli.sh and zkcli.bat barfs when LOG4J_PROPS is set
>
>
> Key: SOLR-14109
> URL: https://issues.apache.org/jira/browse/SOLR-14109
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I noticed this when running {{zkcli.sh}} from solr's docker image. [The
> docker image sets the variable
> {{LOG4J_PROPS}}|https://github.com/docker-solr/docker-solr/blob/master/8.3/Dockerfile],
> causing the zkcli script to pick up and use that logger instead of the
> console logger. Problem with that is that Solr's log4j2 config relies on the
> {{solr.log.dir}} sysprop being set, which it is not when running this script.
> So either fix the wrapper script to set {{solr.log.dir}} or, better, always
> log to stdout.
--
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-13749) Implement support for joining across collections with multiple shards ( XCJF )
[
https://issues.apache.org/jira/browse/SOLR-13749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998984#comment-16998984
]
Mikhail Khludnev commented on SOLR-13749:
-
if there's 8.5 release, I'll vote for putting it there as well.
> Implement support for joining across collections with multiple shards ( XCJF )
> --
>
> Key: SOLR-13749
> URL: https://issues.apache.org/jira/browse/SOLR-13749
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Kevin Watters
>Assignee: Gus Heck
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This ticket includes 2 query parsers.
> The first one is the "Cross collection join filter" (XCJF) parser. This is
> the "Cross-collection join filter" query parser. It can do a call out to a
> remote collection to get a set of join keys to be used as a filter against
> the local collection.
> The second one is the Hash Range query parser that you can specify a field
> name and a hash range, the result is that only the documents that would have
> hashed to that range will be returned.
> This query parser will do an intersection based on join keys between 2
> collections.
> The local collection is the collection that you are searching against.
> The remote collection is the collection that contains the join keys that you
> want to use as a filter.
> Each shard participating in the distributed request will execute a query
> against the remote collection. If the local collection is setup with the
> compositeId router to be routed on the join key field, a hash range query is
> applied to the remote collection query to only match the documents that
> contain a potential match for the documents that are in the local shard/core.
>
>
> Here's some vocab to help with the descriptions of the various parameters.
> ||Term||Description||
> |Local Collection|This is the main collection that is being queried.|
> |Remote Collection|This is the collection that the XCJFQuery will query to
> resolve the join keys.|
> |XCJFQuery|The lucene query that executes a search to get back a set of join
> keys from a remote collection|
> |HashRangeQuery|The lucene query that matches only the documents whose hash
> code on a field falls within a specified range.|
>
>
> ||Param ||Required ||Description||
> |collection|Required|The name of the external Solr collection to be queried
> to retrieve the set of join key values ( required )|
> |zkHost|Optional|The connection string to be used to connect to Zookeeper.
> zkHost and solrUrl are both optional parameters, and at most one of them
> should be specified.
> If neither of zkHost or solrUrl are specified, the local Zookeeper cluster
> will be used. ( optional )|
> |solrUrl|Optional|The URL of the external Solr node to be queried ( optional
> )|
> |from|Required|The join key field name in the external collection ( required
> )|
> |to|Required|The join key field name in the local collection|
> |v|See Note|The query to be executed against the external Solr collection to
> retrieve the set of join key values.
> Note: The original query can be passed at the end of the string or as the
> "v" parameter.
> It's recommended to use query parameter substitution with the "v" parameter
> to ensure no issues arise with the default query parsers.|
> |routed| |true / false. If true, the XCJF query will use each shard's hash
> range to determine the set of join keys to retrieve for that shard.
> This parameter improves the performance of the cross-collection join, but
> it depends on the local collection being routed by the toField. If this
> parameter is not specified,
> the XCJF query will try to determine the correct value automatically.|
> |ttl| |The length of time that an XCJF query in the cache will be considered
> valid, in seconds. Defaults to 3600 (one hour).
> The XCJF query will not be aware of changes to the remote collection, so
> if the remote collection is updated, cached XCJF queries may give inaccurate
> results.
> After the ttl period has expired, the XCJF query will re-execute the join
> against the remote collection.|
> |_All others_| |Any normal Solr parameter can also be specified as a local
> param.|
>
> Example Solr Config.xml changes:
>
> {{<}}{{cache}} {{name}}{{=}}{{"hash_vin"}}
> {{ }}{{class}}{{=}}{{"solr.LRUCache"}}
> {{ }}{{size}}{{=}}{{"128"}}
> {{ }}{{initialSize}}{{=}}{{"0"}}
> {{ }}{{regenerator}}{{=}}{{"solr.NoOpRegenerator"}}{{/>}}
>
> {{<}}{{queryParser}} {{name}}{{=}}{{"xcjf"}}
> {{class}}{{=}}{{"org.apache.solr.search.join.XCJFQueryParserPlugin"}}{{>}}
> {{ }}{{<
[jira] [Commented] (SOLR-14105) Http2SolrClient SSL not working in branch_8x
[
https://issues.apache.org/jira/browse/SOLR-14105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998986#comment-16998986
]
Jan Høydahl commented on SOLR-14105:
Looked at the patch and seems like you cleaned up some of the mess :) Did not
get a chance to test it yet.
In my opinion we should merge this with SOLR-14106 since I believe they are
intertwined and will not be merged to 8.4.x but be released in 8.5. At least
that's my suggestion that I commented in 14106.
> Http2SolrClient SSL not working in branch_8x
>
>
> Key: SOLR-14105
> URL: https://issues.apache.org/jira/browse/SOLR-14105
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-14105.patch
>
>
> In branch_8x we upgraded to Jetty 9.4.24. This causes the following
> exceptions when attempting to start server with SSL:
> {noformat}
> 2019-12-17 14:46:16.646 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:633)
> ...
> Caused by: java.lang.RuntimeException:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.createHttpClient(Http2SolrClient.java:224)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.(Http2SolrClient.java:154)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.build(Http2SolrClient.java:833)
> at
> org.apache.solr.handler.component.HttpShardHandlerFactory.init(HttpShardHandlerFactory.java:321)
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:51)
> ... 50 more
> Caused by: java.lang.UnsupportedOperationException: X509ExtendedKeyManager
> only supported on Server
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1273)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1255)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> {noformat}
--
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-14110) sandbox javax.script usage in tests
Robert Muir created SOLR-14110: -- Summary: sandbox javax.script usage in tests Key: SOLR-14110 URL: https://issues.apache.org/jira/browse/SOLR-14110 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Robert Muir Similar to SOLR-13993 we should sandbox the use of javax.script if security manager is present. -- 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-14110) sandbox javax.script usage in tests
[ https://issues.apache.org/jira/browse/SOLR-14110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-14110: --- Attachment: SOLR-14110.patch > sandbox javax.script usage in tests > --- > > Key: SOLR-14110 > URL: https://issues.apache.org/jira/browse/SOLR-14110 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14110.patch > > > Similar to SOLR-13993 we should sandbox the use of javax.script if security > manager is present. -- 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-13984) Solr should run inside a SecurityManager
[
https://issues.apache.org/jira/browse/SOLR-13984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999017#comment-16999017
]
ASF subversion and git services commented on SOLR-13984:
Commit 7fbb3d5ff4315e35fd6b6c5cb9cda96bf76ac61f in lucene-solr's branch
refs/heads/jira/SOLR-13984 from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7fbb3d5 ]
SOLR-13984: link to the jdk documentation for more info
> Solr should run inside a SecurityManager
>
>
> Key: SOLR-13984
> URL: https://issues.apache.org/jira/browse/SOLR-13984
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> To reduce the effect of attacks, esp. RCE, Solr should run inside a
> SecurityManager.
> Quoting Uwe here:
> {quote}
> The correct way to fix all issues we have seen the last time is very simple:
> LET'S RUN SOLR INSIDE A SECURITY MANAGER IN PRODUCTION (like in tests).
> Elasticsearch is doing this, so please please let's do this instead. But this
> requires to finally get rid of the webapplication and start.jar and add our
> own bootstrapping (like in tests) that configure Jetty and Security Manager
> from our own org.apache.solr.bootstrap.Main.java (or similar).
> {quote}
> https://jira.apache.org/jira/browse/SOLR-12316?focusedCommentId=16465038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16465038
--
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] (LUCENE-9099) Correctly handle repeats in ordered and unordered intervals
Alan Woodward created LUCENE-9099: - Summary: Correctly handle repeats in ordered and unordered intervals Key: LUCENE-9099 URL: https://issues.apache.org/jira/browse/LUCENE-9099 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward If you have repeating intervals in an ordered or unordered interval source, you currently get somewhat confusing behaviour: * ORDERED(a, a, b) will return an extra interval over just `a b` if it first matches `a a b`, meaning that you can get incorrect results if used in a CONTAINING filter - CONTAINING(ORDERED(x, y), ORDERED(a, a, b)) will match on the document `a x a b y` * UNORDERED(a, a) will match on documents that just containg a single `a`. It is possible to deal with the unordered case when building sources by rewriting duplicates to nested ORDERED clauses, so that UNORDERED(a, b, c, a, b) becomes UNORDERED(ORDERED(a, a), ORDERED(b, b), c), but this then breaks MAXGAPS filtering. We should try and fix this within intervals themselves. -- 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] romseygeek opened a new pull request #1097: LUCENE-9099: Correctly handle repeats in ORDERED and UNORDERED intervals
romseygeek opened a new pull request #1097: LUCENE-9099: Correctly handle repeats in ORDERED and UNORDERED intervals URL: https://github.com/apache/lucene-solr/pull/1097 If you have repeating intervals in an ordered or unordered interval source, you currently get somewhat confusing behaviour: * `ORDERED(a, a, b)` will return an extra interval over just `a b` if it first matches `a a b`, meaning that you can get incorrect results if used in a `CONTAINING` filter - `CONTAINING(ORDERED(x, y), ORDERED(a, a, b))` will match on the document `a x a b y` * `UNORDERED(a, a)` will match on documents that just containg a single `a`. This commit adds a `RepeatingIntervalsSource` that correctly handles repeats within ordered and unordered sources. It also changes the way that gaps are calculated within ordered and unordered sources, by using a new `width()` method on `IntervalIterator`. The default implementation just returns `end() - start() + 1`, but `RepeatingIntervalsSource` instead returns the sum of the widths of its child iterators. This preserves `maxgaps` filtering on ordered and unordered sources that contain repeats. In order to correctly handle matches in this scenario, `IntervalsSource#matches` now always returns an explicit `IntervalsMatchesIterator` rather than a plain `MatchesIterator`, which adds `gaps()` and `width()` methods so that submatches can be combined in the same way that subiterators are. Extra checks have been added to `checkIntervals()` to ensure that the same intervals are returned by both iterator and matches, and a fix to `DisjunctionIntervalIterator#matches()` is also included - `DisjunctionIntervalIterator` minimizes its intervals, while `MatchesUtils.disjunction` does not, so there was a discrepancy between the two methods. 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-14110) sandbox javax.script usage in tests
[ https://issues.apache.org/jira/browse/SOLR-14110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999027#comment-16999027 ] Kevin Risden commented on SOLR-14110: - +1 lgtm > sandbox javax.script usage in tests > --- > > Key: SOLR-14110 > URL: https://issues.apache.org/jira/browse/SOLR-14110 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14110.patch > > > Similar to SOLR-13993 we should sandbox the use of javax.script if security > manager is present. -- 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999033#comment-16999033 ] Tim Allison commented on SOLR-14054: [~dweiss], commons-csv is used in Tika's in TextAndCSVParser, which is new since 1.19.1. > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999034#comment-16999034 ] Tim Allison commented on SOLR-14054: [~hossman]...ugh. Worked locally. Will take a look. Sorry and thank you. > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-14110) sandbox javax.script usage in tests
[ https://issues.apache.org/jira/browse/SOLR-14110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999059#comment-16999059 ] ASF subversion and git services commented on SOLR-14110: Commit 612cba38cab168a41392506cda6ebfe03a9af916 in lucene-solr's branch refs/heads/master from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=612cba3 ] SOLR-14110: sandbox javax.script usage in tests > sandbox javax.script usage in tests > --- > > Key: SOLR-14110 > URL: https://issues.apache.org/jira/browse/SOLR-14110 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14110.patch > > > Similar to SOLR-13993 we should sandbox the use of javax.script if security > manager is present. -- 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999069#comment-16999069 ] Dawid Weiss commented on SOLR-14054: [~tallison] but do we need it? I mean: we don't need to support each and every parser Tika comes with... And if we do then shouldn't this be somehow reflected in tests (they pass without commons-csv for me). > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-12711) Count dominating child field values
[
https://issues.apache.org/jira/browse/SOLR-12711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev resolved SOLR-12711.
-
Resolution: Won't Fix
> Count dominating child field values
> ---
>
> Key: SOLR-12711
> URL: https://issues.apache.org/jira/browse/SOLR-12711
> Project: Solr
> Issue Type: New Feature
> Components: Facet Module
>Reporter: Mikhail Khludnev
>Priority: Major
>
> h2. Context
> {{uniqueBlock(_root_)}} which was introduced in SOLR-8998 allows to count
> child field facet grouping hits by parents, ie hitting every parent only once.
> h2. Problem
> How to count only dominating child field value. ie if a product has 5 Red
> skus and 2 Blue, it contributes {{Red(1)}}, {{Blue(0)}}
> h2. Suggestion
> Introduce {{dominatingBlock(_root_)}} which aggregate hits per parent,
> chooses the dominating one and incs only it.
> h2. Further Work
> Judge dominating value not by number of child hits, but by the given function
> value. Like pick the most popular, best selling, random child field value as
> dominating.
--
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-12478) make JSON.facet aware of timeAllowed
[ https://issues.apache.org/jira/browse/SOLR-12478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev resolved SOLR-12478. - Resolution: Duplicate > make JSON.facet aware of timeAllowed > - > > Key: SOLR-12478 > URL: https://issues.apache.org/jira/browse/SOLR-12478 > Project: Solr > Issue Type: Improvement > Components: Facet Module >Reporter: Mikhail Khludnev >Priority: Major > > It make sense to prevent heavy facets from spinning infinitely by checking > [timeout|https://lucene.apache.org/solr/guide/7_3/common-query-parameters.html#timeallowed-parameter]. > > -- 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-13778) Windows JDK SSL Test Failure trend: SSLException: Software caused connection abort: recv failed
[
https://issues.apache.org/jira/browse/SOLR-13778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated SOLR-13778:
---
Attachment: recv-multiple-2019-12-18.zip
Status: Open (was: Open)
The recv issue is happening even on tests that passed... It just depends on
where it happens and how it's wrapped up (in SSLException or SocketException).
I attach a few logs from a single run on Windows -- all of these logs have
"recv failed" in them; only TestCloudSearcherWarming actually failed.
The context of these failures is not clear to me. [~hossman] - could you take a
look at these logs (grep for "recv failed" and look at a few lines of prior
context) and tell if it's expected that these sockets are closed? I mean -- is
the server really dropping those connections?
> Windows JDK SSL Test Failure trend: SSLException: Software caused connection
> abort: recv failed
> ---
>
> Key: SOLR-13778
> URL: https://issues.apache.org/jira/browse/SOLR-13778
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: dumps-LegacyCloud.zip, logs-2019-12-12-1.zip,
> recv-multiple-2019-12-18.zip
>
>
> Now that Uwe's jenkins build has been correctly reporting it's build results
> for my [automated
> reports|http://fucit.org/solr-jenkins-reports/failure-report.html] to pick
> up, I've noticed a pattern of failures that indicate a definite problem with
> using SSL on Windows (even with java 11.0.4
> )
> The symptommatic stack traces all contain...
> {noformat}
> ...
>[junit4]> Caused by: javax.net.ssl.SSLException: Software caused
> connection abort: recv failed
>[junit4]>at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
> ...
>[junit4]> Caused by: java.net.SocketException: Software caused
> connection abort: recv failed
>[junit4]>at
> java.base/java.net.SocketInputStream.socketRead0(Native Method)
> ...
> {noformat}
> I suspect this may be related to
> [https://bugs.openjdk.java.net/browse/JDK-8209333] but i have no concrete
> evidence to back this up.
> I'll post some details of my analysis in comments...
--
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-14110) sandbox javax.script usage in tests
[ https://issues.apache.org/jira/browse/SOLR-14110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999115#comment-16999115 ] ASF subversion and git services commented on SOLR-14110: Commit 53a82aedcb4c62ac8b2573e7caa6104ce7db8229 in lucene-solr's branch refs/heads/branch_8x from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=53a82ae ] SOLR-14110: sandbox javax.script usage in tests > sandbox javax.script usage in tests > --- > > Key: SOLR-14110 > URL: https://issues.apache.org/jira/browse/SOLR-14110 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14110.patch > > > Similar to SOLR-13993 we should sandbox the use of javax.script if security > manager is present. -- 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-14110) sandbox javax.script usage in tests
[ https://issues.apache.org/jira/browse/SOLR-14110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved SOLR-14110. Fix Version/s: 8.5 Assignee: Robert Muir Resolution: Fixed > sandbox javax.script usage in tests > --- > > Key: SOLR-14110 > URL: https://issues.apache.org/jira/browse/SOLR-14110 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Major > Fix For: 8.5 > > Attachments: SOLR-14110.patch > > > Similar to SOLR-13993 we should sandbox the use of javax.script if security > manager is present. -- 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-13190) Fuzzy search treated as server error instead of client error when terms are too complex
[
https://issues.apache.org/jira/browse/SOLR-13190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999118#comment-16999118
]
Andy Webb commented on SOLR-13190:
--
Thanks Mike!
I've tried adding a {{maxQueryLength}} option to {{Direct(Solr)SpellChecker}}
which can be set to prevent long terms being spellchecked - it's a simple
change, largely a cut-and-paste of the {{minQueryLength}}, and as far as I can
see this would prevent us seeing the exceptions. It could default to 0, i.e.
"no limit", to maintain the existing default behaviour unless it's deliberately
set. Would this be a reasonable change to make to Lucene/Solr or do you think
there might be a better approach?
> Fuzzy search treated as server error instead of client error when terms are
> too complex
> ---
>
> Key: SOLR-13190
> URL: https://issues.apache.org/jira/browse/SOLR-13190
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We've seen a fuzzy search end up breaking the automaton and getting reported
> as a server error. This usage should be improved by
> 1) reporting as a client error, because it's similar to something like too
> many boolean clauses queries in how an operator should deal with it
> 2) report what field is causing the error, since that currently must be
> deduced from adjacent query logs and can be difficult if there are multiple
> terms in the search
> This trigger was added to defend against adversarial regex but somehow hits
> fuzzy terms as well, I don't understand enough about the automaton mechanisms
> to really know how to approach a fix there, but improving the operability is
> a good first step.
> relevant stack trace:
> {noformat}
> org.apache.lucene.util.automaton.TooComplexToDeterminizeException:
> Determinizing automaton with 13632 states and 21348 transitions would result
> in more than 1 states.
> at
> org.apache.lucene.util.automaton.Operations.determinize(Operations.java:746)
> at
> org.apache.lucene.util.automaton.RunAutomaton.(RunAutomaton.java:69)
> at
> org.apache.lucene.util.automaton.ByteRunAutomaton.(ByteRunAutomaton.java:32)
> at
> org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:247)
> at
> org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:133)
> at
> org.apache.lucene.search.FuzzyTermsEnum.(FuzzyTermsEnum.java:143)
> at org.apache.lucene.search.FuzzyQuery.getTermsEnum(FuzzyQuery.java:154)
> at
> org.apache.lucene.search.MultiTermQuery$RewriteMethod.getTermsEnum(MultiTermQuery.java:78)
> at
> org.apache.lucene.search.TermCollectingRewrite.collectTerms(TermCollectingRewrite.java:58)
> at
> org.apache.lucene.search.TopTermsRewrite.rewrite(TopTermsRewrite.java:67)
> at
> org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:310)
> at
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:442)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
> 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:1435)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:374)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
> {noformat}
--
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-14105) Http2SolrClient SSL not working in branch_8x
[
https://issues.apache.org/jira/browse/SOLR-14105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999123#comment-16999123
]
Kevin Risden commented on SOLR-14105:
-
Yea agreed on merging.
> Http2SolrClient SSL not working in branch_8x
>
>
> Key: SOLR-14105
> URL: https://issues.apache.org/jira/browse/SOLR-14105
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-14105.patch
>
>
> In branch_8x we upgraded to Jetty 9.4.24. This causes the following
> exceptions when attempting to start server with SSL:
> {noformat}
> 2019-12-17 14:46:16.646 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:633)
> ...
> Caused by: java.lang.RuntimeException:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.createHttpClient(Http2SolrClient.java:224)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.(Http2SolrClient.java:154)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.build(Http2SolrClient.java:833)
> at
> org.apache.solr.handler.component.HttpShardHandlerFactory.init(HttpShardHandlerFactory.java:321)
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:51)
> ... 50 more
> Caused by: java.lang.UnsupportedOperationException: X509ExtendedKeyManager
> only supported on Server
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1273)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1255)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> {noformat}
--
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-14105) Http2SolrClient SSL not working in branch_8x
[
https://issues.apache.org/jira/browse/SOLR-14105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden resolved SOLR-14105.
-
Fix Version/s: (was: 8.5)
Resolution: Duplicate
> Http2SolrClient SSL not working in branch_8x
>
>
> Key: SOLR-14105
> URL: https://issues.apache.org/jira/browse/SOLR-14105
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14105.patch
>
>
> In branch_8x we upgraded to Jetty 9.4.24. This causes the following
> exceptions when attempting to start server with SSL:
> {noformat}
> 2019-12-17 14:46:16.646 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:633)
> ...
> Caused by: java.lang.RuntimeException:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.createHttpClient(Http2SolrClient.java:224)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.(Http2SolrClient.java:154)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.build(Http2SolrClient.java:833)
> at
> org.apache.solr.handler.component.HttpShardHandlerFactory.init(HttpShardHandlerFactory.java:321)
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:51)
> ... 50 more
> Caused by: java.lang.UnsupportedOperationException: X509ExtendedKeyManager
> only supported on Server
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1273)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1255)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> {noformat}
--
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-14106) SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
[
https://issues.apache.org/jira/browse/SOLR-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14106:
Fix Version/s: 8.5
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {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] (SOLR-14105) Http2SolrClient SSL not working in branch_8x
[
https://issues.apache.org/jira/browse/SOLR-14105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999124#comment-16999124
]
Kevin Risden commented on SOLR-14105:
-
Going to fix this all in SOLR-14106
> Http2SolrClient SSL not working in branch_8x
>
>
> Key: SOLR-14105
> URL: https://issues.apache.org/jira/browse/SOLR-14105
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-14105.patch
>
>
> In branch_8x we upgraded to Jetty 9.4.24. This causes the following
> exceptions when attempting to start server with SSL:
> {noformat}
> 2019-12-17 14:46:16.646 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:633)
> ...
> Caused by: java.lang.RuntimeException:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.createHttpClient(Http2SolrClient.java:224)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.(Http2SolrClient.java:154)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.build(Http2SolrClient.java:833)
> at
> org.apache.solr.handler.component.HttpShardHandlerFactory.init(HttpShardHandlerFactory.java:321)
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:51)
> ... 50 more
> Caused by: java.lang.UnsupportedOperationException: X509ExtendedKeyManager
> only supported on Server
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1273)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1255)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> {noformat}
--
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-14106) SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
[
https://issues.apache.org/jira/browse/SOLR-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14106:
Affects Version/s: 8.4
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.4, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {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] [Resolved] (LUCENE-8677) JVM SIGSEGV in Node::in
[
https://issues.apache.org/jira/browse/LUCENE-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Sokolov resolved LUCENE-8677.
-
Resolution: Resolved
I think we can resolve given this is 1 yr old, on JDK 9, and no clear repro is
cited
> JVM SIGSEGV in Node::in
> ---
>
> Key: LUCENE-8677
> URL: https://issues.apache.org/jira/browse/LUCENE-8677
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Dawid Weiss
>Priority: Minor
> Labels: jvm
>
> Jenkins:
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15
> {code}
>[junit4] # A fatal error has been detected by the Java Runtime Environment:
>[junit4] #
>[junit4] # SIGSEGV (0xb) at pc=0x000105bee9d8, pid=85292, tid=18179
>[junit4] #
>[junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+181) (build
> 9+181)
>[junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (9+181, mixed mode,
> tiered, concurrent mark sweep gc, bsd-amd64)
>[junit4] # Problematic frame:
>[junit4] # [thread 208539 also had an error]
>[junit4] V [libjvm.dylib+0x4f49d8] Node::in(unsigned int) const+0x18
>[junit4] #
>[junit4] # No core dump will be written. Core dumps have been disabled. To
> enable core dumping, try "ulimit -c unlimited" before starting Java again
>[junit4] #
>[junit4] # An error report file with more information is saved as:
>[junit4] #
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J0/hs_err_pid85292.log
>[junit4] # [ timer expired, abort... ]
> {code}
> No hs_err or replay log on the jenkins page though.
--
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-14106) SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
[
https://issues.apache.org/jira/browse/SOLR-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999125#comment-16999125
]
Kevin Risden commented on SOLR-14106:
-
Closed SOLR-14105 and will fix them both here since they are intertwined. Will
upload a new patch/PR shortly.
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.4, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {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] [Created] (SOLR-14111) Revert SOLR-13541 which breaks SSL client auth
Jan Høydahl created SOLR-14111: -- Summary: Revert SOLR-13541 which breaks SSL client auth Key: SOLR-14111 URL: https://issues.apache.org/jira/browse/SOLR-14111 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Jan Høydahl Assignee: Jan Høydahl Fix For: 8.4.1 Propose to revert SOLR-13541 which was the commit introducing the regression. This means rolling back to Jetty 9.4.14, in branch_8_4 only. Then release a bugfix version 8.4.1 with this fix. The full fix of this issue will come in SOLR-14105 and SOLR-14106 in 8.5.0 but is more involved, requires further upgrade of Jetty beyond 9.4.19 and is thus not suitable for a bugfix 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] [Updated] (SOLR-14106) SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
[
https://issues.apache.org/jira/browse/SOLR-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14106:
Attachment: SOLR-14106.patch
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.4, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, SOLR-14106.patch,
> deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {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-8448) Slowdown of nested boolean queries after LUCENE-8060
[
https://issues.apache.org/jira/browse/LUCENE-8448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999130#comment-16999130
]
Tommaso Teofili commented on LUCENE-8448:
-
I get the same issue as [~dweiss], in a BQ with *many* {{SHOULD}} clauses, I
get a serious slowdown (~10x) if I run the same code with 7.6.0 vs 8.3.1 [1]
(~200ms vs ~2s).
[1] :
https://github.com/tteofili/Anserini-embeddings/blob/nnsearch/src/main/java/io/anserini/embeddings/nn/fw/FakeWordsRunner.java
> Slowdown of nested boolean queries after LUCENE-8060
>
>
> Key: LUCENE-8448
> URL: https://issues.apache.org/jira/browse/LUCENE-8448
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 8.0
>
> Attachments: LUCENE-8448.patch, LUCENE-8448.patch
>
>
> Mike's nightly benchmarks revealed that disabling hit counts slowed down
> nested boolean queries
> http://people.apache.org/~mikemccand/lucenebench/AndHighOrMedMed.html
> http://people.apache.org/~mikemccand/lucenebench/AndMedOrHighHigh.html.
> We are probably not propagating max scores and/or blocks efficiently.
--
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-14111) Revert SOLR-13541 which breaks SSL client auth
[ https://issues.apache.org/jira/browse/SOLR-14111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999131#comment-16999131 ] Jan Høydahl commented on SOLR-14111: This Jira intends to fix the bug for branch_8_4 through reverting the bad Jetty, while SOLR-14106 fixes the same bug on branch_8x and master through upgrading Jetty and fixing related Solr code. > Revert SOLR-13541 which breaks SSL client auth > -- > > Key: SOLR-14111 > URL: https://issues.apache.org/jira/browse/SOLR-14111 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4.1 > > > Propose to revert SOLR-13541 which was the commit introducing the regression. > This means rolling back to Jetty 9.4.14, in branch_8_4 only. Then release a > bugfix version 8.4.1 with this fix. > The full fix of this issue will come in SOLR-14105 and SOLR-14106 in 8.5.0 > but is more involved, requires further upgrade of Jetty beyond 9.4.19 and is > thus not suitable for a bugfix 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] (LUCENE-8677) JVM SIGSEGV in Node::in
[
https://issues.apache.org/jira/browse/LUCENE-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss reassigned LUCENE-8677:
---
Assignee: Dawid Weiss
> JVM SIGSEGV in Node::in
> ---
>
> Key: LUCENE-8677
> URL: https://issues.apache.org/jira/browse/LUCENE-8677
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Labels: jvm
>
> Jenkins:
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15
> {code}
>[junit4] # A fatal error has been detected by the Java Runtime Environment:
>[junit4] #
>[junit4] # SIGSEGV (0xb) at pc=0x000105bee9d8, pid=85292, tid=18179
>[junit4] #
>[junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+181) (build
> 9+181)
>[junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (9+181, mixed mode,
> tiered, concurrent mark sweep gc, bsd-amd64)
>[junit4] # Problematic frame:
>[junit4] # [thread 208539 also had an error]
>[junit4] V [libjvm.dylib+0x4f49d8] Node::in(unsigned int) const+0x18
>[junit4] #
>[junit4] # No core dump will be written. Core dumps have been disabled. To
> enable core dumping, try "ulimit -c unlimited" before starting Java again
>[junit4] #
>[junit4] # An error report file with more information is saved as:
>[junit4] #
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J0/hs_err_pid85292.log
>[junit4] # [ timer expired, abort... ]
> {code}
> No hs_err or replay log on the jenkins page though.
--
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-14106) SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
[
https://issues.apache.org/jira/browse/SOLR-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999132#comment-16999132
]
Kevin Risden commented on SOLR-14106:
-
Uploaded new version of the patch and pushed update to PR.
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.4, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, SOLR-14106.patch,
> deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {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-8677) JVM SIGSEGV in Node::in
[
https://issues.apache.org/jira/browse/LUCENE-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999134#comment-16999134
]
Dawid Weiss commented on LUCENE-8677:
-
Thanks Mike.
> JVM SIGSEGV in Node::in
> ---
>
> Key: LUCENE-8677
> URL: https://issues.apache.org/jira/browse/LUCENE-8677
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Labels: jvm
>
> Jenkins:
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15
> {code}
>[junit4] # A fatal error has been detected by the Java Runtime Environment:
>[junit4] #
>[junit4] # SIGSEGV (0xb) at pc=0x000105bee9d8, pid=85292, tid=18179
>[junit4] #
>[junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+181) (build
> 9+181)
>[junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (9+181, mixed mode,
> tiered, concurrent mark sweep gc, bsd-amd64)
>[junit4] # Problematic frame:
>[junit4] # [thread 208539 also had an error]
>[junit4] V [libjvm.dylib+0x4f49d8] Node::in(unsigned int) const+0x18
>[junit4] #
>[junit4] # No core dump will be written. Core dumps have been disabled. To
> enable core dumping, try "ulimit -c unlimited" before starting Java again
>[junit4] #
>[junit4] # An error report file with more information is saved as:
>[junit4] #
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J0/hs_err_pid85292.log
>[junit4] # [ timer expired, abort... ]
> {code}
> No hs_err or replay log on the jenkins page though.
--
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] [Reopened] (LUCENE-8677) JVM SIGSEGV in Node::in
[
https://issues.apache.org/jira/browse/LUCENE-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss reopened LUCENE-8677:
-
> JVM SIGSEGV in Node::in
> ---
>
> Key: LUCENE-8677
> URL: https://issues.apache.org/jira/browse/LUCENE-8677
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Labels: jvm
>
> Jenkins:
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15
> {code}
>[junit4] # A fatal error has been detected by the Java Runtime Environment:
>[junit4] #
>[junit4] # SIGSEGV (0xb) at pc=0x000105bee9d8, pid=85292, tid=18179
>[junit4] #
>[junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+181) (build
> 9+181)
>[junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (9+181, mixed mode,
> tiered, concurrent mark sweep gc, bsd-amd64)
>[junit4] # Problematic frame:
>[junit4] # [thread 208539 also had an error]
>[junit4] V [libjvm.dylib+0x4f49d8] Node::in(unsigned int) const+0x18
>[junit4] #
>[junit4] # No core dump will be written. Core dumps have been disabled. To
> enable core dumping, try "ulimit -c unlimited" before starting Java again
>[junit4] #
>[junit4] # An error report file with more information is saved as:
>[junit4] #
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J0/hs_err_pid85292.log
>[junit4] # [ timer expired, abort... ]
> {code}
> No hs_err or replay log on the jenkins page though.
--
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-8677) JVM SIGSEGV in Node::in
[
https://issues.apache.org/jira/browse/LUCENE-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss resolved LUCENE-8677.
-
Resolution: Cannot Reproduce
> JVM SIGSEGV in Node::in
> ---
>
> Key: LUCENE-8677
> URL: https://issues.apache.org/jira/browse/LUCENE-8677
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Labels: jvm
>
> Jenkins:
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15
> {code}
>[junit4] # A fatal error has been detected by the Java Runtime Environment:
>[junit4] #
>[junit4] # SIGSEGV (0xb) at pc=0x000105bee9d8, pid=85292, tid=18179
>[junit4] #
>[junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+181) (build
> 9+181)
>[junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (9+181, mixed mode,
> tiered, concurrent mark sweep gc, bsd-amd64)
>[junit4] # Problematic frame:
>[junit4] # [thread 208539 also had an error]
>[junit4] V [libjvm.dylib+0x4f49d8] Node::in(unsigned int) const+0x18
>[junit4] #
>[junit4] # No core dump will be written. Core dumps have been disabled. To
> enable core dumping, try "ulimit -c unlimited" before starting Java again
>[junit4] #
>[junit4] # An error report file with more information is saved as:
>[junit4] #
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J0/hs_err_pid85292.log
>[junit4] # [ timer expired, abort... ]
> {code}
> No hs_err or replay log on the jenkins page though.
--
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] (SOLR-13190) Fuzzy search treated as server error instead of client error when terms are too complex
[
https://issues.apache.org/jira/browse/SOLR-13190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999118#comment-16999118
]
Andy Webb edited comment on SOLR-13190 at 12/18/19 1:11 PM:
Thanks Mike!
I've [tried
adding|https://github.com/apache/lucene-solr/compare/master...andywebb1975:maxQueryLength]
a {{maxQueryLength}} option to {{Direct(Solr)SpellChecker}} which can be set
to prevent long terms being spellchecked - it's a simple change, largely a
cut-and-paste of the {{minQueryLength}}, and as far as I can see this would
prevent us seeing the exceptions. It could default to 0, i.e. "no limit", to
maintain the existing default behaviour unless it's deliberately set. Would
this be a reasonable change to make to Lucene/Solr or do you think there might
be a better approach?
was (Author: andywebb1975):
Thanks Mike!
I've tried adding a {{maxQueryLength}} option to {{Direct(Solr)SpellChecker}}
which can be set to prevent long terms being spellchecked - it's a simple
change, largely a cut-and-paste of the {{minQueryLength}}, and as far as I can
see this would prevent us seeing the exceptions. It could default to 0, i.e.
"no limit", to maintain the existing default behaviour unless it's deliberately
set. Would this be a reasonable change to make to Lucene/Solr or do you think
there might be a better approach?
> Fuzzy search treated as server error instead of client error when terms are
> too complex
> ---
>
> Key: SOLR-13190
> URL: https://issues.apache.org/jira/browse/SOLR-13190
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We've seen a fuzzy search end up breaking the automaton and getting reported
> as a server error. This usage should be improved by
> 1) reporting as a client error, because it's similar to something like too
> many boolean clauses queries in how an operator should deal with it
> 2) report what field is causing the error, since that currently must be
> deduced from adjacent query logs and can be difficult if there are multiple
> terms in the search
> This trigger was added to defend against adversarial regex but somehow hits
> fuzzy terms as well, I don't understand enough about the automaton mechanisms
> to really know how to approach a fix there, but improving the operability is
> a good first step.
> relevant stack trace:
> {noformat}
> org.apache.lucene.util.automaton.TooComplexToDeterminizeException:
> Determinizing automaton with 13632 states and 21348 transitions would result
> in more than 1 states.
> at
> org.apache.lucene.util.automaton.Operations.determinize(Operations.java:746)
> at
> org.apache.lucene.util.automaton.RunAutomaton.(RunAutomaton.java:69)
> at
> org.apache.lucene.util.automaton.ByteRunAutomaton.(ByteRunAutomaton.java:32)
> at
> org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:247)
> at
> org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:133)
> at
> org.apache.lucene.search.FuzzyTermsEnum.(FuzzyTermsEnum.java:143)
> at org.apache.lucene.search.FuzzyQuery.getTermsEnum(FuzzyQuery.java:154)
> at
> org.apache.lucene.search.MultiTermQuery$RewriteMethod.getTermsEnum(MultiTermQuery.java:78)
> at
> org.apache.lucene.search.TermCollectingRewrite.collectTerms(TermCollectingRewrite.java:58)
> at
> org.apache.lucene.search.TopTermsRewrite.rewrite(TopTermsRewrite.java:67)
> at
> org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:310)
> at
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:442)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
> 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:1435)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:374)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
> {nof
[jira] [Resolved] (LUCENE-8617) FSDirectory tries to create MMapDirectory on non default file system
[
https://issues.apache.org/jira/browse/LUCENE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Sokolov resolved LUCENE-8617.
-
Resolution: Won't Fix
Won't fix since we are not proceeding, and the OP asked to close
> FSDirectory tries to create MMapDirectory on non default file system
>
>
> Key: LUCENE-8617
> URL: https://issues.apache.org/jira/browse/LUCENE-8617
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/store
>Affects Versions: 5.0
>Reporter: Philippe Marschall
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{org.apache.lucene.store.FSDirectory.open(Path, LockFactory)}} and
> {{org.apache.lucene.store.FSDirectory.open(Path)}} always assume the path is
> created on the default file system. If the path is not on the default file
> system {{MMapDirectory}} is the wrong choice as only the default file system
> can provide {{mmap()}}.
> In case of a non default file system {{SimpleFSDirectory}} is a good choice.
> See this bug for an example
> https://github.com/marschall/memoryfilesystem/issues/113
--
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-14070) Deprecate CloudSolrClient's ZKHost constructor
[
https://issues.apache.org/jira/browse/SOLR-14070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999139#comment-16999139
]
Jason Gerlowski commented on SOLR-14070:
bq. This is inherently insecure.
Can you elaborate a bit on this please? AFAIK clusterstate, security.json,
etc. information is going to be in ZooKeeper with the same protections,
regardless of how SolrJ finds the shape/status of a particular cluster. I
can't see how deprecating this constructor will make that information any more
or less protected.
> Deprecate CloudSolrClient's ZKHost constructor
> --
>
> Key: SOLR-14070
> URL: https://issues.apache.org/jira/browse/SOLR-14070
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>
> CloudSolrClient can be used by pointing it to a ZK cluster. This is
> inherently insecure.
> CSC can already be used in all the same ways by pointing it to a Solr cluster.
> Proposing to add a deprecation notice to the following constructor to the
> CloudSolrClient#Builder:
> {code}
> public Builder(List zkHosts, Optional zkChroot)
> {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] [Comment Edited] (SOLR-13190) Fuzzy search treated as server error instead of client error when terms are too complex
[
https://issues.apache.org/jira/browse/SOLR-13190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999118#comment-16999118
]
Andy Webb edited comment on SOLR-13190 at 12/18/19 1:18 PM:
Thanks Mike!
I've [tried adding|https://github.com/apache/lucene-solr/pull/1098] a
{{maxQueryLength}} option to {{Direct(Solr)SpellChecker}} which can be set to
prevent long terms being spellchecked - it's a simple change, largely a
cut-and-paste of the {{minQueryLength}}, and as far as I can see this would
prevent us seeing the exceptions. It could default to 0, i.e. "no limit", to
maintain the existing default behaviour unless it's deliberately set. Would
this be a reasonable change to make to Lucene/Solr or do you think there might
be a better approach?
was (Author: andywebb1975):
Thanks Mike!
I've [tried
adding|https://github.com/apache/lucene-solr/compare/master...andywebb1975:maxQueryLength]
a {{maxQueryLength}} option to {{Direct(Solr)SpellChecker}} which can be set
to prevent long terms being spellchecked - it's a simple change, largely a
cut-and-paste of the {{minQueryLength}}, and as far as I can see this would
prevent us seeing the exceptions. It could default to 0, i.e. "no limit", to
maintain the existing default behaviour unless it's deliberately set. Would
this be a reasonable change to make to Lucene/Solr or do you think there might
be a better approach?
> Fuzzy search treated as server error instead of client error when terms are
> too complex
> ---
>
> Key: SOLR-13190
> URL: https://issues.apache.org/jira/browse/SOLR-13190
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We've seen a fuzzy search end up breaking the automaton and getting reported
> as a server error. This usage should be improved by
> 1) reporting as a client error, because it's similar to something like too
> many boolean clauses queries in how an operator should deal with it
> 2) report what field is causing the error, since that currently must be
> deduced from adjacent query logs and can be difficult if there are multiple
> terms in the search
> This trigger was added to defend against adversarial regex but somehow hits
> fuzzy terms as well, I don't understand enough about the automaton mechanisms
> to really know how to approach a fix there, but improving the operability is
> a good first step.
> relevant stack trace:
> {noformat}
> org.apache.lucene.util.automaton.TooComplexToDeterminizeException:
> Determinizing automaton with 13632 states and 21348 transitions would result
> in more than 1 states.
> at
> org.apache.lucene.util.automaton.Operations.determinize(Operations.java:746)
> at
> org.apache.lucene.util.automaton.RunAutomaton.(RunAutomaton.java:69)
> at
> org.apache.lucene.util.automaton.ByteRunAutomaton.(ByteRunAutomaton.java:32)
> at
> org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:247)
> at
> org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:133)
> at
> org.apache.lucene.search.FuzzyTermsEnum.(FuzzyTermsEnum.java:143)
> at org.apache.lucene.search.FuzzyQuery.getTermsEnum(FuzzyQuery.java:154)
> at
> org.apache.lucene.search.MultiTermQuery$RewriteMethod.getTermsEnum(MultiTermQuery.java:78)
> at
> org.apache.lucene.search.TermCollectingRewrite.collectTerms(TermCollectingRewrite.java:58)
> at
> org.apache.lucene.search.TopTermsRewrite.rewrite(TopTermsRewrite.java:67)
> at
> org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:310)
> at
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:442)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
> 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:1435)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:374)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.s
[GitHub] [lucene-solr] andywebb1975 opened a new pull request #1098: SOLR-13190 - added maxQueryLength parameter
andywebb1975 opened a new pull request #1098: SOLR-13190 - added maxQueryLength parameter URL: https://github.com/apache/lucene-solr/pull/1098 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # 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 `ant precommit` and the appropriate test suite. - [ ] 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 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] (LUCENE-8596) The replacement of comments is a bug, in "UserDictionary.java"
[
https://issues.apache.org/jira/browse/LUCENE-8596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999146#comment-16999146
]
Michael Sokolov commented on LUCENE-8596:
-
That looks like a real problem we should fix. There's no way to include a
token with a "#" in a user dictionary. However it's problematic since any
change here will not be backwards-compatible.
We can just change the behavior to respect comments only at the beginning of
the line, and document the breaking change. Some users may get bit when they
upgrade (if they have been using the other comment style in their dictionaries).
Or, we can introduce some API change to support both styles of commenting. This
seems overly complex for a pretty small edge case though: I favor fixing the
behavior with a breaking change plus documentation in CHANGES. If there's no
objection, I'll merge this and add a note to CHANGES
> The replacement of comments is a bug, in "UserDictionary.java"
> --
>
> Key: LUCENE-8596
> URL: https://issues.apache.org/jira/browse/LUCENE-8596
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Reporter: miyaharas
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/lucene/analysis/kuromoji/src/java/org/apache/lucene/analysis/ja/dict/UserDictionary.java#L68]
>
> hi
> I think that this is bug.
> I think the following is correct
> {code:java}
> line = line.replaceAll ("^ #. * $", "");
> {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
[GitHub] [lucene-solr] janhoy opened a new pull request #1099: SOLR-14111: Revert SOLR13541 which breaks SSL client auth
janhoy opened a new pull request #1099: SOLR-14111: Revert SOLR13541 which breaks SSL client auth URL: https://github.com/apache/lucene-solr/pull/1099 See https://issues.apache.org/jira/browse/SOLR-14111 for details 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999151#comment-16999151 ] Tim Allison commented on SOLR-14054: [~dweiss], you are right. I only found this issue when I ran all of Tika's unit test docs against the upgraded Solr. I think users would be surprised to get a ClassNotFoundException when they send a csv file to DIH. I can add unit tests for more file format coverage (including csv) or we can configure Tika to use only the TXTParser in Solr. Let me know your preference. > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-14111) Revert SOLR-13541 which breaks SSL client auth
[ https://issues.apache.org/jira/browse/SOLR-14111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-14111: --- Affects Version/s: 8.4 8.2 8.3 8.3.1 > Revert SOLR-13541 which breaks SSL client auth > -- > > Key: SOLR-14111 > URL: https://issues.apache.org/jira/browse/SOLR-14111 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.2, 8.3, 8.4, 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Propose to revert SOLR-13541 which was the commit introducing the regression. > This means rolling back to Jetty 9.4.14, in branch_8_4 only. Then release a > bugfix version 8.4.1 with this fix. > The full fix of this issue will come in SOLR-14105 and SOLR-14106 in 8.5.0 > but is more involved, requires further upgrade of Jetty beyond 9.4.19 and is > thus not suitable for a bugfix 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] [Updated] (SOLR-14111) Revert SOLR-13541 which breaks SSL client auth
[ https://issues.apache.org/jira/browse/SOLR-14111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-14111: --- Component/s: Server > Revert SOLR-13541 which breaks SSL client auth > -- > > Key: SOLR-14111 > URL: https://issues.apache.org/jira/browse/SOLR-14111 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: 8.2, 8.3, 8.4, 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Propose to revert SOLR-13541 which was the commit introducing the regression. > This means rolling back to Jetty 9.4.14, in branch_8_4 only. Then release a > bugfix version 8.4.1 with this fix. > The full fix of this issue will come in SOLR-14105 and SOLR-14106 in 8.5.0 > but is more involved, requires further upgrade of Jetty beyond 9.4.19 and is > thus not suitable for a bugfix 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] [Commented] (SOLR-14111) Revert SOLR-13541 which breaks SSL client auth
[ https://issues.apache.org/jira/browse/SOLR-14111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999152#comment-16999152 ] Jan Høydahl commented on SOLR-14111: [~krisden] do you agree that for 8.4.1 it is safer to revert jetty than to upgrade it? As I understood, v9.4.19 is also broken wrt client auth? Doing both jetty upgrade and your fixes for a bugfix release seems a bit too much. > Revert SOLR-13541 which breaks SSL client auth > -- > > Key: SOLR-14111 > URL: https://issues.apache.org/jira/browse/SOLR-14111 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Propose to revert SOLR-13541 which was the commit introducing the regression. > This means rolling back to Jetty 9.4.14, in branch_8_4 only. Then release a > bugfix version 8.4.1 with this fix. > The full fix of this issue will come in SOLR-14105 and SOLR-14106 in 8.5.0 > but is more involved, requires further upgrade of Jetty beyond 9.4.19 and is > thus not suitable for a bugfix 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] [Resolved] (LUCENE-8561) Heap dump while search the index
[ https://issues.apache.org/jira/browse/LUCENE-8561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-8561. - Resolution: Abandoned closing since the issue is stale and there is no way to repro > Heap dump while search the index > > > Key: LUCENE-8561 > URL: https://issues.apache.org/jira/browse/LUCENE-8561 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 4.3 >Reporter: Roshini >Priority: Major > > A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_IN_PAGE_ERROR (0xc006) at pc=0x08e02b78, pid=9892, > tid=8688 > # > # JRE version: Java(TM) SE Runtime Environment (8.0_74-b02) (build > 1.8.0_74-b02) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.74-b02 mixed mode > windows-amd64 compressed oops) > # Problematic frame: > # J 45372 C2 > org.apache.lucene.store.CompoundFileDirectory.readEntries(Lorg/apache/lucene/store/Directory$IndexInputSlicer;Lorg/apache/lucene/store/Directory;Ljava/lang/String;)Ljava/util/Map; > (387 bytes) @ 0x08e02b78 [0x08e02a40+0x138] > # > # Failed to write core dump. Minidump has been disabled from the command line > # > # If you would like to submit a bug report, please visit: > # [http://bugreport.java.com/bugreport/crash.jsp] -- 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-8547) Add a build target that beasts all of the tests modified in the last commit.
[ https://issues.apache.org/jira/browse/LUCENE-8547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov updated LUCENE-8547: Summary: Add a build target that beasts all of the tests modified in the last commit. (was: Add an ant target that beasts all of the tests modified in the last commit.) > Add a build target that beasts all of the tests modified in the last commit. > > > Key: LUCENE-8547 > URL: https://issues.apache.org/jira/browse/LUCENE-8547 > Project: Lucene - Core > Issue Type: Test >Reporter: Mark Miller >Priority: Major > -- 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-8530) fix some 'rawtypes' javac warnings
[ https://issues.apache.org/jira/browse/LUCENE-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999163#comment-16999163 ] Michael Sokolov commented on LUCENE-8530: - [~cpoerschke] did you want to push this? Otherwise, we could close the issue as abandoned/won't fix > fix some 'rawtypes' javac warnings > -- > > Key: LUCENE-8530 > URL: https://issues.apache.org/jira/browse/LUCENE-8530 > Project: Lucene - Core > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: LUCENE-8530.patch > > -- 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-8517) TestRandomChains.testRandomChainsWithLargeStrings failure
[
https://issues.apache.org/jira/browse/LUCENE-8517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Sokolov resolved LUCENE-8517.
-
Resolution: Fixed
> TestRandomChains.testRandomChainsWithLargeStrings failure
> -
>
> Key: LUCENE-8517
> URL: https://issues.apache.org/jira/browse/LUCENE-8517
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Reporter: Steven Rowe
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> From
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2828/consoleText],
> reproduces for me on Java8:
> {noformat}
> Checking out Revision 216f10026b86627750e133fe24ce6a750c470695
> (refs/remotes/origin/branch_7x)
> [...]
> [java-info] java version "10.0.1"
> [java-info] OpenJDK Runtime Environment (10.0.1+10, Oracle Corporation)
> [java-info] OpenJDK 64-Bit Server VM (10.0.1+10, Oracle Corporation)
> [java-info] Test args: [-XX:-UseCompressedOops -XX:+UseConcMarkSweepGC]
> [...]
>[junit4] Suite: org.apache.lucene.analysis.core.TestRandomChains
>[junit4] 2> Exception from random analyzer:
>[junit4] 2> charfilters=
>[junit4] 2>
> org.apache.lucene.analysis.charfilter.MappingCharFilter(org.apache.lucene.analysis.charfilter.NormalizeCharMap@3ef95503,
> java.io.StringReader@70dde633)
>[junit4] 2>
> org.apache.lucene.analysis.fa.PersianCharFilter(org.apache.lucene.analysis.charfilter.MappingCharFilter@12423b20)
>[junit4] 2> tokenizer=
>[junit4] 2> org.apache.lucene.analysis.th.ThaiTokenizer()
>[junit4] 2> filters=
>[junit4] 2>
> org.apache.lucene.analysis.compound.HyphenationCompoundWordTokenFilter(ValidatingTokenFilter@7914bba7
>
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,
> org.apache.lucene.analysis.compound.hyphenation.HyphenationTree@abd7bca)
>[junit4] 2>
> Conditional:org.apache.lucene.analysis.MockGraphTokenFilter(java.util.Random@56348091,
> OneTimeWrapper@aa1c073
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1)
>[junit4] 2>
> Conditional:org.apache.lucene.analysis.shingle.FixedShingleFilter(OneTimeWrapper@4cf58fce
>
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,
> 4, , )
>[junit4] 2>
> org.apache.lucene.analysis.pt.PortugueseLightStemFilter(ValidatingTokenFilter@3a915324
>
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,keyword=false)
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestRandomChains
> -Dtests.method=testRandomChainsWithLargeStrings -Dtests.seed=92344C536D4E00F4
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en-ZW
> -Dtests.timezone=Atlantic/Faroe -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR 0.46s J2 |
> TestRandomChains.testRandomChainsWithLargeStrings <<<
>[junit4]> Throwable #1: java.lang.IllegalStateException: stage 3:
> inconsistent startOffset at pos=0: 0 vs 5; token=effort
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([92344C536D4E00F4:F86FF34234002007]:0)
>[junit4]> at
> org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:109)
>[junit4]> at
> org.apache.lucene.analysis.pt.PortugueseLightStemFilter.incrementToken(PortugueseLightStemFilter.java:48)
>[junit4]> at
> org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:68)
>[junit4]> at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException(BaseTokenStreamTestCase.java:441)
>[junit4]> at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:546)
>[junit4]> at
> org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings(TestRandomChains.java:897)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70):
> {dummy=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128)))},
> docValues:{}, maxPointsInLeafNode=214, maxMBSortInHe
[jira] [Commented] (LUCENE-8494) CFS leaks a file on exception opening it
[
https://issues.apache.org/jira/browse/LUCENE-8494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999172#comment-16999172
]
Michael Sokolov commented on LUCENE-8494:
-
Is there anything to be done here? Or ... is this just an issue with cleaning
up from a failed test (in which case I think we should close if there's no
obvious fix)
> CFS leaks a file on exception opening it
>
>
> Key: LUCENE-8494
> URL: https://issues.apache.org/jira/browse/LUCENE-8494
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/codecs
>Reporter: Robert Muir
>Priority: Major
>
> If CFS hits an exception opening its file, it will leak the file handle.
> Found by Jenkins: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/808/
> {noformat}
> java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are
> still 7 open files: {_j.cfs=1, _h.cfs=1, _e.cfs=1, _g.cfs=1, _i.cfs=1,
> _k.cfs=1, _f.cfs=1}
> ...
> Caused by: java.lang.RuntimeException: unclosed IndexInput: _f.cfs
> at
> org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:730)
> at
> org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:773)
> at
> org.apache.lucene.codecs.lucene50.Lucene50CompoundReader.(Lucene50CompoundReader.java:78)
> {noformat}
> Looks like it needs to move opening of {{handle}} into the try block
> (untested):
> {noformat}
> diff --git
> a/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
>
> b/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
> index 7526c88c20..db54ecdee2 100644
> ---
> a/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
> +++
> b/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
> @@ -75,8 +75,8 @@ final class Lucene50CompoundReader extends Directory {
> }
> expectedLength += CodecUtil.footerLength();
>
> -handle = directory.openInput(dataFileName, context);
> try {
> + handle = directory.openInput(dataFileName, context);
>CodecUtil.checkIndexHeader(handle, Lucene50CompoundFormat.DATA_CODEC,
> version, version, si.getId(), "");
>
>// NOTE: data file is too costly to verify checksum against all the
> bytes on open,
> {noformat}
--
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-8489) Provide List type constructors for BaseCompositeReader based Readers
[
https://issues.apache.org/jira/browse/LUCENE-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Sokolov resolved LUCENE-8489.
-
Resolution: Won't Fix
The discussion ended up deciding not to go forward , so I'm resolving the issue.
> Provide List type constructors for BaseCompositeReader based Readers
>
>
> Key: LUCENE-8489
> URL: https://issues.apache.org/jira/browse/LUCENE-8489
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Reporter: Namgyu Kim
>Priority: Major
> Labels: usability
> Attachments: LUCENE-8489.patch
>
>
> Currently, Reader based on BaseCompositeReader(MultiReader,
> ParallelCompositeReader, DirectoryReader) does not support List type
> constructor.
> In fact, this does not make a big difference in performance, but users will
> think positively if the API supports more variants.
> I will add the following to support this.
> 1) MultiReader
> {code:java}
> public MultiReader(List subReaders) throws IOException {
> this(subReaders, true);
> }
> public MultiReader(List subReaders, boolean closeSubReaders)
> throws IOException {
> this(subReaders.toArray(new IndexReader[0]), closeSubReaders);
> }
> {code}
> 2) ParallelCompositeReader
> {code:java}
> public ParallelCompositeReader(List readers) throws
> IOException {
> this(true, readers);
> }
> public ParallelCompositeReader(boolean closeSubReaders, List
> readers) throws IOException {
> this(closeSubReaders, readers, readers);
> }
> public ParallelCompositeReader(boolean closeSubReaders, List
> readers, List storedFieldReaders) throws IOException {
> this(closeSubReaders, readers.toArray(new CompositeReader[0]),
> storedFieldReaders.toArray(new CompositeReader[0]));
> }
> {code}
> 3) DirectoryReader
> {code:java}
> protected DirectoryReader(Directory directory, List
> segmentReaders) throws IOException {
> super(segmentReaders);
> this.directory = directory;
> }
> {code}
> 4) BaseCompositeReader
> {code:java}
> @SuppressWarnings("unchecked")
> protected BaseCompositeReader(List subReaders) throws IOException {
> this(subReaders.toArray((R[]) new IndexReader[subReaders.size()]));
> }
> {code}
> 5) Test
> I wrote a test case in "TestParallelCompositeReader".
> If you have any questions or requests, please left any comments :D
--
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-8488) Javadoc examples should be kept in sync with actual compiled code
[ https://issues.apache.org/jira/browse/LUCENE-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999175#comment-16999175 ] Michael Sokolov commented on LUCENE-8488: - [~dweiss]can you elaborate what your idea here is? Are you thinking of a way to *automatically* keep examples in javadocs up to date? > Javadoc examples should be kept in sync with actual compiled code > - > > Key: LUCENE-8488 > URL: https://issues.apache.org/jira/browse/LUCENE-8488 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Minor > > This isn't something that is done trivially, unfortunately, but can be hacked > around. And it'd help to keep the docs up-to-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] (LUCENE-8488) Javadoc examples should be kept in sync with actual compiled code
[ https://issues.apache.org/jira/browse/LUCENE-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999183#comment-16999183 ] Dawid Weiss commented on LUCENE-8488: - Precisely. I think this would have to wait until the switch to gradle is complete. Doing this in ant is going to be nighmarish. > Javadoc examples should be kept in sync with actual compiled code > - > > Key: LUCENE-8488 > URL: https://issues.apache.org/jira/browse/LUCENE-8488 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Minor > > This isn't something that is done trivially, unfortunately, but can be hacked > around. And it'd help to keep the docs up-to-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] [Resolved] (LUCENE-8494) CFS leaks a file on exception opening it
[
https://issues.apache.org/jira/browse/LUCENE-8494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss resolved LUCENE-8494.
-
Resolution: Cannot Reproduce
> CFS leaks a file on exception opening it
>
>
> Key: LUCENE-8494
> URL: https://issues.apache.org/jira/browse/LUCENE-8494
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/codecs
>Reporter: Robert Muir
>Priority: Major
>
> If CFS hits an exception opening its file, it will leak the file handle.
> Found by Jenkins: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/808/
> {noformat}
> java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are
> still 7 open files: {_j.cfs=1, _h.cfs=1, _e.cfs=1, _g.cfs=1, _i.cfs=1,
> _k.cfs=1, _f.cfs=1}
> ...
> Caused by: java.lang.RuntimeException: unclosed IndexInput: _f.cfs
> at
> org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:730)
> at
> org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:773)
> at
> org.apache.lucene.codecs.lucene50.Lucene50CompoundReader.(Lucene50CompoundReader.java:78)
> {noformat}
> Looks like it needs to move opening of {{handle}} into the try block
> (untested):
> {noformat}
> diff --git
> a/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
>
> b/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
> index 7526c88c20..db54ecdee2 100644
> ---
> a/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
> +++
> b/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
> @@ -75,8 +75,8 @@ final class Lucene50CompoundReader extends Directory {
> }
> expectedLength += CodecUtil.footerLength();
>
> -handle = directory.openInput(dataFileName, context);
> try {
> + handle = directory.openInput(dataFileName, context);
>CodecUtil.checkIndexHeader(handle, Lucene50CompoundFormat.DATA_CODEC,
> version, version, si.getId(), "");
>
>// NOTE: data file is too costly to verify checksum against all the
> bytes on open,
> {noformat}
--
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-8494) CFS leaks a file on exception opening it
[
https://issues.apache.org/jira/browse/LUCENE-8494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999184#comment-16999184
]
Dawid Weiss commented on LUCENE-8494:
-
I think we can close and reopen if needed. Please close JIRA issues with
'cannot reproduce' or a similar status indicating the issue may still be there.
I'm not sure if this is the case here.
> CFS leaks a file on exception opening it
>
>
> Key: LUCENE-8494
> URL: https://issues.apache.org/jira/browse/LUCENE-8494
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/codecs
>Reporter: Robert Muir
>Priority: Major
>
> If CFS hits an exception opening its file, it will leak the file handle.
> Found by Jenkins: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/808/
> {noformat}
> java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are
> still 7 open files: {_j.cfs=1, _h.cfs=1, _e.cfs=1, _g.cfs=1, _i.cfs=1,
> _k.cfs=1, _f.cfs=1}
> ...
> Caused by: java.lang.RuntimeException: unclosed IndexInput: _f.cfs
> at
> org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:730)
> at
> org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:773)
> at
> org.apache.lucene.codecs.lucene50.Lucene50CompoundReader.(Lucene50CompoundReader.java:78)
> {noformat}
> Looks like it needs to move opening of {{handle}} into the try block
> (untested):
> {noformat}
> diff --git
> a/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
>
> b/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
> index 7526c88c20..db54ecdee2 100644
> ---
> a/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
> +++
> b/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
> @@ -75,8 +75,8 @@ final class Lucene50CompoundReader extends Directory {
> }
> expectedLength += CodecUtil.footerLength();
>
> -handle = directory.openInput(dataFileName, context);
> try {
> + handle = directory.openInput(dataFileName, context);
>CodecUtil.checkIndexHeader(handle, Lucene50CompoundFormat.DATA_CODEC,
> version, version, si.getId(), "");
>
>// NOTE: data file is too costly to verify checksum against all the
> bytes on open,
> {noformat}
--
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-8222) TestICUTokenizerCJK failure
[
https://issues.apache.org/jira/browse/LUCENE-8222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999188#comment-16999188
]
Michael Sokolov commented on LUCENE-8222:
-
The ICU bug was marked fixed in 63.1; we should try upgrading and see we can
re-enable this test
> TestICUTokenizerCJK failure
> ---
>
> Key: LUCENE-8222
> URL: https://issues.apache.org/jira/browse/LUCENE-8222
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Priority: Major
>
> This reproduces for me:
> {code:java}
> [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestICUTokenizerCJK
> -Dtests.method=testRandomHugeStrings -Dtests.seed=2C1F4414ECB02FE4
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=pl-PL
> -Dtests.timezone=Europe/Athens -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
> [junit4] FAILURE 0.57s | TestICUTokenizerCJK.testRandomHugeStrings <<<
> [junit4] > Throwable #1: org.junit.ComparisonFailure: term 128 expected:<ー[]>
> but was:<ー[デ]>
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([2C1F4414ECB02FE4:B43C23D7B2C693AC]:0)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:201)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:325)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:329)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:869)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:668)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:566)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:479)
> [junit4] > at
> org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK.testRandomHugeStrings(TestICUTokenizerCJK.java:107)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit4] > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit4] > at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [junit4] > at java.base/java.lang.Thread.run(Thread.java:844)
> [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70):
> {dummy=PostingsFormat(name=LuceneVarGapDocFreqInterval)}, docValues:{},
> maxPointsInLeafNode=1800, maxMBSortInHeap=7.290162896982681,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@3f70f3d9),
> locale=pl-PL, timezone=Europe/Athens
> [junit4] 2> NOTE: Mac OS X 10.13.3 x86_64/Oracle Corporation 9.0.1
> (64-bit)/cpus=8,threads=1,free=150530048,total=268435456{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] [Resolved] (LUCENE-3006) Javadocs warnings should fail the build
[ https://issues.apache.org/jira/browse/LUCENE-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-3006. - Resolution: Fixed This 8-year-old issue got fixed at some point - checking javadocs is now part of precommit. I think we can close as Fixed. > Javadocs warnings should fail the build > --- > > Key: LUCENE-3006 > URL: https://issues.apache.org/jira/browse/LUCENE-3006 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 3.2, 4.0-ALPHA >Reporter: Grant Ingersoll >Priority: Major > Attachments: LUCENE-3006-javadoc-warning-cleanup.patch, > LUCENE-3006-modules-javadoc-warning-cleanup.patch, LUCENE-3006.patch, > LUCENE-3006.patch, LUCENE-3006.patch > > > We should fail the build when there are javadocs warnings, as this should not > be the Release Manager's job to fix all at once right before the release. > See > http://www.lucidimagination.com/search/document/14bd01e519f39aff/brainstorming_on_improving_the_release_process -- 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999192#comment-16999192 ] Dawid Weiss commented on SOLR-14054: Right. I don't think we can exclude the csv dependency - I recall trying to make the plain text parser avoid pulling csv classes but tika defaulted to using this class (which does some auto-detection): https://github.com/apache/tika/blob/4b330263d1759c35886e6243d5edc5426be54029/tika-parsers/src/main/java/org/apache/tika/parser/csv/TextAndCSVParser.java and csv classes are hard referenced. A test that would fail (on missing dependency) added on top of this patch would be great. > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-6236) TestICUNormalizer2CharFilter test is failing consistently
[ https://issues.apache.org/jira/browse/LUCENE-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-6236. - Resolution: Won't Fix This is no longer true on master (the test succeeds, generally), and we're not going to go back and fix an issue from 5 major versions ago, even if it is still reproducing there... > TestICUNormalizer2CharFilter test is failing consistently > - > > Key: LUCENE-6236 > URL: https://issues.apache.org/jira/browse/LUCENE-6236 > Project: Lucene - Core > Issue Type: Test >Affects Versions: 4.10.3 >Reporter: Hrishikesh Gadre >Priority: Major > > In my development environment, following unit test is failing consistently. > ant test -Dtestcase=TestICUNormalizer2CharFilter > -Dtests.method=testRandomStrings -Dtests.seed=E27DEA12D513F6FF > -Dtests.slow=true -Dtests.locale=ru -Dtests.timezone=PNT -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 >[junit4] FAILURE 1.70s | TestICUNormalizer2CharFilter.testRandomStrings <<< >[junit4]> Throwable #1: java.lang.AssertionError: startOffset 625 > expected:<5377> but was:<5378> >[junit4]> at > __randomizedtesting.SeedInfo.seed([E27DEA12D513F6FF:6AF4EAAC7617A1CA]:0) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:183) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:296) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:300) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:815) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:614) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:513) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:437) >[junit4]> at > org.apache.lucene.analysis.icu.TestICUNormalizer2CharFilter.testRandomStrings(TestICUNormalizer2CharFilter.java:186) >[junit4]> at java.lang.Thread.run(Thread.java:745) -- 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-14110) sandbox javax.script usage in tests
[ https://issues.apache.org/jira/browse/SOLR-14110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999200#comment-16999200 ] ASF subversion and git services commented on SOLR-14110: Commit 612cba38cab168a41392506cda6ebfe03a9af916 in lucene-solr's branch refs/heads/gradle-master from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=612cba3 ] SOLR-14110: sandbox javax.script usage in tests > sandbox javax.script usage in tests > --- > > Key: SOLR-14110 > URL: https://issues.apache.org/jira/browse/SOLR-14110 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Major > Fix For: 8.5 > > Attachments: SOLR-14110.patch > > > Similar to SOLR-13993 we should sandbox the use of javax.script if security > manager is present. -- 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-13983) remove or replace process execution in SystemInfoHandler
[
https://issues.apache.org/jira/browse/SOLR-13983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999209#comment-16999209
]
ASF subversion and git services commented on SOLR-13983:
Commit 56839f6ace6fa3241754d371e90fce696c00cd8e in lucene-solr's branch
refs/heads/master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=56839f6 ]
SOLR-13983: remove or replace process execution in SystemInfoHandler
> remove or replace process execution in SystemInfoHandler
>
>
> Key: SOLR-13983
> URL: https://issues.apache.org/jira/browse/SOLR-13983
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Robert Muir
>Priority: Major
> Attachments: SOLR-13983.patch
>
>
> SystemInfoHandler is the only place in solr code executing processes.
> Since solr is a server/long running process listening to HTTP, ideally
> process execution could be disabled (e.g. with security manager). But first
> this code needs to be removed or replaced, so that there is no legitimate use
> of it:
> {noformat}
> try {
> if (!Constants.WINDOWS) {
> info.add( "uname", execute( "uname -a" ) );
> info.add( "uptime", execute( "uptime" ) );
> }
> } catch( Exception ex ) {
> log.warn("Unable to execute command line tools to get operating system
> properties.", ex);
> }
> return info;
> {noformat}
> It already looks like its getting data from OS MXbean here, so maybe this
> logic is simply outdated or not needed. It seems to be "best-effort" anyway.
> Alternatively similar stuff could be fetched by reading from e.g. /proc file
> system location if needed.
--
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-13756) ivy cannot download org.restlet.ext.servlet jar
[ https://issues.apache.org/jira/browse/SOLR-13756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999213#comment-16999213 ] Zsolt Gyulavari commented on SOLR-13756: I'm working on this currently. > ivy cannot download org.restlet.ext.servlet jar > --- > > Key: SOLR-13756 > URL: https://issues.apache.org/jira/browse/SOLR-13756 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Chongchen Chen >Priority: Major > > I checkout the project and run `ant idea`, it will try to download jars. But > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > will return 404 now. > [ivy:retrieve] public: tried > [ivy:retrieve] > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > [ivy:retrieve]:: > [ivy:retrieve]:: FAILED DOWNLOADS:: > [ivy:retrieve]:: ^ see resolution messages for details ^ :: > [ivy:retrieve]:: > [ivy:retrieve]:: > org.restlet.jee#org.restlet;2.3.0!org.restlet.jar > [ivy:retrieve]:: > org.restlet.jee#org.restlet.ext.servlet;2.3.0!org.restlet.ext.servlet.jar > [ivy:retrieve]:: -- 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-13579) Create resource management API
[
https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999228#comment-16999228
]
Andrzej Bialecki commented on SOLR-13579:
-
Updated patch:
* improved algorithm for cache limits adjustments - both soft optimization and
hard control are supported, see javadocs for {{CacheManagerPool}}
* unit tests.
* {{ChangeListener}} API for monitoring resource adjustments by the framework.
> Create resource management API
> --
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
> Issue Type: New Feature
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch,
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch,
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch
>
>
> Resource management framework API supporting the goals outlined in SOLR-13578.
--
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-13579) Create resource management API
[ https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-13579: Attachment: SOLR-13579.patch > Create resource management API > -- > > Key: SOLR-13579 > URL: https://issues.apache.org/jira/browse/SOLR-13579 > Project: Solr > Issue Type: New Feature >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch > > > Resource management framework API supporting the goals outlined in SOLR-13578. -- 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-13579) Create resource management API
[ https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-13579: Attachment: (was: SOLR-13579.patch) > Create resource management API > -- > > Key: SOLR-13579 > URL: https://issues.apache.org/jira/browse/SOLR-13579 > Project: Solr > Issue Type: New Feature >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch > > > Resource management framework API supporting the goals outlined in SOLR-13578. -- 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-13983) remove or replace process execution in SystemInfoHandler
[
https://issues.apache.org/jira/browse/SOLR-13983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999242#comment-16999242
]
ASF subversion and git services commented on SOLR-13983:
Commit 8c14015e52af2568aaefbf6fb4c6e8ad01a6a8fe in lucene-solr's branch
refs/heads/branch_8x from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8c14015 ]
SOLR-13983: remove or replace process execution in SystemInfoHandler
> remove or replace process execution in SystemInfoHandler
>
>
> Key: SOLR-13983
> URL: https://issues.apache.org/jira/browse/SOLR-13983
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Robert Muir
>Priority: Major
> Attachments: SOLR-13983.patch
>
>
> SystemInfoHandler is the only place in solr code executing processes.
> Since solr is a server/long running process listening to HTTP, ideally
> process execution could be disabled (e.g. with security manager). But first
> this code needs to be removed or replaced, so that there is no legitimate use
> of it:
> {noformat}
> try {
> if (!Constants.WINDOWS) {
> info.add( "uname", execute( "uname -a" ) );
> info.add( "uptime", execute( "uptime" ) );
> }
> } catch( Exception ex ) {
> log.warn("Unable to execute command line tools to get operating system
> properties.", ex);
> }
> return info;
> {noformat}
> It already looks like its getting data from OS MXbean here, so maybe this
> logic is simply outdated or not needed. It seems to be "best-effort" anyway.
> Alternatively similar stuff could be fetched by reading from e.g. /proc file
> system location if needed.
--
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-14112) do not display load average of -1.00 on windows in admin UI
Robert Muir created SOLR-14112: -- Summary: do not display load average of -1.00 on windows in admin UI Key: SOLR-14112 URL: https://issues.apache.org/jira/browse/SOLR-14112 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 8.5 Reporter: Robert Muir Fix For: 8.5 I caused this with SOLR-13983. The OSMXBean returns -1, we should handle that in the javascript and display nothing at all, to prevent confusion. -- 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-13579) Create resource management API
[ https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-13579: Attachment: SOLR-13579.patch > Create resource management API > -- > > Key: SOLR-13579 > URL: https://issues.apache.org/jira/browse/SOLR-13579 > Project: Solr > Issue Type: New Feature >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch > > > Resource management framework API supporting the goals outlined in SOLR-13578. -- 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999247#comment-16999247 ] Tim Allison commented on SOLR-14054: [~hossman] I can replicate this now. I should have caught this before the commit. I clearly tested with Java 11 when I thought I was testing with Java 8. This is my fault. The problem is solved if we add the xml-apis dependency, which xerces requires. It looks like the earlier version of xerces didn't happen to require xml-apis on the execution paths the unit tests were exercising. I can't explain why this isn't a problem with Java 11. > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-14112) do not display load average of -1.00 on windows in admin UI
[ https://issues.apache.org/jira/browse/SOLR-14112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999252#comment-16999252 ] Robert Muir commented on SOLR-14112: untested patch: i have issues with my windows VM crashing my os X kernel from time to time :( > do not display load average of -1.00 on windows in admin UI > --- > > Key: SOLR-14112 > URL: https://issues.apache.org/jira/browse/SOLR-14112 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.5 >Reporter: Robert Muir >Priority: Major > Fix For: 8.5 > > Attachments: SOLR-14112.patch > > > I caused this with SOLR-13983. The OSMXBean returns -1, we should handle that > in the javascript and display nothing at all, to prevent confusion. -- 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-14112) do not display load average of -1.00 on windows in admin UI
[ https://issues.apache.org/jira/browse/SOLR-14112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-14112: --- Attachment: SOLR-14112.patch > do not display load average of -1.00 on windows in admin UI > --- > > Key: SOLR-14112 > URL: https://issues.apache.org/jira/browse/SOLR-14112 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.5 >Reporter: Robert Muir >Priority: Major > Fix For: 8.5 > > Attachments: SOLR-14112.patch > > > I caused this with SOLR-13983. The OSMXBean returns -1, we should handle that > in the javascript and display nothing at all, to prevent confusion. -- 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999254#comment-16999254 ] Tim Allison commented on SOLR-14054: [~dweiss], will do on a separate issue if that's ok. You can tell Tika to avoid loading the TextAndCSVParser and use the TXTParser instead via tika-config.xml. If you'd prefer this behavior either offline or in Solr, I can show you how to do that. > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-13822) Isolated Classloading from packages
[
https://issues.apache.org/jira/browse/SOLR-13822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999262#comment-16999262
]
Cassandra Targett commented on SOLR-13822:
--
[~noble.paul], [~ichattopadhyaya] - this commit:
https://github.com/apache/lucene-solr/commit/f98555854cbdb9d396c34a93fde9c1610df74882#diff-04f78a3e0960a743f6b4267e2d0f7f49
was only pushed to {{master}} branch and not {{branch_8x}}. Thus these changes
*do not* appear in 8.4, which is contrary to what this issue says. The bug
fixes and doc changes will not be available to users. I can pull out the doc
changes, but it's too late, I guess for the bug fixes?
> Isolated Classloading from packages
> ---
>
> Key: SOLR-13822
> URL: https://issues.apache.org/jira/browse/SOLR-13822
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13822.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Design is here:
> [https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?ts=5d86a8ad#]
>
> main features:
> * A new file for packages definition (/packages.json) in ZK
> * Public APIs to edit/read the file
> * The APIs are registered at {{/api/cluster/package}}
> * Classes can be loaded from the package classloader using the
> {{:}} syntax
--
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
