[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: Attachment: (was: SOLR-14051.branch_8x.00.patch) > 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] [Commented] (LUCENE-9096) Implementation of CompressingTermVectorsWriter.flushOffsets can be simpler
[
https://issues.apache.org/jira/browse/LUCENE-9096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16997967#comment-16997967
]
Adrien Grand commented on LUCENE-9096:
--
Thank you, would you like to submit a patch or open a pull request?
> Implementation of CompressingTermVectorsWriter.flushOffsets can be simpler
> --
>
> Key: LUCENE-9096
> URL: https://issues.apache.org/jira/browse/LUCENE-9096
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Affects Versions: 8.2
>Reporter: kkewwei
>Priority: Major
>
> In CompressingTermVectorsWriter.flushOffsets, we count
> sumPos and sumOffsets by the way
> {code:java}
> for (int i = 0; i < fd.numTerms; ++i) {
> int previousPos = 0;
> int previousOff = 0;
> for (int j = 0; j < fd.freqs[i]; ++j) {
> final int position = positionsBuf[fd.posStart + pos];
> final int startOffset = startOffsetsBuf[fd.offStart + pos];
> sumPos[fieldNumOff] += position - previousPos;
> sumOffsets[fieldNumOff] += startOffset - previousOff;
> previousPos = position;
> previousOff = startOffset;
> ++pos;
> }
> }
> {code}
> we always use the position - previousPos, it can be summarized like this:
> {code:java}
> (position5-position4)+(position4-position3)+(position3-position2)+(position2-position1){code}
> If we should simplify it: position5-position1
>
--
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] iverase merged pull request #1020: LUCENE-9055: Fixes the detection of lines crossing triangles through edge points
iverase merged pull request #1020: LUCENE-9055: Fixes the detection of lines crossing triangles through edge points URL: https://github.com/apache/lucene-solr/pull/1020 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-9055) Line2D misses crossings through triangle edge points
[ https://issues.apache.org/jira/browse/LUCENE-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16997996#comment-16997996 ] ASF subversion and git services commented on LUCENE-9055: - Commit 17ef175224a0314bfd24fa83645ddcdabc9aea40 in lucene-solr's branch refs/heads/master from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=17ef175 ] LUCENE-9055: Fix the detection of lines crossing triangles through edge points (#1020) > Line2D misses crossings through triangle edge points > > > Key: LUCENE-9055 > URL: https://issues.apache.org/jira/browse/LUCENE-9055 > Project: Lucene - Core > Issue Type: Bug >Reporter: Ignacio Vera >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > when a line crosses a triangle through an edge point, the crossing is not > detected. -- 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-9055) Line2D misses crossings through triangle edge points
[ https://issues.apache.org/jira/browse/LUCENE-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998000#comment-16998000 ] ASF subversion and git services commented on LUCENE-9055: - Commit f08a830a6a4880cb397cf7d071460e37ea6f8e10 in lucene-solr's branch refs/heads/branch_8x from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f08a830 ] LUCENE-9055: Fix the detection of lines crossing triangles through edge points (#1020) > Line2D misses crossings through triangle edge points > > > Key: LUCENE-9055 > URL: https://issues.apache.org/jira/browse/LUCENE-9055 > Project: Lucene - Core > Issue Type: Bug >Reporter: Ignacio Vera >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > when a line crosses a triangle through an edge point, the crossing is not > detected. -- 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-9055) Line2D misses crossings through triangle edge points
[ https://issues.apache.org/jira/browse/LUCENE-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera resolved LUCENE-9055. -- Fix Version/s: 8.5 Assignee: Ignacio Vera Resolution: Fixed > Line2D misses crossings through triangle edge points > > > Key: LUCENE-9055 > URL: https://issues.apache.org/jira/browse/LUCENE-9055 > Project: Lucene - Core > Issue Type: Bug >Reporter: Ignacio Vera >Assignee: Ignacio Vera >Priority: Major > Fix For: 8.5 > > Time Spent: 0.5h > Remaining Estimate: 0h > > when a line crosses a triangle through an edge point, the crossing is not > detected. -- 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: Attachment: SOLR-14051.patch Status: Patch Available (was: Patch Available) > 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] [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: Attachment: (was: SOLR-14051.patch) > 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] [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: Attachment: SOLR-14051.patch > 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] [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: Attachment: (was: SOLR-14051.patch) > 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] [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: Attachment: SOLR-14051.patch Status: Patch Available (was: Patch Available) > 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] [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: Attachment: (was: SOLR-14051.patch) > 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] [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: Attachment: SOLR-14092.branch_8x.00.patch Status: Patch Available (was: Patch Available) > 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] [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: Attachment: (was: SOLR-14092.branch_8x.00.patch) > 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] [Created] (LUCENE-9097) TestXYMultiPolygonShapeQueries out of memory errors in nightly runs
Ignacio Vera created LUCENE-9097: Summary: TestXYMultiPolygonShapeQueries out of memory errors in nightly runs Key: LUCENE-9097 URL: https://issues.apache.org/jira/browse/LUCENE-9097 Project: Lucene - Core Issue Type: Test Reporter: Ignacio Vera This test seems to run out of memory quite often during nightly runs. Let's decrease the number of shapes it uses. -- 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] iverase opened a new pull request #1089: LUCENE-9097: Decrease the number of shape used in multi-polygon tests
iverase opened a new pull request #1089: LUCENE-9097: Decrease the number of shape used in multi-polygon tests URL: https://github.com/apache/lucene-solr/pull/1089 Decrease the number so test run faster and minimise the possibility of OOM errors. 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-7893) Document ZooKeeper SSL support
[
https://issues.apache.org/jira/browse/SOLR-7893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998034#comment-16998034
]
Andor Molnar commented on SOLR-7893:
[~janhoy] [~jornfranke]
I just updated the ZK jira. Sorry for the delay.
> Document ZooKeeper SSL support
> --
>
> Key: SOLR-7893
> URL: https://issues.apache.org/jira/browse/SOLR-7893
> Project: Solr
> Issue Type: Sub-task
> Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Labels: ssl, zookeeper
>
> Once ZooKeeper supports SSL properly, Solr should start using it for all
> communication. See comments in
> https://cwiki.apache.org/confluence/display/solr/Enabling+SSL
> {quote}
> ZooKeeper does not support encrypted communication with clients like Solr.
> There are several related JIRA tickets where SSL support is being
> planned/worked on: ZOOKEEPER-235; ZOOKEEPER-236; ZOOKEEPER-733; and
> ZOOKEEPER-1000.
> {quote}
--
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-9096) Implementation of CompressingTermVectorsWriter.flushOffsets can be simpler
[
https://issues.apache.org/jira/browse/LUCENE-9096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998074#comment-16998074
]
kkewwei commented on LUCENE-9096:
-
[~jpountz] It's my pleasure to do it.
> Implementation of CompressingTermVectorsWriter.flushOffsets can be simpler
> --
>
> Key: LUCENE-9096
> URL: https://issues.apache.org/jira/browse/LUCENE-9096
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Affects Versions: 8.2
>Reporter: kkewwei
>Priority: Major
>
> In CompressingTermVectorsWriter.flushOffsets, we count
> sumPos and sumOffsets by the way
> {code:java}
> for (int i = 0; i < fd.numTerms; ++i) {
> int previousPos = 0;
> int previousOff = 0;
> for (int j = 0; j < fd.freqs[i]; ++j) {
> final int position = positionsBuf[fd.posStart + pos];
> final int startOffset = startOffsetsBuf[fd.offStart + pos];
> sumPos[fieldNumOff] += position - previousPos;
> sumOffsets[fieldNumOff] += startOffset - previousOff;
> previousPos = position;
> previousOff = startOffset;
> ++pos;
> }
> }
> {code}
> we always use the position - previousPos, it can be summarized like this:
> {code:java}
> (position5-position4)+(position4-position3)+(position3-position2)+(position2-position1){code}
> If we should simplify it: position5-position1
>
--
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-14094) TestSolrCachePerf is flaky
[
https://issues.apache.org/jira/browse/SOLR-14094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998152#comment-16998152
]
ASF subversion and git services commented on SOLR-14094:
Commit b5a2cfba4fd9d9443eaf07e4c93540aaed1c3634 in lucene-solr's branch
refs/heads/gradle-master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b5a2cfb ]
SOLR-14094: Enable this test again in master.
> TestSolrCachePerf is flaky
> --
>
> Key: SOLR-14094
> URL: https://issues.apache.org/jira/browse/SOLR-14094
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Adrien Grand
>Assignee: Andrzej Bialecki
>Priority: Major
>
> I hit the below failure while building the RC.
> {noformat}
>[junit4] Suite: org.apache.solr.search.TestSolrCachePerf
>[junit4] 2> 921086 INFO
> (SUITE-TestSolrCachePerf-seed#[1D407DF9BFA38129]-worker) [ ]
> o.a.s.SolrTestCaseJ4 Created dataDir:
> /home/jpountz/.lucene-releases/8.4.0/lucene-solr/solr/build/solr-core/test/J2/temp/solr.search.TestSolrCachePerf_1D407DF9BFA38129-001/data-dir-97-001
>[junit4] 2> 921086 WARN
> (SUITE-TestSolrCachePerf-seed#[1D407DF9BFA38129]-worker) [ ]
> o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=16 numCloses=16
>[junit4] 2> 921086 INFO
> (SUITE-TestSolrCachePerf-seed#[1D407DF9BFA38129]-worker) [ ]
> o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true)
> w/NUMERIC_DOCVALUES_SYSPROP=false
>[junit4] 2> 921087 INFO
> (SUITE-TestSolrCachePerf-seed#[1D407DF9BFA38129]-worker) [ ]
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true) via:
> @org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN,
> clientAuth=NaN)
>[junit4] 2> 921087 INFO
> (SUITE-TestSolrCachePerf-seed#[1D407DF9BFA38129]-worker) [ ]
> o.a.s.SolrTestCaseJ4 SecureRandom sanity checks:
> test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
>[junit4] 2> 921088 INFO
> (TEST-TestSolrCachePerf.testGetPutCompute-seed#[1D407DF9BFA38129]) [ ]
> o.a.s.SolrTestCaseJ4 ###Starting testGetPutCompute
>[junit4] 2> 927857 INFO
> (TEST-TestSolrCachePerf.testGetPutCompute-seed#[1D407DF9BFA38129]) [ ]
> o.a.s.SolrTestCaseJ4 ###Ending testGetPutCompute
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestSolrCachePerf
> -Dtests.method=testGetPutCompute -Dtests.seed=1D407DF9BFA38129
> -Dtests.slow=true -Dtests.locale=ar-QA -Dtests.timezone=AGT
> -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 6.77s J2 | TestSolrCachePerf.testGetPutCompute <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Cache FastLRUCache:
> compute ratio should be higher or equal to get/put ratio: 0.9917 >= 0.9941
>[junit4]>at
> __randomizedtesting.SeedInfo.seed([1D407DF9BFA38129:9DE8FAF1672A99B6]:0)
>[junit4]>at
> org.apache.solr.search.TestSolrCachePerf.assertGreaterThanOrEqual(TestSolrCachePerf.java:84)
>[junit4]>at
> org.apache.solr.search.TestSolrCachePerf.lambda$testGetPutCompute$0(TestSolrCachePerf.java:75)
>[junit4]>at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]>at
> org.apache.solr.search.TestSolrCachePerf.testGetPutCompute(TestSolrCachePerf.java:73)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
>[junit4] 2> NOTE: leaving temporary files on disk at:
> /home/jpountz/.lucene-releases/8.4.0/lucene-solr/solr/build/solr-core/test/J2/temp/solr.search.TestSolrCachePerf_1D407DF9BFA38129-001
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene84): {},
> docValues:{}, maxPointsInLeafNode=825, maxMBSortInHeap=7.419122986645501,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@d7facc8),
> locale=ar-QA, timezone=AGT
>[junit4] 2> NOTE: Linux 4.4.0-104-generic amd64/Oracle Corporation
> 1.8.0_151 (64-bit)/cpus=12,threads=1,free=188791576,total=528482304
>[junit4] 2> NOTE: All tests run in this JVM: [TestCryptoKeys,
> AtomicUpdatesTest, TestNestedUpdateProcessor, SolrPluginUtilsTest,
> TestStressCloudBlindAtomicUpdates, DirectoryFactoryTest, TaggerTest,
> IndexSizeTriggerMixedBoundsTest, NumberUtilsTest, TestZkChroot,
> HdfsDirectoryTest, RollingRestartTest, TestSolrCLIRunExample,
> ClusterStateTest, DocValuesMultiTest, TestLeaderElectionWithEmptyReplica,
> TestCustomSort, TestSchemaManager, TestInPlaceUpdatesDistrib,
> TestReloadAndDeleteDocs, HighlighterConfigTest, MBeansHandlerTest,
> PeerSyncWithIndexFingerprintCachingTest, SubstringBytesRefFilterTest,
> TestChildDocTransformer, IndexSizeTriggerTest, HealthCheckHandlerTest,
> SuggesterFSTTest, TestLucene
[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=16998151#comment-16998151
]
ASF subversion and git services commented on SOLR-14096:
Commit ee0b066ab63ab21645b91c5a190b157fa56b6ca7 in lucene-solr's branch
refs/heads/gradle-master from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ee0b066 ]
SOLR-14096: Stopping -Denable.packages=true from leaking to other tests
> 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: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>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] [Commented] (SOLR-14087) disable package store API if -Denable.packages not set to true
[ https://issues.apache.org/jira/browse/SOLR-14087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998150#comment-16998150 ] ASF subversion and git services commented on SOLR-14087: Commit 7dfea5fe33fe0aea7eda001c046a3537402532f2 in lucene-solr's branch refs/heads/gradle-master from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7dfea5f ] SOLR-14087: Changing the filestore dir name back to filestore from .filestore > disable package store API if -Denable.packages not set to true > -- > > Key: SOLR-14087 > URL: https://issues.apache.org/jira/browse/SOLR-14087 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Blocker > Fix For: 8.4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Package store is only used by package manager. For better security, we can > disable it by default -- 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=16998154#comment-16998154
]
ASF subversion and git services commented on SOLR-14099:
Commit e6b5da5c12c37dce6f3d767bbafb75b28795ab2f in lucene-solr's branch
refs/heads/gradle-master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e6b5da5 ]
SOLR-14099: work around @LogLevel bug in LoggingHandlerTest
> @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
> Attachments: 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-14081) rewrite FullSolrCloudDistribCmdsTest to extend SolrCloudTestCase
[ https://issues.apache.org/jira/browse/SOLR-14081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998155#comment-16998155 ] ASF subversion and git services commented on SOLR-14081: Commit db11e9e9a2c07136399ba002f2bbefe8c611b0a0 in lucene-solr's branch refs/heads/gradle-master from Chris M. Hostetter [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=db11e9e ] SOLR-14081: re-implement FullSolrCloudDistribCmdsTest to extend SolrCloudTestCase > rewrite FullSolrCloudDistribCmdsTest to extend SolrCloudTestCase > > > Key: SOLR-14081 > URL: https://issues.apache.org/jira/browse/SOLR-14081 > Project: Solr > Issue Type: Sub-task > 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.4 > > Attachments: SOLR-14081.patch, SOLR-14081.patch, SOLR-14081.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] [Commented] (LUCENE-9094) Ban ObjectInputStream and ObjectOutputStream in forbidden-apis
[
https://issues.apache.org/jira/browse/LUCENE-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998153#comment-16998153
]
ASF subversion and git services commented on LUCENE-9094:
-
Commit dc35e5752bcdbf85ad52b958723db008502061a6 in lucene-solr's branch
refs/heads/gradle-master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=dc35e57 ]
LUCENE-9094: Ban ObjectInputStream and ObjectOutputStream in forbidden-apis
> Ban ObjectInputStream and ObjectOutputStream in forbidden-apis
> --
>
> Key: LUCENE-9094
> URL: https://issues.apache.org/jira/browse/LUCENE-9094
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Major
> Fix For: 8.5
>
> Attachments: LUCENE-9094.patch
>
>
> suggested build failure message:
> {quote}
> [forbidden-apis] Forbidden class/interface use: java.io.ObjectInputStream
> [Java deserialization is unsafe when the data is untrusted. The java
> developer is powerless: no checks or casts help, exploitation can happen in
> places such as clinit or finalize!]
> {quote}
> I will whitelist existing places doing this for now.
--
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-9055) Line2D misses crossings through triangle edge points
[ https://issues.apache.org/jira/browse/LUCENE-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998156#comment-16998156 ] ASF subversion and git services commented on LUCENE-9055: - Commit 17ef175224a0314bfd24fa83645ddcdabc9aea40 in lucene-solr's branch refs/heads/gradle-master from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=17ef175 ] LUCENE-9055: Fix the detection of lines crossing triangles through edge points (#1020) > Line2D misses crossings through triangle edge points > > > Key: LUCENE-9055 > URL: https://issues.apache.org/jira/browse/LUCENE-9055 > Project: Lucene - Core > Issue Type: Bug >Reporter: Ignacio Vera >Assignee: Ignacio Vera >Priority: Major > Fix For: 8.5 > > Time Spent: 0.5h > Remaining Estimate: 0h > > when a line crosses a triangle through an edge point, the crossing is not > detected. -- 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-13974) Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error
[
https://issues.apache.org/jira/browse/SOLR-13974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998206#comment-16998206
]
Jacek Kikiewicz commented on SOLR-13974:
Hello [~erickerickson]
I am happy to test this - sure.
Realistically however I probably not manage to do this this year.
Thank you VERY much for assistance and help.
> Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error
> --
>
> Key: SOLR-13974
> URL: https://issues.apache.org/jira/browse/SOLR-13974
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: http2
>Affects Versions: 8.3, 8.3.1
>Reporter: Jacek Kikiewicz
>Priority: Major
>
> We are running a solrcloud clusters with Solr 8.3 , from time to time during
> data import we see following errors in solr log:
> {code:java}
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error at
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.doDistribFinish(DistributedZkUpdateProcessor.java:1189)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1096)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2576) at
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:803) at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:582) at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:424)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> at
> org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:311)
> at
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:265)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:505) at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(E
[jira] [Created] (SOLR-14103) hadoop-minicluster dependency is not used anywhere?
Dawid Weiss created SOLR-14103: -- Summary: 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 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] [Created] (SOLR-14104) Remove unused stale files from licenses/
Dawid Weiss created SOLR-14104: -- Summary: Remove unused stale files from licenses/ Key: SOLR-14104 URL: https://issues.apache.org/jira/browse/SOLR-14104 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Dawid Weiss -- 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-14104) Remove unused stale files from licenses/
[ https://issues.apache.org/jira/browse/SOLR-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998232#comment-16998232 ] ASF subversion and git services commented on SOLR-14104: Commit 079ddeb1f43f0243273f29f39238c3ec777cbefb in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=079ddeb ] SOLR-14104: Remove a truckload of unused licenses and notice files. > Remove unused stale files from licenses/ > > > Key: SOLR-14104 > URL: https://issues.apache.org/jira/browse/SOLR-14104 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >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] [Assigned] (SOLR-14104) Remove unused stale files from licenses/
[ https://issues.apache.org/jira/browse/SOLR-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss reassigned SOLR-14104: -- Assignee: Dawid Weiss > Remove unused stale files from licenses/ > > > Key: SOLR-14104 > URL: https://issues.apache.org/jira/browse/SOLR-14104 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >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] [Resolved] (SOLR-14104) Remove unused stale files from licenses/
[ https://issues.apache.org/jira/browse/SOLR-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved SOLR-14104. Resolution: Fixed > Remove unused stale files from licenses/ > > > Key: SOLR-14104 > URL: https://issues.apache.org/jira/browse/SOLR-14104 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >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] (SOLR-14104) Remove unused stale files from licenses/
[ https://issues.apache.org/jira/browse/SOLR-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998259#comment-16998259 ] ASF subversion and git services commented on SOLR-14104: Commit 868d5b4ae6f482741a2a7ff64c1d8abcc83fffad in lucene-solr's branch refs/heads/gradle-master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=868d5b4 ] SOLR-14104: clean up asm license. > Remove unused stale files from licenses/ > > > Key: SOLR-14104 > URL: https://issues.apache.org/jira/browse/SOLR-14104 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >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] (SOLR-14104) Remove unused stale files from licenses/
[ https://issues.apache.org/jira/browse/SOLR-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998258#comment-16998258 ] ASF subversion and git services commented on SOLR-14104: Commit 98965b6c9865d66c0a610eaa863eadd6858947d1 in lucene-solr's branch refs/heads/gradle-master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=98965b6 ] SOLR-14104: clean up asm license. > Remove unused stale files from licenses/ > > > Key: SOLR-14104 > URL: https://issues.apache.org/jira/browse/SOLR-14104 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >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] (SOLR-14104) Remove unused stale files from licenses/
[ https://issues.apache.org/jira/browse/SOLR-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998261#comment-16998261 ] ASF subversion and git services commented on SOLR-14104: Commit 0f7a046e853159b8e84c5e5102337d3808170b50 in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0f7a046 ] SOLR-14104: clean up asm license. > Remove unused stale files from licenses/ > > > Key: SOLR-14104 > URL: https://issues.apache.org/jira/browse/SOLR-14104 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >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] (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=16998266#comment-16998266 ] Dawid Weiss commented on SOLR-14103: jersey-core, jersey-server and netty-all also seem to be redundant. I removed them from the ivy file, running tests now. > 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-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=16998292#comment-16998292 ] ASF subversion and git services commented on SOLR-14103: Commit 4b7bb7cf29e7cb66ab0d95f1c4e451226a5c6d64 in lucene-solr's branch refs/heads/gradle-master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4b7bb7c ] SOLR-14103: remove unused dependencies and their checksums, licenses. > 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-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=16998293#comment-16998293 ] Dawid Weiss commented on SOLR-14103: I've removed all of these and modified the ivy file. All solr core tests pass. modified: solr/core/ivy.xml deleted:solr/licenses/hadoop-minicluster-3.2.0.jar.sha1 deleted:solr/licenses/hadoop-minicluster-LICENSE-ASL.txt deleted:solr/licenses/hadoop-minicluster-NOTICE.txt deleted:solr/licenses/jersey-core-1.19.jar.sha1 deleted:solr/licenses/jersey-core-LICENSE-CDDL.txt deleted:solr/licenses/jersey-server-1.19.jar.sha1 deleted:solr/licenses/jersey-server-LICENSE-CDDL.txt deleted:solr/licenses/netty-all-4.1.29.Final.jar.sha1 deleted:solr/licenses/netty-all-LICENSE-ASL.txt deleted:solr/licenses/netty-all-NOTICE.txt > 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] [Created] (SOLR-14105) SSL not working in branch_8x
Jan Høydahl created SOLR-14105:
--
Summary: 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
Fix For: 8.5
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] [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=16998306#comment-16998306 ] ASF subversion and git services commented on SOLR-14103: Commit 845b20224dc933ac56bc72654fb20c84bde6b7dd in lucene-solr's branch refs/heads/gradle-master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=845b202 ] SOLR-14103: follow up > 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] [Created] (SOLR-14106) SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
Jan Høydahl created SOLR-14106:
--
Summary: 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)
Affects Versions: 8.3.1, 8.2
Reporter: Jan Høydahl
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) SSL not working in branch_8x
[
https://issues.apache.org/jira/browse/SOLR-14105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998318#comment-16998318
]
Jan Høydahl commented on SOLR-14105:
PS: This Jira needs no CHANGES.txt entry as it is all yet in unreleased code
> 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
>Priority: Major
> Fix For: 8.5
>
>
> 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] [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=16998321#comment-16998321
]
Jan Høydahl commented on SOLR-14106:
Note that even 8.1.1 docker img runs with Java11, so there is no difference
there. Only change between the two tests is solr version.
> 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)
>Affects Versions: 8.2, 8.3.1
>Reporter: Jan Høydahl
>Priority: Major
>
> 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-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=16998322#comment-16998322 ] Kevin Risden commented on SOLR-14103: - [~dweiss] is Gradle allowing transitive dependencies? I think hadoop-minicluster is probably pulled in via like hadoop test framework or something. > 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
[GitHub] [lucene-solr] tuftii opened a new pull request #1090: Update README.txt
tuftii opened a new pull request #1090: Update README.txt URL: https://github.com/apache/lucene-solr/pull/1090 Update the analysis-extras README to include reference to including solr-analysis-extras jar. I struggled to work out what was missing when I was using ICU for the first time, and this caught me out. There may be a better way of phrasing it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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] [Created] (LUCENE-9098) Report problematic term value when fuzzy query is too complex
Mike Drob created LUCENE-9098: - Summary: Report problematic term value when fuzzy query is too complex Key: LUCENE-9098 URL: https://issues.apache.org/jira/browse/LUCENE-9098 Project: Lucene - Core Issue Type: Bug Components: core/search Reporter: Mike Drob Assignee: Mike Drob Fix For: master (9.0) This is the lucene compliment to SOLR-13190, when fuzzy query gets a term that expands to too many states, we throw an exception but don't provide insight on the problematic term. We should improve the error reporting. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob opened a new pull request #1091: LUCENE-9098 Report bad term for fuzzy query
madrob opened a new pull request #1091: LUCENE-9098 Report bad term for fuzzy query URL: https://github.com/apache/lucene-solr/pull/1091 # Description When a fuzzy query encounters a term that is too complex, the exception should report the term instead of a cryptic message about too many states. This supersedes #554 # Solution Catch the exception and regrow it with term information present. # Tests Added tests which generate long terms and feed them to fuzzy query. # Checklist Please review the following and check all that apply: - [x] 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. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] 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) - [x] I have developed this patch against the `master` branch. - [x] I have run `ant precommit` and the appropriate test suite. - [x] 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] [Updated] (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:all-tabpanel
]
Chris M. Hostetter updated SOLR-14099:
--
Attachment: SOLR-14099.patch
Status: Patch Available (was: Patch Available)
updated patch, resolve final nocommit and fix lingering unused imports
All tests pass.
> @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
> 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-13696) DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest failures due commitWithin/openSearcher delays
[
https://issues.apache.org/jira/browse/SOLR-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998441#comment-16998441
]
ASF subversion and git services commented on SOLR-13696:
Commit 33e44b2fd6973aa801d8bad2b64ff1931d885ee3 in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=33e44b2 ]
SOLR-13696: AwaitsFix RoutedAliasUpdateProcessorTest (and subclasses)
The helper method RoutedAliasUpdateProcessorTest.addDocsAndCommit doesn't
garuntee docs have been committed when it returns, causing threading/timing
bugs in tests that use it as a gate for making subsequent assertions -- causing
a steady stream of jenkins test failures
> DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest
> failures due commitWithin/openSearcher delays
>
>
> Key: SOLR-13696
> URL: https://issues.apache.org/jira/browse/SOLR-13696
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Gus Heck
>Priority: Major
> Attachments: thetaphi_Lucene-Solr-8.x-MacOSX_272.log.txt
>
>
> Recent jenkins failure...
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/272/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
> {noformat}
> Stack Trace:
> java.lang.AssertionError: expected:<16> but was:<15>
> at
> __randomizedtesting.SeedInfo.seed([DB6DC28D5560B1D2:E295833E1541FDB9]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:677
> )
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> Digging into the logs, the problem appears to be in the way the test
> verifies/assumes docs have been committed.
--
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-13696) DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest failures due commitWithin/openSearcher delays
[
https://issues.apache.org/jira/browse/SOLR-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998449#comment-16998449
]
ASF subversion and git services commented on SOLR-13696:
Commit c9bd7cedc270fc08b480b229930dc456a5cfdd88 in lucene-solr's branch
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c9bd7ce ]
SOLR-13696: AwaitsFix RoutedAliasUpdateProcessorTest (and subclasses)
The helper method RoutedAliasUpdateProcessorTest.addDocsAndCommit doesn't
garuntee docs have been committed when it returns, causing threading/timing
bugs in tests that use it as a gate for making subsequent assertions -- causing
a steady stream of jenkins test failures
(cherry picked from commit 33e44b2fd6973aa801d8bad2b64ff1931d885ee3)
> DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest
> failures due commitWithin/openSearcher delays
>
>
> Key: SOLR-13696
> URL: https://issues.apache.org/jira/browse/SOLR-13696
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Gus Heck
>Priority: Major
> Attachments: thetaphi_Lucene-Solr-8.x-MacOSX_272.log.txt
>
>
> Recent jenkins failure...
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/272/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
> {noformat}
> Stack Trace:
> java.lang.AssertionError: expected:<16> but was:<15>
> at
> __randomizedtesting.SeedInfo.seed([DB6DC28D5560B1D2:E295833E1541FDB9]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:677
> )
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> Digging into the logs, the problem appears to be in the way the test
> verifies/assumes docs have been committed.
--
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=16998485#comment-16998485
]
Lucene/Solr QA commented on SOLR-14099:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
9s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 2s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 46m
28s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
21s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 51m 2s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14099 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12989032/SOLR-14099.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 33e44b2fd69 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/631/testReport/ |
| modules | C: solr/core solr/test-framework U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/631/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> @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
> 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-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=16998507#comment-16998507 ] Dawid Weiss commented on SOLR-14103: Gradle does. We don't pull it in though -- it'd be on the list of dependencies under licenses (and it isn't). In fact, I've just removed it from ivy/ ant along with the stuff above and all tests still pass. I think these are just redundant and I'll remove them from master. > 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-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=16998509#comment-16998509 ] Dawid Weiss commented on SOLR-14103: You can try the ant build/ tests on gradle-master, Kevin. It's essentially the same code as master with those dependencies removed. I'll commit the removal tomorrow unless somebody can tell me what these are used for (they're only included in test.DfsMiniCluster ivy configuration): https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=commitdiff;h=4b7bb7c > 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-14067) Deprecate StatelessScriptUpdateProcessor and disabled by default
[ https://issues.apache.org/jira/browse/SOLR-14067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998527#comment-16998527 ] Anshum Gupta commented on SOLR-14067: - +1 on the direction in which this is going. SSUP is just scary in every way for users who don't understand it's implications, as well as for people who download and run Solr as is i.e. without disabling this. > Deprecate StatelessScriptUpdateProcessor and disabled by default > > > Key: SOLR-14067 > URL: https://issues.apache.org/jira/browse/SOLR-14067 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.4 > > Time Spent: 10m > Remaining Estimate: 0h > > We should eliminate all scripting capabilities within Solr. Let us start with > the StatelessScriptUpdateProcessor deprecation/removal. -- 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-13974) Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error
[
https://issues.apache.org/jira/browse/SOLR-13974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998532#comment-16998532
]
Erick Erickson commented on SOLR-13974:
---
There's no hurry here, Solr 8.5 won't be released for, probably, 2-3 months
(that's a guess). This is mostly to insure that the Jetty issue you pointed out
really addresses the problem since I don't have a good way to test.
Regardless, this upgrade is almost certainly here to stay. That said, there may
be a few issues that shake out over the next little bit, there's another Solr
Jira for an SSL related issue that just came over the transom. So please also
report any anomalies you find.
> Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error
> --
>
> Key: SOLR-13974
> URL: https://issues.apache.org/jira/browse/SOLR-13974
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: http2
>Affects Versions: 8.3, 8.3.1
>Reporter: Jacek Kikiewicz
>Priority: Major
>
> We are running a solrcloud clusters with Solr 8.3 , from time to time during
> data import we see following errors in solr log:
> {code:java}
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error at
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.doDistribFinish(DistributedZkUpdateProcessor.java:1189)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1096)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2576) at
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:803) at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:582) at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:424)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> at
> org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:311)
> at
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:265)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:505) at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at
> org.eclipse.jetty.util.thread
[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=16998533#comment-16998533
]
Andy Webb commented on SOLR-13190:
--
hi, we've seeing {{TooComplexToDeterminizeException}} in production - our
current mitigation is to avoid asking Solr to spellcheck long queries.
The exception can be triggered in 8.3.0 as follows:
# create a collection (e.g. {{default}}) using the {{_default}} config
# add a single document with some random content in the {{\_text_}} field
# send a spellcheck request such as
{{/solr/default/spell?q=kjshgkjahdskjgadhsgkahsdkgskd%C4%A3shdjghaksdhdhdkadhgkjahsdkjgahskdghjjhgkasjdhgajhdskgjahsdgkahjsdkjghaksd}}
The presence of a multi-byte character seems to matter - without it the query
can be several times longer before a StackOverflowError is thrown instead.
Would you expect the PR on this ticket to resolve this? If so, we'd be very
keen to see it merged in please. (I'll try spinning up a custom build Solr with
the patch applied to test this myself.)
thanks,
Andy
> 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: 10m
> 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
[GitHub] [lucene-solr] mbwaheed commented on a change in pull request #1055: SOLR-13932 Review directory locking and Blob interactions
mbwaheed commented on a change in pull request #1055: SOLR-13932 Review
directory locking and Blob interactions
URL: https://github.com/apache/lucene-solr/pull/1055#discussion_r359001769
##
File path:
solr/core/src/java/org/apache/solr/store/blob/metadata/ServerSideMetadata.java
##
@@ -276,7 +224,7 @@ private String getSolrDirectoryHash(Directory coreDir)
throws NoSuchAlgorithmExc
digest.update(Long.toString(coreDir.fileLength(fileName)).getBytes());
} catch (FileNotFoundException fnf) {
Review comment:
Need to handle java.nio.file.NoSuchFileException too.
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-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=16998537#comment-16998537
]
Andy Webb commented on SOLR-13190:
--
(Obviously we don't expect to receive a useful correction for such queries!)
> 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: 10m
> 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-13696) DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest failures due commitWithin/openSearcher delays
[
https://issues.apache.org/jira/browse/SOLR-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998541#comment-16998541
]
Ishan Chattopadhyaya commented on SOLR-13696:
-
Are these related to https://issues.apache.org/jira/browse/SOLR-13997?
> DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest
> failures due commitWithin/openSearcher delays
>
>
> Key: SOLR-13696
> URL: https://issues.apache.org/jira/browse/SOLR-13696
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Gus Heck
>Priority: Major
> Attachments: thetaphi_Lucene-Solr-8.x-MacOSX_272.log.txt
>
>
> Recent jenkins failure...
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/272/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
> {noformat}
> Stack Trace:
> java.lang.AssertionError: expected:<16> but was:<15>
> at
> __randomizedtesting.SeedInfo.seed([DB6DC28D5560B1D2:E295833E1541FDB9]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:677
> )
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> Digging into the logs, the problem appears to be in the way the test
> verifies/assumes docs have been committed.
--
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-13696) DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest failures due commitWithin/openSearcher delays
[
https://issues.apache.org/jira/browse/SOLR-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998449#comment-16998449
]
Ishan Chattopadhyaya edited comment on SOLR-13696 at 12/17/19 8:14 PM:
---
Commit c9bd7cedc270fc08b480b229930dc456a5cfdd88 in lucene-solr's branch
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c9bd7ce ]
SOLR-13696: AwaitsFix RoutedAliasUpdateProcessorTest (and subclasses)
The helper method RoutedAliasUpdateProcessorTest.addDocsAndCommit doesn't
guarantee docs have been committed when it returns, causing threading/timing
bugs in tests that use it as a gate for making subsequent assertions -- causing
a steady stream of jenkins test failures
(cherry picked from commit 33e44b2fd6973aa801d8bad2b64ff1931d885ee3)
was (Author: jira-bot):
Commit c9bd7cedc270fc08b480b229930dc456a5cfdd88 in lucene-solr's branch
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c9bd7ce ]
SOLR-13696: AwaitsFix RoutedAliasUpdateProcessorTest (and subclasses)
The helper method RoutedAliasUpdateProcessorTest.addDocsAndCommit doesn't
garuntee docs have been committed when it returns, causing threading/timing
bugs in tests that use it as a gate for making subsequent assertions -- causing
a steady stream of jenkins test failures
(cherry picked from commit 33e44b2fd6973aa801d8bad2b64ff1931d885ee3)
> DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest
> failures due commitWithin/openSearcher delays
>
>
> Key: SOLR-13696
> URL: https://issues.apache.org/jira/browse/SOLR-13696
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Gus Heck
>Priority: Major
> Attachments: thetaphi_Lucene-Solr-8.x-MacOSX_272.log.txt
>
>
> Recent jenkins failure...
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/272/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
> {noformat}
> Stack Trace:
> java.lang.AssertionError: expected:<16> but was:<15>
> at
> __randomizedtesting.SeedInfo.seed([DB6DC28D5560B1D2:E295833E1541FDB9]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:677
> )
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> Digging into the logs, the problem appears to be in the way the test
> verifies/assumes docs have been committed.
--
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-13696) DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest failures due commitWithin/openSearcher delays
[
https://issues.apache.org/jira/browse/SOLR-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998441#comment-16998441
]
Ishan Chattopadhyaya edited comment on SOLR-13696 at 12/17/19 8:14 PM:
---
Commit 33e44b2fd6973aa801d8bad2b64ff1931d885ee3 in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=33e44b2 ]
SOLR-13696: AwaitsFix RoutedAliasUpdateProcessorTest (and subclasses)
The helper method RoutedAliasUpdateProcessorTest.addDocsAndCommit doesn't
guarantee docs have been committed when it returns, causing threading/timing
bugs in tests that use it as a gate for making subsequent assertions -- causing
a steady stream of jenkins test failures
was (Author: jira-bot):
Commit 33e44b2fd6973aa801d8bad2b64ff1931d885ee3 in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=33e44b2 ]
SOLR-13696: AwaitsFix RoutedAliasUpdateProcessorTest (and subclasses)
The helper method RoutedAliasUpdateProcessorTest.addDocsAndCommit doesn't
garuntee docs have been committed when it returns, causing threading/timing
bugs in tests that use it as a gate for making subsequent assertions -- causing
a steady stream of jenkins test failures
> DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest
> failures due commitWithin/openSearcher delays
>
>
> Key: SOLR-13696
> URL: https://issues.apache.org/jira/browse/SOLR-13696
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Gus Heck
>Priority: Major
> Attachments: thetaphi_Lucene-Solr-8.x-MacOSX_272.log.txt
>
>
> Recent jenkins failure...
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/272/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
> {noformat}
> Stack Trace:
> java.lang.AssertionError: expected:<16> but was:<15>
> at
> __randomizedtesting.SeedInfo.seed([DB6DC28D5560B1D2:E295833E1541FDB9]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:677
> )
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> Digging into the logs, the problem appears to be in the way the test
> verifies/assumes docs have been committed.
--
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] tballison opened a new pull request #1092: SOLR-14054 -- upgrade to Tika 1.23 (and its dependencies)
tballison opened a new pull request #1092: SOLR-14054 -- upgrade to Tika 1.23 (and its dependencies) URL: https://github.com/apache/lucene-solr/pull/1092 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=16998564#comment-16998564 ] ASF subversion and git services commented on SOLR-14054: Commit 5887b27ecc6e2ebb24e2a7b660e488155aebdcfa in lucene-solr's branch refs/heads/jira/SOLR-14054 from Tim Allison [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5887b27 ] SOLR-14054 -- upgrade to Tika 1.23 (and its dependencies) > 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 > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 10m > 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-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=16998568#comment-16998568
]
Mike Drob commented on SOLR-13190:
--
You have great timing, [~andywebb1975]! The PR as written won't solve it.
You'll get a better exception message that tells you what the term is (which
you currently don't get), which will help you in post analysis of error logs,
but won't make much difference in the moment. I spun things out to LUCENE-9098
this morning for that change, since it required more lucene change than solr
change.
I have plans to improve things so that we can run the long queries as well, but
I wanted to get the quicker logging change in first.
> 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: 10m
> 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-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=16998569#comment-16998569 ] Kevin Risden commented on SOLR-14103: - So need to make sure these tests are run on basically any non Windows OS and nightly=true. Otherwise the Hadoop code won't get executed. I'll try to run the tests from gradle-master and report back. > 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-14105) SSL not working in branch_8x
[
https://issues.apache.org/jira/browse/SOLR-14105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998571#comment-16998571
]
Kevin Risden commented on SOLR-14105:
-
Linking to SOLR-14026 since presumably caused by that upgrade. I can try to
help take a look.
> 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
>Priority: Major
> Fix For: 8.5
>
>
> 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] [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=16998572#comment-16998572
]
Kevin Risden commented on SOLR-14106:
-
FYI might be caused by SOLR-13541 which is a Jetty upgrade in 8.2.0.
> 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)
>Affects Versions: 8.2, 8.3.1
>Reporter: Jan Høydahl
>Priority: Major
>
> 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998574#comment-16998574 ] ASF subversion and git services commented on SOLR-14054: Commit a58269f6a60a4c5b8eda07d23c51810d34aa1da2 in lucene-solr's branch refs/heads/branch_8x from Tim Allison [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a58269f ] SOLR-14054: Upgrade to Tika 1.23 > 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 > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 10m > 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=16998576#comment-16998576
]
Ishan Chattopadhyaya commented on SOLR-14106:
-
Shall we mark this as a 8.4 blocker, downgrade Jetty and request [~jpountz] for
a re-spin?
> 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)
>Affects Versions: 8.2, 8.3.1
>Reporter: Jan Høydahl
>Priority: Major
>
> 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
[GitHub] [lucene-solr] tballison merged pull request #1092: SOLR-14054 -- upgrade to Tika 1.23 (and its dependencies)
tballison merged pull request #1092: SOLR-14054 -- upgrade to Tika 1.23 (and its dependencies) URL: https://github.com/apache/lucene-solr/pull/1092 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=16998581#comment-16998581 ] ASF subversion and git services commented on SOLR-14054: Commit 279a391cf3b38354f94e721297b8bc6563b8c4ce in lucene-solr's branch refs/heads/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 > 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=16998580#comment-16998580 ] ASF subversion and git services commented on SOLR-14054: Commit 279a391cf3b38354f94e721297b8bc6563b8c4ce in lucene-solr's branch refs/heads/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 > 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=16998583#comment-16998583 ] Tim Allison commented on SOLR-14054: Let me know if I botched anything. I _think_ we're good to go. > 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 > 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Allison resolved SOLR-14054. Fix Version/s: 8.5 Resolution: Fixed Please reopen if I've broken anything. > 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-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=16998585#comment-16998585 ] Kevin Risden commented on SOLR-14103: - Hmmm I ran the HDFS specifics tests on Mac from the latest gradle-master and heck idk why that dependency doesn't need to be there anymore. Everything looks fine to me. > 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-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=16998589#comment-16998589
]
Kevin Risden commented on SOLR-14106:
-
I have no idea if its safe to roll back the Jetty change. There are a lot of
JDK 11+ fixes in Jetty lately.
https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.16.v20190411
introduced the Client/Server difference that might be causing SOLR-14106 as
well.
The specific change and details are here:
https://github.com/eclipse/jetty.project/issues/3464
It would be better to actually fix the issue than try to just revert with a
bunch of things linked off of SOLR-13541.
> 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)
>Affects Versions: 8.2, 8.3.1
>Reporter: Jan Høydahl
>Priority: Major
>
> 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-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=16998595#comment-16998595
]
Kevin Risden commented on SOLR-14106:
-
For client auth, most likely looks like running into
https://github.com/eclipse/jetty.project/issues/3554 where using the .Server()
option is more correct anyway. I'll see what is necessary to make this change.
> 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)
>Affects Versions: 8.2, 8.3.1
>Reporter: Jan Høydahl
>Priority: Major
>
> 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-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=16998597#comment-16998597
]
Kevin Risden commented on SOLR-14106:
-
>From
>https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/config/etc/jetty-ssl-context.xml#L10
Looks like we want to set
https://github.com/apache/lucene-solr/blob/master/solr/server/etc/jetty-ssl.xml#L9:
to
{code:java}
{code}
> 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)
>Affects Versions: 8.2, 8.3.1
>Reporter: Jan Høydahl
>Priority: Major
>
> 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
[GitHub] [lucene-solr] madrob commented on issue #1091: LUCENE-9098 Report bad term for fuzzy query
madrob commented on issue #1091: LUCENE-9098 Report bad term for fuzzy query URL: https://github.com/apache/lucene-solr/pull/1091#issuecomment-566755397 @atris sure - I split the single commit into two commits, one for LUCENE and one for SOLR. 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
[GitHub] [lucene-solr] madrob closed pull request #554: SOLR-13190 Treat fuzzy term search errors as client errors
madrob closed pull request #554: SOLR-13190 Treat fuzzy term search errors as client errors URL: https://github.com/apache/lucene-solr/pull/554 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-14105) SSL not working in branch_8x
[
https://issues.apache.org/jira/browse/SOLR-14105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998600#comment-16998600
]
Kevin Risden commented on SOLR-14105:
-
SOLR-14106 may fix part of this. From the stack trace I don't think it will fix
all of it.
> 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
>Priority: Major
> Fix For: 8.5
>
>
> 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] [Commented] (LUCENE-8037) API report for Lucene Core snapshot
[ https://issues.apache.org/jira/browse/LUCENE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998601#comment-16998601 ] Michael Sokolov commented on LUCENE-8037: - Thanks for the report [~aponomarenko] - I'm resolving the issue since there's no action to be taken here; feel free to re-open and comment if you think there is something remaining to do. > API report for Lucene Core snapshot > --- > > Key: LUCENE-8037 > URL: https://issues.apache.org/jira/browse/LUCENE-8037 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Andrey Ponomarenko >Priority: Trivial > Attachments: lucene-core-1.png, lucene-core-2.png > > > Hi, > I'd like to share report on API changes and backward compatibility for the > latest snapshot of the Lucene Core library (updated daily): > https://abi-laboratory.pro/java/tracker/timeline/lucene-core/ > BC — binary compatibility > SC — source compatibility > The report is generated according to the article > https://wiki.eclipse.org/Evolving_Java-based_APIs_2 by the > https://github.com/lvc/japi-tracker tool for jars from > https://repository.apache.org/content/repositories/snapshots/org/apache/lucene/lucene-core/ > and http://central.maven.org/maven2/org/apache/lucene/lucene-core/. > Hope it will be helpful for users and maintainers of the library. > Feel free to request more modules of the library to be included to the > tracker if you are interested. > Thank you. > !lucene-core-2.png|API symbols timeline! > !lucene-core-1.png|API changes review! -- 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-8037) API report for Lucene Core snapshot
[ https://issues.apache.org/jira/browse/LUCENE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-8037. - Resolution: Fixed > API report for Lucene Core snapshot > --- > > Key: LUCENE-8037 > URL: https://issues.apache.org/jira/browse/LUCENE-8037 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Andrey Ponomarenko >Priority: Trivial > Attachments: lucene-core-1.png, lucene-core-2.png > > > Hi, > I'd like to share report on API changes and backward compatibility for the > latest snapshot of the Lucene Core library (updated daily): > https://abi-laboratory.pro/java/tracker/timeline/lucene-core/ > BC — binary compatibility > SC — source compatibility > The report is generated according to the article > https://wiki.eclipse.org/Evolving_Java-based_APIs_2 by the > https://github.com/lvc/japi-tracker tool for jars from > https://repository.apache.org/content/repositories/snapshots/org/apache/lucene/lucene-core/ > and http://central.maven.org/maven2/org/apache/lucene/lucene-core/. > Hope it will be helpful for users and maintainers of the library. > Feel free to request more modules of the library to be included to the > tracker if you are interested. > Thank you. > !lucene-core-2.png|API symbols timeline! > !lucene-core-1.png|API changes review! -- 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=16998602#comment-16998602
]
Kevin Risden commented on SOLR-14106:
-
Here are all the references to SslContextFactory:
{code:java}
git grep -F org.eclipse.jetty.util.ssl.SslContextFactory | cat
core/src/java/org/apache/solr/client/solrj/embedded/JettySolrRunner.java:import
org.eclipse.jetty.util.ssl.SslContextFactory;
core/src/test/org/apache/hadoop/http/HttpServer2.java:import
org.eclipse.jetty.util.ssl.SslContextFactory;
server/etc/jetty-ssl.xml:
solrj/src/java/org/apache/solr/client/solrj/embedded/SSLConfig.java:import
org.eclipse.jetty.util.ssl.SslContextFactory;
solrj/src/java/org/apache/solr/client/solrj/impl/Http2SolrClient.java:import
org.eclipse.jetty.util.ssl.SslContextFactory;
test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:import
org.eclipse.jetty.util.ssl.SslContextFactory;
{code}
> 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)
>Affects Versions: 8.2, 8.3.1
>Reporter: Jan Høydahl
>Priority: Major
>
> 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-7566) BooleanQuery.Builder shouldn't clone added clauses
[
https://issues.apache.org/jira/browse/LUCENE-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Sokolov resolved LUCENE-7566.
-
Resolution: Fixed
This seems to have been fixed at some point, just resolving the issue after the
fact. I now see:
{{public Builder add(BooleanClause clause) {}}
{{ // We do the final deep check for max clauses count limit during}}
{{ //IndexSearcher.rewrite but do this check to short}}
{{ // circuit in case a single query holds more than numClauses}}
{{ if (clauses.size() >= IndexSearcher.maxClauseCount) {}}
{{ throw new IndexSearcher.TooManyClauses();}}
{{ }}}
{{ clauses.add(clause);}}
{{ return this;}}
{{ }}}
> 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] [Assigned] (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 reassigned SOLR-14106:
---
Assignee: Kevin Risden
> 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)
>Affects Versions: 8.2, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
>
> 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-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=16998606#comment-16998606
]
Kevin Risden commented on SOLR-14106:
-
Most of the .Client() usage has already been fixed. Looking through the above,
there are a few .Server() missing. I'll address those with this patch. Working
on creating and patch and running a test locally.
> 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)
>Affects Versions: 8.2, 8.3.1
>Reporter: Jan Høydahl
>Priority: Major
>
> 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
[GitHub] [lucene-solr] mbwaheed commented on a change in pull request #1055: SOLR-13932 Review directory locking and Blob interactions
mbwaheed commented on a change in pull request #1055: SOLR-13932 Review
directory locking and Blob interactions
URL: https://github.com/apache/lucene-solr/pull/1055#discussion_r359042707
##
File path:
solr/core/src/java/org/apache/solr/store/blob/metadata/ServerSideMetadata.java
##
@@ -132,35 +127,15 @@ public ServerSideMetadata(String coreName, CoreContainer
container, boolean take
generation = latestCommit.getGeneration();
latestCommitFiles = latestCommitBuilder.build();
-// Capture now the hash and verify again if we need to pull content
from the Blob store into this directory,
-// to make sure there are no local changes at the same time that might
lead to a corruption in case of interaction
-// with the download.
-// TODO: revise with "design assumptions around pull pipeline"
mentioned in allCommits TODO below
+// Capture now the hash and verify again after files have been pulled
and before the directory is updated (or before
+// the index is switched to use a new directory) to make sure there
are no local changes at the same time that might
+// lead to a corruption in case of interaction with the download or
might be a sign of other problems (it is not
+// expected that indexing can happen on a local directory of a SHARED
replica if that replica is not up to date with
+// the Blob store version).
directoryHash = getSolrDirectoryHash(coreDir);
-allCommitsFiles = latestCommitFiles;
-// TODO: allCommits was added to detect special cases where inactive
file segments can potentially conflict
-// with whats in shared store. But given the recent
understanding of semantics around index directory locks
-// we need to revise our design assumptions around pull
pipeline, including this one.
-// Disabling this for now so that unreliability around
introspection of older commits
-// might not get in the way of steady state indexing.
-//// A note on listCommits says that it does not guarantee consistent
results if a commit is in progress.
-//// But in blob context we serialize commits and pulls by proper
locking therefore we should be good here.
-//List allCommits = DirectoryReader.listCommits(coreDir);
-//
-//// we should always have a commit point as verified in the beginning
of this method.
-//assert (allCommits.size() > 1) || (allCommits.size() == 1 &&
allCommits.get(0).equals(latestCommit));
-//
-//// optimization: normally we would only be dealing with one commit
point. In that case just reuse latest commit files builder.
-//ImmutableCollection.Builder allCommitsBuilder =
latestCommitBuilder;
-//if (allCommits.size() > 1) {
-// allCommitsBuilder = new ImmutableSet.Builder<>();
-// for (IndexCommit commit : allCommits) {
-//// no snapshot for inactive segments files
-//buildCommitFiles(coreDir, commit, allCommitsBuilder, /*
snapshotDir */ null);
-// }
-//}
-//allCommitsFiles = allCommitsBuilder.build();
+// Need to inventory all local files in case files that need to be
pulled from Blob conflict with them.
+allFiles = ImmutableSet.copyOf(coreDir.listAll());
Review comment:
And we don't need directory hash in push scenario, we can consider making it
optional so we don't compute it in indexing path.
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] [Resolved] (LUCENE-1909) Make IndexReader.DEFAULT_TERMS_INDEX_DIVISOR public
[ https://issues.apache.org/jira/browse/LUCENE-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-1909. - Resolution: Fixed I think we can resolve now, given that this constant no longer exists > Make IndexReader.DEFAULT_TERMS_INDEX_DIVISOR public > --- > > Key: LUCENE-1909 > URL: https://issues.apache.org/jira/browse/LUCENE-1909 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Grant Ingersoll >Priority: Trivial > Fix For: 6.0, 4.9 > > Attachments: LUCENE_1909.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] [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=16998608#comment-16998608 ] Michael Sokolov commented on LUCENE-6678: - [~dweiss] can we resolve now that JDK 14 is coming, and JDK 9 was never LTS anyway? > 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-5997) StandardFilter redundant
[
https://issues.apache.org/jira/browse/LUCENE-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Sokolov resolved LUCENE-5997.
-
Resolution: Fixed
I'm not sure when, but StandardFilter was removed and no longer exists, so this
issue won
> StandardFilter redundant
>
>
> Key: LUCENE-5997
> URL: https://issues.apache.org/jira/browse/LUCENE-5997
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 4.10.1
>Reporter: Itamar Syn-Hershko
>Priority: Trivial
>
> Any reason why StandardFilter is still around? its just a no-op class now:
> @Override
> public final boolean incrementToken() throws IOException {
> return input.incrementToken(); // TODO: add some niceties for the new
> grammar
> }
> https://github.com/apache/lucene-solr/blob/trunk/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/StandardFilter.java
--
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-5839) Regex bug in AnalyzingQueryParser
[
https://issues.apache.org/jira/browse/LUCENE-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Sokolov resolved LUCENE-5839.
-
Resolution: Fixed
AnalyzingQueryParser no longer exists. I also grepped for `wildcardPattern`
just to make sure this usage didn't persist in some other class and couldn't
find it: I think it's safe to close this now
> Regex bug in AnalyzingQueryParser
> -
>
> Key: LUCENE-5839
> URL: https://issues.apache.org/jira/browse/LUCENE-5839
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/queryparser
>Affects Versions: 4.9
>Reporter: Tim Allison
>Priority: Trivial
>
> Dennis Walter recently pointed out this bug on d...@lucene.apache.org:
> " // gobble escaped chars or find a wildcard character
> private final Pattern wildcardPattern = Pattern.compile("(\\.)|([?*]+)");
> The first group will match a literal dot ("."), while its intention seems to
> be to match a backslash and a single character. So the expression should
> instead be "(.)|([?*]+)" "
--
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=16998617#comment-16998617
]
Jan Høydahl commented on SOLR-14106:
Thanks for digging Kevin.
So I checked out branch_8_4 and reverted just that one commit from SOLR-13541
([https://github.com/apache/lucene-solr/commit/22fca67bfe3b35c1c6818ed0fcce08086db987c9)]
and guess what, SSL client auth now started working again...
Looks like the move to .Server and .Client was not fully completed...
> 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)
>Affects Versions: 8.2, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
>
> 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-5198) Strengthen the function of Min should match, making it select BooleanClause as Occur.MUST according to the weight of query
[ https://issues.apache.org/jira/browse/LUCENE-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-5198. - Resolution: Fixed Resolving this very forward-looking issue that seems to have been an early plea for something like "WAND" > Strengthen the function of Min should match, making it select BooleanClause > as Occur.MUST according to the weight of query > -- > > Key: LUCENE-5198 > URL: https://issues.apache.org/jira/browse/LUCENE-5198 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Affects Versions: 4.4 >Reporter: HeXin >Priority: Trivial > > In current version, when we using BooleanQuery do disjunction, the top scorer > will select the doc which meet > at least mm numbers of sub scorers. > But in some case, we wish that the weight of sub scorers larger than the > threshold can be selected > as Occur.MUST automatically. The threshold can be configurable, equaling the > minimum integer by default. > Any comments is welcomed. -- 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=16998621#comment-16998621
]
Shawn Heisey commented on SOLR-14103:
-
{quote}jersey-core, jersey-server and netty-all also seem to be redundant.
{quote}
I don't know anything about the jersey dependencies, but netty is required to
do SSL with ZooKeeper. A smaller subset of dependencies than netty-all MIGHT
be workable, that would have to be explored.
> 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=16998625#comment-16998625
]
ASF subversion and git services commented on SOLR-14099:
Commit cc4262a8ec37b2420e1d80a392c5e8019f43e24c in lucene-solr's branch
refs/heads/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
> 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-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=16998624#comment-16998624
]
Jan Høydahl commented on SOLR-14106:
Whether it should be a 8.4 blocker is another question. Given that 8.2.0 has
been out since end of July there are likely not too many other serious issues.
We can always do a quick 8.4.1.
> 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)
>Affects Versions: 8.2, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
>
> 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-1207) Allow spell check input to be part of the results
[ https://issues.apache.org/jira/browse/LUCENE-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-1207. - Resolution: Fixed Resolving since the last activity on this issue was a note from six years ago stating that this issue had been inactive for three years. > Allow spell check input to be part of the results > - > > Key: LUCENE-1207 > URL: https://issues.apache.org/jira/browse/LUCENE-1207 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/other >Reporter: Karl Wettin >Priority: Trivial > Attachments: canSuggestSelf.patch > > > As a threadshold marker, to see if the word seems to exist at all, or what > not. -- 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-4679) LowercaseExpandedTermsQueryNodeProcessor changes regex queries
[ https://issues.apache.org/jira/browse/LUCENE-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-4679. - Resolution: Fixed resolving this issue that appears to have been overtaken by events and refers to a class that no longer exists in the flexible queryparser > LowercaseExpandedTermsQueryNodeProcessor changes regex queries > -- > > Key: LUCENE-4679 > URL: https://issues.apache.org/jira/browse/LUCENE-4679 > Project: Lucene - Core > Issue Type: Wish >Reporter: Roman Chyla >Priority: Trivial > Attachments: LUCENE-4679.patch > > > This is really a very silly request, but could the lowercase processor > 'abstain' from changing regex queries? For example, W should stay > uppercase, but it is lowercased. -- 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-8240) Make TokenStreamComponents.setReader public
[ https://issues.apache.org/jira/browse/LUCENE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-8240. - Resolution: Won't Fix Analyzer.TokenStreamComponents actually became private instead (in Lucene 8)! However TokenStreamComponents now accepts a callback (functional object) that enables the desired usage, so we can close this issue. > Make TokenStreamComponents.setReader public > --- > > Key: LUCENE-8240 > URL: https://issues.apache.org/jira/browse/LUCENE-8240 > Project: Lucene - Core > Issue Type: Wish > Components: modules/analysis >Reporter: Michael Sokolov >Priority: Major > Attachments: SubFieldAnalyzer.java > > > The simplest change for this would be to make > TokenStreamComponents.setReader() public. Another alternative would be to > provide a SubFieldAnalyzer along the lines of what is attached, although for > reasons given below I think this implementation is a little hacky and would > ideally be supported in a different way before making *that* part of a public > Lucene API. > Exposing this method would allow a third-party extension to access it in > order to wrap TokenStreamComponents. My use case is a SubFieldAnalyzer > (attached, for reference) that applies different analysis to different > instances of a field. This supports a big "catch-all" field that has > different (index-time) text processing. The way we implement that is by > creating a TokenStreamComponents that wraps separate per-subfield components > and switches among them when setReader() is called. > Why setReader()? This is the only part of the API where we can inject this > notion of subfields. setReader() is called with a Reader for each field > instance, and we supply a special Reader that identifies its subfield. > This is a bit hacky – ideally subfields would be first-class citizens in the > Analyzer API, so eg there would be methods like > Analyzer.createComponents(String fieldName, String subFieldName), etc. > However this seems like a pretty big change for an experimental feature, so > it seems like an OK tradeoff to live with the Reader-per-subfield hack for > now. > Currently SubFieldAnalyzer has to live in org.apache.lucene.analysis package > in order to call TokenStreamComponents.setReader (on a separate instance) and > propitiate java's code-hiding rules, which is awkward. -- 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=16998633#comment-16998633
]
ASF subversion and git services commented on SOLR-14099:
Commit d1fa6e1e023cae780bb0eeffe81fefb9c5e2b129 in lucene-solr's branch
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d1fa6e1 ]
SOLR-14099: Fixed @LogLevel annotation in test-framework to correctly 'unset'
Loggers after test
(cherry picked from commit cc4262a8ec37b2420e1d80a392c5e8019f43e24c)
> @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
> 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
