[jira] [Commented] (SOLR-14066) Deprecate DIH
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999820#comment-16999820 ] Ishan Chattopadhyaya commented on SOLR-14066: - Thanks a lot, Rohit. Please create a public repo somewhere, and we can collaborate there to bring DIH there under your maintainership. > Deprecate DIH > - > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 40m > Remaining Estimate: 0h > > DataImportHandler has outlived its utility. DIH doesn't need to remain inside > Solr anymore. Let us deprecate DIH in 8.4 (and remove it from the Solr distro > in 9x or 10x). -- 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 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: Resolution: Fixed Status: Resolved (was: Patch Available) > Remove BlockJoinFacetComponent in 9.0 > --- > > Key: SOLR-14051 > URL: https://issues.apache.org/jira/browse/SOLR-14051 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-14051.patch > > > Please migrate to SOLR-8998 and SOLR-9510 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14108) Package Manager: verify command should be optional
[ https://issues.apache.org/jira/browse/SOLR-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999755#comment-16999755 ] Ishan Chattopadhyaya commented on SOLR-14108: - Fixed a clumsy cherry-pick. > Package Manager: verify command should be optional > -- > > Key: SOLR-14108 > URL: https://issues.apache.org/jira/browse/SOLR-14108 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.4 > > > The command to verify a package after deployment should be made optional. It > was originally intended to be that way, but got missed out in the > implementation. > The workaround for now is to have a condition in the verify command that > always evaluates to true :-( -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14108) Package Manager: verify command should be optional
[ https://issues.apache.org/jira/browse/SOLR-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999753#comment-16999753 ] ASF subversion and git services commented on SOLR-14108: Commit 35cb6a020304e9c53543c6d25897a769d7dba109 in lucene-solr's branch refs/heads/branch_8x from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=35cb6a0 ] SOLR-14108: Fix cherry-pick problem with last commit > Package Manager: verify command should be optional > -- > > Key: SOLR-14108 > URL: https://issues.apache.org/jira/browse/SOLR-14108 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.4 > > > The command to verify a package after deployment should be made optional. It > was originally intended to be that way, but got missed out in the > implementation. > The workaround for now is to have a condition in the verify command that > always evaluates to true :-( -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14108) Package Manager: verify command should be optional
[ https://issues.apache.org/jira/browse/SOLR-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999754#comment-16999754 ] ASF subversion and git services commented on SOLR-14108: Commit 75983fa2acfddd3cc1fe0cafeb1e2b08129fdce0 in lucene-solr's branch refs/heads/branch_8_4 from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=75983fa ] SOLR-14108: Fix cherry-pick problem with last commit > Package Manager: verify command should be optional > -- > > Key: SOLR-14108 > URL: https://issues.apache.org/jira/browse/SOLR-14108 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.4 > > > The command to verify a package after deployment should be made optional. It > was originally intended to be that way, but got missed out in the > implementation. > The workaround for now is to have a condition in the verify command that > always evaluates to true :-( -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14108) Package Manager: verify command should be optional
[ https://issues.apache.org/jira/browse/SOLR-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999750#comment-16999750 ] Ishan Chattopadhyaya commented on SOLR-14108: - Thanks [~ehatcher]! > Package Manager: verify command should be optional > -- > > Key: SOLR-14108 > URL: https://issues.apache.org/jira/browse/SOLR-14108 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.4 > > > The command to verify a package after deployment should be made optional. It > was originally intended to be that way, but got missed out in the > implementation. > The workaround for now is to have a condition in the verify command that > always evaluates to true :-( -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14108) Package Manager: verify command should be optional
[ https://issues.apache.org/jira/browse/SOLR-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya resolved SOLR-14108. - Fix Version/s: 8.4 Resolution: Fixed All it needed was two null checks, so pushed it in without a review. I verified this manually. > Package Manager: verify command should be optional > -- > > Key: SOLR-14108 > URL: https://issues.apache.org/jira/browse/SOLR-14108 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.4 > > > The command to verify a package after deployment should be made optional. It > was originally intended to be that way, but got missed out in the > implementation. > The workaround for now is to have a condition in the verify command that > always evaluates to true :-( -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14108) Package Manager: verify command should be optional
[ https://issues.apache.org/jira/browse/SOLR-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999747#comment-16999747 ] ASF subversion and git services commented on SOLR-14108: Commit bb1b3ea223f0557f93e0fd7e3ebcc843033f1798 in lucene-solr's branch refs/heads/branch_8_4 from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bb1b3ea ] SOLR-14108: Handle missing verify commands or missing default params in Package Manager > Package Manager: verify command should be optional > -- > > Key: SOLR-14108 > URL: https://issues.apache.org/jira/browse/SOLR-14108 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > The command to verify a package after deployment should be made optional. It > was originally intended to be that way, but got missed out in the > implementation. > The workaround for now is to have a condition in the verify command that > always evaluates to true :-( -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14108) Package Manager: verify command should be optional
[ https://issues.apache.org/jira/browse/SOLR-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999746#comment-16999746 ] ASF subversion and git services commented on SOLR-14108: Commit 3a4f43227b4471ffc89c3c6c64e2f2562ebb7cb7 in lucene-solr's branch refs/heads/branch_8x from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3a4f432 ] SOLR-14108: Handle missing verify commands or missing default params in Package Manager > Package Manager: verify command should be optional > -- > > Key: SOLR-14108 > URL: https://issues.apache.org/jira/browse/SOLR-14108 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > The command to verify a package after deployment should be made optional. It > was originally intended to be that way, but got missed out in the > implementation. > The workaround for now is to have a condition in the verify command that > always evaluates to true :-( -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13985) bind to localhost by default
[
https://issues.apache.org/jira/browse/SOLR-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999735#comment-16999735
]
Robert Muir commented on SOLR-13985:
{noformat}
+IF NOT DEFINED SOLR_JETTY_HOST (
+ set "SOLR_OPTS=%SOLR_OPTS% -Dsolr.jetty.host=%SOLR_JETTY_HOST%"
+)
{noformat}
This looks backwards to me, should it be instead {{IF DEFINED}}? Sorry, I don't
know windows, but it seems backwards from {{test -n}}. I can test the patch on
a windows VM if needed.
> bind to localhost by default
>
>
> Key: SOLR-13985
> URL: https://issues.apache.org/jira/browse/SOLR-13985
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Robert Muir
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13985.patch, SOLR-13985.patch, SOLR-13985.patch
>
>
> Currently solr binds to all interfaces by default.
> The default should be safer, so that e.g. the user is not exposed to the
> internet until they make an explicit step to do so.
--
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-13960) Reproducible failure in HdfsBasicDistributedZk2Test
[
https://issues.apache.org/jira/browse/SOLR-13960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999728#comment-16999728
]
Kevin Risden commented on SOLR-13960:
-
So I looked at this a bit more. My gut says this is just a seed creating a ton
of documents and causing GC/slowness. It just looks like it goes so
slowwly:
Eventually
{code:java}
Caused by: java.net.SocketTimeoutException: Read timed out
{code}
So I'm guessing long GC. I'll have to hook up a debugger and check what the
seed is doing for the random values in the test.
> Reproducible failure in HdfsBasicDistributedZk2Test
>
>
> Key: SOLR-13960
> URL: https://issues.apache.org/jira/browse/SOLR-13960
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Hadoop Integration, hdfs
>Reporter: Erick Erickson
>Assignee: Kevin Risden
>Priority: Major
>
> This reproduces for me very consistently on a fresh checkout of master.
> {code:java}
> ant test -Dtestcase=HdfsBasicDistributedZk2Test -Dtests.method=test
> -Dtests.seed=67263E0CD3327A11 -Dtests.nightly=true -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=sr -Dtests.timezone=America/St_Lucia
> -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {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] (SOLR-14085) remove solr fork of lucene test securitymanager
[ https://issues.apache.org/jira/browse/SOLR-14085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved SOLR-14085. Fix Version/s: 8.5 Assignee: Robert Muir Resolution: Fixed > remove solr fork of lucene test securitymanager > --- > > Key: SOLR-14085 > URL: https://issues.apache.org/jira/browse/SOLR-14085 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Major > Fix For: 8.5 > > Attachments: SOLR-14085.patch > > > I forked it to better contain some hadoop hacks: but now those hacks are > removed and it is just duplicate code: let's nuke it. -- 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-14085) remove solr fork of lucene test securitymanager
[ https://issues.apache.org/jira/browse/SOLR-14085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999726#comment-16999726 ] ASF subversion and git services commented on SOLR-14085: Commit 04e306f616bb191c67ee4e241ce7c3bb68477a97 in lucene-solr's branch refs/heads/branch_8x from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=04e306f ] SOLR-14085: remove solr fork of lucene test securitymanager > remove solr fork of lucene test securitymanager > --- > > Key: SOLR-14085 > URL: https://issues.apache.org/jira/browse/SOLR-14085 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14085.patch > > > I forked it to better contain some hadoop hacks: but now those hacks are > removed and it is just duplicate code: let's nuke it. -- 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-13960) Reproducible failure in HdfsBasicDistributedZk2Test
[
https://issues.apache.org/jira/browse/SOLR-13960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-13960:
Description:
This reproduces for me very consistently on a fresh checkout of master.
{code:java}
ant test -Dtestcase=HdfsBasicDistributedZk2Test -Dtests.method=test
-Dtests.seed=67263E0CD3327A11 -Dtests.nightly=true -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=sr -Dtests.timezone=America/St_Lucia
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
{code}
was:
This reproduces for me very consistently on a fresh checkout of master.
ant test -Dtestcase=HdfsBasicDistributedZk2Test -Dtests.method=test
-Dtests.seed=67263E0CD3327A11 -Dtests.nightly=true -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=sr -Dtests.timezone=America/St_Lucia
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> Reproducible failure in HdfsBasicDistributedZk2Test
>
>
> Key: SOLR-13960
> URL: https://issues.apache.org/jira/browse/SOLR-13960
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Hadoop Integration, hdfs
>Reporter: Erick Erickson
>Assignee: Kevin Risden
>Priority: Major
>
> This reproduces for me very consistently on a fresh checkout of master.
> {code:java}
> ant test -Dtestcase=HdfsBasicDistributedZk2Test -Dtests.method=test
> -Dtests.seed=67263E0CD3327A11 -Dtests.nightly=true -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=sr -Dtests.timezone=America/St_Lucia
> -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {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] [Updated] (SOLR-13960) Reproducible failure in HdfsBasicDistributedZk2Test
[ https://issues.apache.org/jira/browse/SOLR-13960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13960: Description: This reproduces for me very consistently on a fresh checkout of master. ant test -Dtestcase=HdfsBasicDistributedZk2Test -Dtests.method=test -Dtests.seed=67263E0CD3327A11 -Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sr -Dtests.timezone=America/St_Lucia -Dtests.asserts=true -Dtests.file.encoding=US-ASCII was: This reproduces for me very consistently on a fresh checkout of master. ant test-nocompile -Dtestcase=HdfsBasicDistributedZk2Test -Dtests.method=test -Dtests.seed=67263E0CD3327A11 -Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sr -Dtests.timezone=America/St_Lucia -Dtests.asserts=true -Dtests.file.encoding=US-ASCII > Reproducible failure in HdfsBasicDistributedZk2Test > > > Key: SOLR-13960 > URL: https://issues.apache.org/jira/browse/SOLR-13960 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Hadoop Integration, hdfs >Reporter: Erick Erickson >Assignee: Kevin Risden >Priority: Major > > This reproduces for me very consistently on a fresh checkout of master. > ant test -Dtestcase=HdfsBasicDistributedZk2Test -Dtests.method=test > -Dtests.seed=67263E0CD3327A11 -Dtests.nightly=true -Dtests.slow=true > -Dtests.badapples=true -Dtests.locale=sr -Dtests.timezone=America/St_Lucia > -Dtests.asserts=true -Dtests.file.encoding=US-ASCII -- 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-14085) remove solr fork of lucene test securitymanager
[ https://issues.apache.org/jira/browse/SOLR-14085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999725#comment-16999725 ] ASF subversion and git services commented on SOLR-14085: Commit 7490bfd8287960c3e433d2063a3322d6deaf4ef6 in lucene-solr's branch refs/heads/master from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7490bfd ] SOLR-14085: remove solr fork of lucene test securitymanager > remove solr fork of lucene test securitymanager > --- > > Key: SOLR-14085 > URL: https://issues.apache.org/jira/browse/SOLR-14085 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14085.patch > > > I forked it to better contain some hadoop hacks: but now those hacks are > removed and it is just duplicate code: let's nuke it. -- 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-14118) default embedded zookeeper port to localhost
Robert Muir created SOLR-14118:
--
Summary: default embedded zookeeper port to localhost
Key: SOLR-14118
URL: https://issues.apache.org/jira/browse/SOLR-14118
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Robert Muir
Relates: SOLR-13985
If someone runs {{bin/solr start -c}}:
{noformat}
tcp46 0 0 *.8983 *.*LISTEN
tcp46 0 0 *.9983 *.*LISTEN
{noformat}
In addition to the jetty port, the embedded zookeeper port should not bind to
all interfaces. Nothing should 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-14085) remove solr fork of lucene test securitymanager
[ https://issues.apache.org/jira/browse/SOLR-14085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999717#comment-16999717 ] Kevin Risden commented on SOLR-14085: - +1 looks good to me. > remove solr fork of lucene test securitymanager > --- > > Key: SOLR-14085 > URL: https://issues.apache.org/jira/browse/SOLR-14085 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14085.patch > > > I forked it to better contain some hadoop hacks: but now those hacks are > removed and it is just duplicate code: let's nuke it. -- 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-13985) bind to localhost by default
[ https://issues.apache.org/jira/browse/SOLR-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999715#comment-16999715 ] Robert Muir commented on SOLR-13985: +1 for keeping it simple and well-documented for 9.0. I like the patch here. It is good for this kind of change to be in a major release. With regards to the documentation, I think its good to echo it (maybe via link as Jan suggests) in multiple places in the documentation so that its 100% clear, easily seen, and doesn't present roadblocks to people. > bind to localhost by default > > > Key: SOLR-13985 > URL: https://issues.apache.org/jira/browse/SOLR-13985 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Assignee: Jason Gerlowski >Priority: Major > Attachments: SOLR-13985.patch, SOLR-13985.patch, SOLR-13985.patch > > > Currently solr binds to all interfaces by default. > The default should be safer, so that e.g. the user is not exposed to the > internet until they make an explicit step to do so. -- 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] risdenk opened a new pull request #1102: SOLR-9039: Enable clientAuth on OSX
risdenk opened a new pull request #1102: SOLR-9039: Enable clientAuth on OSX URL: https://github.com/apache/lucene-solr/pull/1102 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-14085) remove solr fork of lucene test securitymanager
[ https://issues.apache.org/jira/browse/SOLR-14085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999698#comment-16999698 ] Robert Muir commented on SOLR-14085: Thanks for checking it. I think we should be aggressive about minimizing the amount of java security-related code in Solr at this time. > remove solr fork of lucene test securitymanager > --- > > Key: SOLR-14085 > URL: https://issues.apache.org/jira/browse/SOLR-14085 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14085.patch > > > I forked it to better contain some hadoop hacks: but now those hacks are > removed and it is just duplicate code: let's nuke it. -- 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-14117) remove java serialization from AnalyticsShardResponseParser.java
Robert Muir created SOLR-14117: -- Summary: remove java serialization from AnalyticsShardResponseParser.java Key: SOLR-14117 URL: https://issues.apache.org/jira/browse/SOLR-14117 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Robert Muir This is the only place in solr serializing/deserializing exceptions this way. Can we avoid using java serialization here for exceptions, too? It is dangerous. -- 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-14085) remove solr fork of lucene test securitymanager
[ https://issues.apache.org/jira/browse/SOLR-14085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999687#comment-16999687 ] Kevin Risden commented on SOLR-14085: - Well this fell off my radar. Running tests now. Will report back. > remove solr fork of lucene test securitymanager > --- > > Key: SOLR-14085 > URL: https://issues.apache.org/jira/browse/SOLR-14085 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14085.patch > > > I forked it to better contain some hadoop hacks: but now those hacks are > removed and it is just duplicate code: let's nuke it. -- 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-9100) JapaneseTokenizer produces inconsistent tokens
[
https://issues.apache.org/jira/browse/LUCENE-9100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999688#comment-16999688
]
Kazuaki Hiraga commented on LUCENE-9100:
{quote}not we use our own dictionary and connection costs{quote}
If you don't use custom dictionary, why you don't use standard/simple
constructor, which you have commented out from your code?
{code:java}
Tokenizer tokenizer = new JapaneseTokenizer(newAttributeFactory(), null, true,
JapaneseTokenizer.Mode.SEARCH);
{code}
It seems I cannot reproduce your symptom with standard one, which uses the
above code.
> JapaneseTokenizer produces inconsistent tokens
> --
>
> Key: LUCENE-9100
> URL: https://issues.apache.org/jira/browse/LUCENE-9100
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Affects Versions: 7.2
>Reporter: Elbek Kamoliddinov
>Priority: Major
>
> We use {{JapaneseTokenizer}} on prod and seeing some inconsistent behavior.
> With this text:
> {{"マギアリス【単版話】 4話 (Unlimited Comics)"}} I get different results if I insert
> space before `【` char. Here is the small code snippet demonstrating the case
> (not we use our own dictionary and connection costs):
> {code:java}
> Analyzer analyzer = new Analyzer() {
> @Override
> protected TokenStreamComponents createComponents(String
> fieldName) {
> //Tokenizer tokenizer = new
> JapaneseTokenizer(newAttributeFactory(), null, true,
> JapaneseTokenizer.Mode.SEARCH);
> Tokenizer tokenizer = new
> JapaneseTokenizer(newAttributeFactory(), dictionaries.systemDictionary,
> dictionaries.unknownDictionary, dictionaries.connectionCosts, null, true,
> JapaneseTokenizer.Mode.SEARCH);
> return new TokenStreamComponents(tokenizer, new
> LowerCaseFilter(tokenizer));
> }
> };
> String text1 = "マギアリス【単版話】 4話 (Unlimited Comics)";
> String text2 = "マギアリス 【単版話】 4話 (Unlimited Comics)"; //inserted space
> try (TokenStream tokens = analyzer.tokenStream("field", new
> StringReader(text1))) {
> CharTermAttribute chars =
> tokens.addAttribute(CharTermAttribute.class);
> tokens.reset();
> while (tokens.incrementToken()) {
> System.out.println(chars.toString());
> }
> tokens.end();
> } catch (IOException e) {
> // should never happen with a StringReader
> throw new RuntimeException(e);
> } {code}
> Output is:
> {code:java}
> //text1
> マギ
> アリス
> 単
> 版
> 話
> 4
> 話
> unlimited
> comics
> //text2
> マギア
> リス
> 単
> 版
> 話
> 4
> 話
> unlimited
> comics{code}
> It looks like tokenizer doesn't view the punctuation (\{{【}} is
> \{{Character.START_PUNCTUATION}} type) as an indicator that there should be a
> token break, and somehow 【 punctuation char causes difference in the output.
> If I use the {{JapaneseTokenizer}} tokenizer then this problem doesn't
> manifest because it doesn't tokenize {{マギアリス}} into multiple tokens and
> outputs as is.
--
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] risdenk opened a new pull request #1101: SOLR-9093: Enable clientAuth on OSX
risdenk opened a new pull request #1101: SOLR-9093: Enable clientAuth on OSX URL: https://github.com/apache/lucene-solr/pull/1101 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-9039) Get to the bottom of why clientAuth (SSL certificate) testing on OSX doesn't work
[ https://issues.apache.org/jira/browse/SOLR-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999668#comment-16999668 ] Kevin Risden commented on SOLR-9039: Hm I looked at this again tonight and I'm 90% sure this works on master on a Mac on adoptopenjdk 11.0.5. I'll try it again and run through all the tests. > Get to the bottom of why clientAuth (SSL certificate) testing on OSX doesn't > work > - > > Key: SOLR-9039 > URL: https://issues.apache.org/jira/browse/SOLR-9039 > Project: Solr > Issue Type: Bug >Reporter: Chris M. Hostetter >Priority: Major > > When randomized SSL/clientAuth testing was introduced in SOLR-3854 it was > quickly determined that something about OSX didn't play nicely with the way > we were testing clientAuth certificates... > https://issues.apache.org/jira/browse/SOLR-3854?focusedCommentId=13897983#comment-13897983 > https://svn.apache.org/r1567643 > At the time no additional investigation into the root problem was attempted. > As part of SOLR-9028, I spent a little time trying to verify if this was > still a problem, and determined it was. I briefly attempted to get to the > bottom of it, and compiled a few notes on things to look into -- but > ultimately i don't have the time/resources to do any serious test on OSX > myself, and i didn't want this to block SOLR-9028 so i'm spinning it out into > it's own issue. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-9039) Get to the bottom of why clientAuth (SSL certificate) testing on OSX doesn't work
[ https://issues.apache.org/jira/browse/SOLR-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9039: --- Comment: was deleted (was: FWIW this still fails if I comment out the assume on Mac so its not just magically fixed. ) > Get to the bottom of why clientAuth (SSL certificate) testing on OSX doesn't > work > - > > Key: SOLR-9039 > URL: https://issues.apache.org/jira/browse/SOLR-9039 > Project: Solr > Issue Type: Bug >Reporter: Chris M. Hostetter >Priority: Major > > When randomized SSL/clientAuth testing was introduced in SOLR-3854 it was > quickly determined that something about OSX didn't play nicely with the way > we were testing clientAuth certificates... > https://issues.apache.org/jira/browse/SOLR-3854?focusedCommentId=13897983#comment-13897983 > https://svn.apache.org/r1567643 > At the time no additional investigation into the root problem was attempted. > As part of SOLR-9028, I spent a little time trying to verify if this was > still a problem, and determined it was. I briefly attempted to get to the > bottom of it, and compiled a few notes on things to look into -- but > ultimately i don't have the time/resources to do any serious test on OSX > myself, and i didn't want this to block SOLR-9028 so i'm spinning it out into > it's own issue. -- 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=16999664#comment-16999664
]
Kevin Risden commented on SOLR-14106:
-
Uploaded a new version that leaves a lot of the Http2Client stuff the way it
used to work.
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.4, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, SOLR-14106.patch, SOLR-14106.patch,
> deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14106) SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
[
https://issues.apache.org/jira/browse/SOLR-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14106:
Attachment: SOLR-14106.patch
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.4, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, SOLR-14106.patch, SOLR-14106.patch,
> deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14106) SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
[
https://issues.apache.org/jira/browse/SOLR-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14106:
Attachment: (was: SOLR-14106.patch)
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.4, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, SOLR-14106.patch, SOLR-14106.patch,
> deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14106) SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
[
https://issues.apache.org/jira/browse/SOLR-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14106:
Attachment: (was: SOLR-14106.patch)
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.4, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, SOLR-14106.patch, SOLR-14106.patch,
> deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14106) SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
[
https://issues.apache.org/jira/browse/SOLR-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14106:
Attachment: SOLR-14106.patch
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.4, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, SOLR-14106.patch, SOLR-14106.patch,
> SOLR-14106.patch, deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14116) Support safe index modifications without re-indexing
Erick Erickson created SOLR-14116: - Summary: Support safe index modifications without re-indexing Key: SOLR-14116 URL: https://issues.apache.org/jira/browse/SOLR-14116 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Erick Erickson See the SIP here: https://cwiki.apache.org/confluence/display/SOLR/SIP-2+Support+safe+index+transformations+without+reindexing -- 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-14095) Remove serialization and/or support serialization filtering
[ https://issues.apache.org/jira/browse/SOLR-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999652#comment-16999652 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-14095: -- Isn’t this almost exactly what I did in my patch? How do you deal with things like int vs long? SimpleOrderedMap vs NamedList? > Remove serialization and/or support serialization filtering > --- > > Key: SOLR-14095 > URL: https://issues.apache.org/jira/browse/SOLR-14095 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14095-json.patch, json-nl.patch > > Time Spent: 1h > Remaining Estimate: 0h > > Removing the use of serialization is greatly preferred. > But if serialization over the wire must really happen, then we must use JDK's > serialization filtering capability to prevent havoc. > https://docs.oracle.com/javase/10/core/serialization-filtering1.htm#JSCOR-GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A -- 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-9100) JapaneseTokenizer produces inconsistent tokens
[
https://issues.apache.org/jira/browse/LUCENE-9100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999651#comment-16999651
]
Elbek Kamoliddinov commented on LUCENE-9100:
I wonder if we could just replace all punctuation characters (ie
{{JapaneseTokenizer#isPunctuation}}) with space, but then there is much logic
in the tokenizer for {{isPunctuation}}.
> JapaneseTokenizer produces inconsistent tokens
> --
>
> Key: LUCENE-9100
> URL: https://issues.apache.org/jira/browse/LUCENE-9100
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Affects Versions: 7.2
>Reporter: Elbek Kamoliddinov
>Priority: Major
>
> We use {{JapaneseTokenizer}} on prod and seeing some inconsistent behavior.
> With this text:
> {{"マギアリス【単版話】 4話 (Unlimited Comics)"}} I get different results if I insert
> space before `【` char. Here is the small code snippet demonstrating the case
> (not we use our own dictionary and connection costs):
> {code:java}
> Analyzer analyzer = new Analyzer() {
> @Override
> protected TokenStreamComponents createComponents(String
> fieldName) {
> //Tokenizer tokenizer = new
> JapaneseTokenizer(newAttributeFactory(), null, true,
> JapaneseTokenizer.Mode.SEARCH);
> Tokenizer tokenizer = new
> JapaneseTokenizer(newAttributeFactory(), dictionaries.systemDictionary,
> dictionaries.unknownDictionary, dictionaries.connectionCosts, null, true,
> JapaneseTokenizer.Mode.SEARCH);
> return new TokenStreamComponents(tokenizer, new
> LowerCaseFilter(tokenizer));
> }
> };
> String text1 = "マギアリス【単版話】 4話 (Unlimited Comics)";
> String text2 = "マギアリス 【単版話】 4話 (Unlimited Comics)"; //inserted space
> try (TokenStream tokens = analyzer.tokenStream("field", new
> StringReader(text1))) {
> CharTermAttribute chars =
> tokens.addAttribute(CharTermAttribute.class);
> tokens.reset();
> while (tokens.incrementToken()) {
> System.out.println(chars.toString());
> }
> tokens.end();
> } catch (IOException e) {
> // should never happen with a StringReader
> throw new RuntimeException(e);
> } {code}
> Output is:
> {code:java}
> //text1
> マギ
> アリス
> 単
> 版
> 話
> 4
> 話
> unlimited
> comics
> //text2
> マギア
> リス
> 単
> 版
> 話
> 4
> 話
> unlimited
> comics{code}
> It looks like tokenizer doesn't view the punctuation (\{{【}} is
> \{{Character.START_PUNCTUATION}} type) as an indicator that there should be a
> token break, and somehow 【 punctuation char causes difference in the output.
> If I use the {{JapaneseTokenizer}} tokenizer then this problem doesn't
> manifest because it doesn't tokenize {{マギアリス}} into multiple tokens and
> outputs as is.
--
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-9100) JapaneseTokenizer produces inconsistent tokens
Elbek Kamoliddinov created LUCENE-9100:
--
Summary: JapaneseTokenizer produces inconsistent tokens
Key: LUCENE-9100
URL: https://issues.apache.org/jira/browse/LUCENE-9100
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: 7.2
Reporter: Elbek Kamoliddinov
We use {{JapaneseTokenizer}} on prod and seeing some inconsistent behavior.
With this text:
{{"マギアリス【単版話】 4話 (Unlimited Comics)"}} I get different results if I insert
space before `【` char. Here is the small code snippet demonstrating the case
(not we use our own dictionary and connection costs):
{code:java}
Analyzer analyzer = new Analyzer() {
@Override
protected TokenStreamComponents createComponents(String fieldName) {
//Tokenizer tokenizer = new
JapaneseTokenizer(newAttributeFactory(), null, true,
JapaneseTokenizer.Mode.SEARCH);
Tokenizer tokenizer = new
JapaneseTokenizer(newAttributeFactory(), dictionaries.systemDictionary,
dictionaries.unknownDictionary, dictionaries.connectionCosts, null, true,
JapaneseTokenizer.Mode.SEARCH);
return new TokenStreamComponents(tokenizer, new
LowerCaseFilter(tokenizer));
}
};
String text1 = "マギアリス【単版話】 4話 (Unlimited Comics)";
String text2 = "マギアリス 【単版話】 4話 (Unlimited Comics)"; //inserted space
try (TokenStream tokens = analyzer.tokenStream("field", new
StringReader(text1))) {
CharTermAttribute chars =
tokens.addAttribute(CharTermAttribute.class);
tokens.reset();
while (tokens.incrementToken()) {
System.out.println(chars.toString());
}
tokens.end();
} catch (IOException e) {
// should never happen with a StringReader
throw new RuntimeException(e);
} {code}
Output is:
{code:java}
//text1
マギ
アリス
単
版
話
4
話
unlimited
comics
//text2
マギア
リス
単
版
話
4
話
unlimited
comics{code}
It looks like tokenizer doesn't view the punctuation (\{{【}} is
\{{Character.START_PUNCTUATION}} type) as an indicator that there should be a
token break, and somehow 【 punctuation char causes difference in the output.
If I use the {{JapaneseTokenizer}} tokenizer then this problem doesn't manifest
because it doesn't tokenize {{マギアリス}} into multiple tokens and outputs as is.
--
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-14095) Remove serialization and/or support serialization filtering
[ https://issues.apache.org/jira/browse/SOLR-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999642#comment-16999642 ] Noble Paul commented on SOLR-14095: --- I've attached a patch to deserialize JSON as NamedList. Now , you can get similar behavior to javabin > Remove serialization and/or support serialization filtering > --- > > Key: SOLR-14095 > URL: https://issues.apache.org/jira/browse/SOLR-14095 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14095-json.patch, json-nl.patch > > Time Spent: 1h > Remaining Estimate: 0h > > Removing the use of serialization is greatly preferred. > But if serialization over the wire must really happen, then we must use JDK's > serialization filtering capability to prevent havoc. > https://docs.oracle.com/javase/10/core/serialization-filtering1.htm#JSCOR-GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A -- 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-14095) Remove serialization and/or support serialization filtering
[ https://issues.apache.org/jira/browse/SOLR-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-14095: -- Attachment: json-nl.patch > Remove serialization and/or support serialization filtering > --- > > Key: SOLR-14095 > URL: https://issues.apache.org/jira/browse/SOLR-14095 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14095-json.patch, json-nl.patch > > Time Spent: 1h > Remaining Estimate: 0h > > Removing the use of serialization is greatly preferred. > But if serialization over the wire must really happen, then we must use JDK's > serialization filtering capability to prevent havoc. > https://docs.oracle.com/javase/10/core/serialization-filtering1.htm#JSCOR-GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14106) SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
[
https://issues.apache.org/jira/browse/SOLR-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14106:
Attachment: SOLR-14106.patch
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.4, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, SOLR-14106.patch, SOLR-14106.patch,
> deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
> There has been a Jetty upgrade from from jetty-9.4.14 to jetty-9.4.19 and I
> see some deprecation warnings in the log of 8.3.1:
> {noformat}
> o.e.j.x.XmlConfiguration Deprecated method public void
> org.eclipse.jetty.util.ssl.SslContextFactory.setWantClientAuth(boolean) in
> file:///opt/solr-8.3.1/server/etc/jetty-ssl.xml
> {noformat}
> I have made a simple reproduction script using Docker to reproduce first the
> 8.1.1 behaviour that succeeds, then 8.3.1 which fails:
> {code}
> wget https://www.dropbox.com/s/fkjcez1i5anh42i/tls.tgz
> tar -xvzf tls.tgz
> cd tls
> ./repro.sh
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14091) Remove deprecated soLingerTime when configuring Jetty connector
[
https://issues.apache.org/jira/browse/SOLR-14091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999614#comment-16999614
]
ASF subversion and git services commented on SOLR-14091:
Commit d226aba686dc271562779ed88b2a232243f83809 in lucene-solr's branch
refs/heads/branch_8x from Matthias Krueger
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d226aba ]
SOLR-14091: Removing deprecated configuration of Jetty's soLingerTime option
Signed-off-by: Kevin Risden
> Remove deprecated soLingerTime when configuring Jetty connector
> ---
>
> Key: SOLR-14091
> URL: https://issues.apache.org/jira/browse/SOLR-14091
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7.2, 8.3.1
>Reporter: Matthias Krueger
>Assignee: Kevin Risden
>Priority: Major
> Fix For: 8.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Jetty has deprecated ServerConnector#soLingerTime since 9.4.12 as "linger
> should not be set for NIO sockets" (see
> [https://github.com/eclipse/jetty.project/issues/2468]). We should remove it
> from configuration, too. Currently, there is a bunch of
> {code:java}
> [pool-1-thread-1] org.eclipse.jetty.server.AbstractConnector Ignoring
> deprecated socket close linger time {code}
> warnings spamming our logs.
--
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=16999591#comment-16999591
]
ASF subversion and git services commented on SOLR-14099:
Commit d30f90e34963f63c07df53df82960f927ab20a8e in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d30f90e ]
SOLR-14099: expanded comment on static final variable based on followup
questions in Jira from Dawid
> @LogLevel annotation not properly reseting after end of test (causes
> LoggingHandlerTest.testLogLevelHandlerOutput failures)
> ---
>
> Key: SOLR-14099
> URL: https://issues.apache.org/jira/browse/SOLR-14099
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Fix For: master (9.0), 8.5
>
> Attachments: SOLR-14099.patch, SOLR-14099.patch,
> SOLR-14099_test_workaround.patch
>
>
> We've seen a recent uptick in jenkins failures from
> {{LoggingHandlerTest.testLogLevelHandlerOutput}} that indicate the @LogLevel
> usage in other tests that have run earlier in the same JVM are _NOT_ properly
> being reset when those tests complete.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14095) Remove serialization and/or support serialization filtering
[ https://issues.apache.org/jira/browse/SOLR-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999572#comment-16999572 ] Anshum Gupta commented on SOLR-14095: - Thanks for doing this, Tomás. The responses here so unpredictable, that I think it makes sense to just to the basic work right now until we fix the responses themselves. For the purpose of security, I would recommend going with the Javabin approach for now. > Remove serialization and/or support serialization filtering > --- > > Key: SOLR-14095 > URL: https://issues.apache.org/jira/browse/SOLR-14095 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14095-json.patch > > Time Spent: 1h > Remaining Estimate: 0h > > Removing the use of serialization is greatly preferred. > But if serialization over the wire must really happen, then we must use JDK's > serialization filtering capability to prevent havoc. > https://docs.oracle.com/javase/10/core/serialization-filtering1.htm#JSCOR-GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A -- 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-14115) Deprecate zkcli and bin/solr zk support
[ https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999509#comment-16999509 ] Erick Erickson edited comment on SOLR-14115 at 12/18/19 10:41 PM: -- I won't argue too hard to remove "bin/solr zl *", I'm glad people find it useful. Certainly I've used it to fix up ZK nodes in emergency situations. If there were a good UI for editing Zookeeper, I'd advocate more strongly to remove "bin/solr zk *", but I don't find one on a quick search. I see several UI editors, but I don't have any confidence that they'll be maintained long-term. was (Author: erickerickson): I won't argue too hard to remove bin/solr, I'm glad people find it useful. Certainly I've used it to fix up ZK nodes in emergency situations. If there were a good UI for editing Zookeeper, I'd advocate more strongly to remove bin/solr, but I don't find one on a quick search. I see several UI editors, but I don't have any confidence that they'll be maintained long-term. > Deprecate zkcli and bin/solr zk support > --- > > Key: SOLR-14115 > URL: https://issues.apache.org/jira/browse/SOLR-14115 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Reporter: Erick Erickson >Priority: Major > > I think it's a valid argument that these have outlived their usefulness and > we should remove them and have APIs to do what Solr requires. Especially if > we can find and point to a third-party visual ZK tool for _changing_ > arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI > (although I don't see how to change data in ZK with it. Haven't looked very > much). > While we're ripping stuff out of Solr, are these candidates? It would break > my heart to rip ZK support out from bin/solr, but all good things must come > to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of > doing the same thing? > Mark put the zkcli stuff in before we had APIs to do what Solr needs to do > with ZK, mainly uploading configsets at the time. I put the zk support in > bin/solr also before the APIs existed because I thought having to learn our > custom wrapper for ZK was yet another orphan bit of code laying around. All > before we had things like the configsets API. > Personally, I'd prefer removing zkcli rather than bin/solr, but that's > because I originated the bin/solr code ;) > This occurred when reading SOLR-14109, I'm not entirely sure what I _really_ > think about it. -- 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-14115) Deprecate zkcli and bin/solr zk support
[ https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999509#comment-16999509 ] Erick Erickson edited comment on SOLR-14115 at 12/18/19 10:41 PM: -- I won't argue too hard to remove "bin/solr zk *", I'm glad people find it useful. Certainly I've used it to fix up ZK nodes in emergency situations. If there were a good UI for editing Zookeeper, I'd advocate more strongly to remove "bin/solr zk *", but I don't find one on a quick search. I see several UI editors, but I don't have any confidence that they'll be maintained long-term. was (Author: erickerickson): I won't argue too hard to remove "bin/solr zl *", I'm glad people find it useful. Certainly I've used it to fix up ZK nodes in emergency situations. If there were a good UI for editing Zookeeper, I'd advocate more strongly to remove "bin/solr zk *", but I don't find one on a quick search. I see several UI editors, but I don't have any confidence that they'll be maintained long-term. > Deprecate zkcli and bin/solr zk support > --- > > Key: SOLR-14115 > URL: https://issues.apache.org/jira/browse/SOLR-14115 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Reporter: Erick Erickson >Priority: Major > > I think it's a valid argument that these have outlived their usefulness and > we should remove them and have APIs to do what Solr requires. Especially if > we can find and point to a third-party visual ZK tool for _changing_ > arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI > (although I don't see how to change data in ZK with it. Haven't looked very > much). > While we're ripping stuff out of Solr, are these candidates? It would break > my heart to rip ZK support out from bin/solr, but all good things must come > to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of > doing the same thing? > Mark put the zkcli stuff in before we had APIs to do what Solr needs to do > with ZK, mainly uploading configsets at the time. I put the zk support in > bin/solr also before the APIs existed because I thought having to learn our > custom wrapper for ZK was yet another orphan bit of code laying around. All > before we had things like the configsets API. > Personally, I'd prefer removing zkcli rather than bin/solr, but that's > because I originated the bin/solr code ;) > This occurred when reading SOLR-14109, I'm not entirely sure what I _really_ > think about it. -- 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-14091) Remove deprecated soLingerTime when configuring Jetty connector
[
https://issues.apache.org/jira/browse/SOLR-14091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14091:
Fix Version/s: 8.5
> Remove deprecated soLingerTime when configuring Jetty connector
> ---
>
> Key: SOLR-14091
> URL: https://issues.apache.org/jira/browse/SOLR-14091
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7.2, 8.3.1
>Reporter: Matthias Krueger
>Assignee: Kevin Risden
>Priority: Major
> Fix For: 8.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Jetty has deprecated ServerConnector#soLingerTime since 9.4.12 as "linger
> should not be set for NIO sockets" (see
> [https://github.com/eclipse/jetty.project/issues/2468]). We should remove it
> from configuration, too. Currently, there is a bunch of
> {code:java}
> [pool-1-thread-1] org.eclipse.jetty.server.AbstractConnector Ignoring
> deprecated socket close linger time {code}
> warnings spamming our logs.
--
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-14042) Fix 7 Varargs methods should only override or be overridden by other varargs methods warnings
[
https://issues.apache.org/jira/browse/SOLR-14042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski reassigned SOLR-14042:
--
Assignee: Jason Gerlowski
> Fix 7 Varargs methods should only override or be overridden by other varargs
> methods warnings
> -
>
> Key: SOLR-14042
> URL: https://issues.apache.org/jira/browse/SOLR-14042
> Project: Solr
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-14042-01.patch
>
>
> Precommit lists 7 quite similar varargs related warnings:
> {noformat}
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/ConcatEvaluator.java
> (at line 46)
> [ecj-lint] public Object doWork(Object values[]) throws IOException {
> [ecj-lint] ^^
> [ecj-lint] Varargs methods should only override or be overridden by other
> varargs methods unlike ConcatEvaluator.doWork(Object[]) and
> ManyValueWorker.doWork(Object...)
> --
> [ecj-lint] 2. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/DateEvaluator.java
> (at line 44)
> [ecj-lint] public Object doWork(Object values[]) throws IOException {
> [ecj-lint] ^^
> [ecj-lint] Varargs methods should only override or be overridden by other
> varargs methods unlike DateEvaluator.doWork(Object[]) and
> ManyValueWorker.doWork(Object...)
> --
> [ecj-lint] 3. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/DbscanEvaluator.java
> (at line 44)
> [ecj-lint] public Object doWork(Object values[]) throws IOException {
> [ecj-lint] ^^
> [ecj-lint] Varargs methods should only override or be overridden by other
> varargs methods unlike DbscanEvaluator.doWork(Object[]) and
> ManyValueWorker.doWork(Object...)
> --
> [ecj-lint] 4. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/EmpiricalDistributionEvaluator.java
> (at line 41)
> [ecj-lint] public Object doWork(Object[] values) throws IOException {
> [ecj-lint] ^^
> [ecj-lint] Varargs methods should only override or be overridden by other
> varargs methods unlike EmpiricalDistributionEvaluator.doWork(Object[]) and
> ManyValueWorker.doWork(Object...)
> --
> [ecj-lint] 5. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/MatchesEvaluator.java
> (at line 39)
> [ecj-lint] public Object doWork(Object[] values) throws IOException {
> [ecj-lint] ^^
> [ecj-lint] Varargs methods should only override or be overridden by other
> varargs methods unlike MatchesEvaluator.doWork(Object[]) and
> ManyValueWorker.doWork(Object...)
> --
> [ecj-lint] 6. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/MatchesEvaluator.java
> (at line 39)
> [ecj-lint] public Object doWork(Object[] values) throws IOException {
> [ecj-lint] ^^
> [ecj-lint] Varargs methods should only override or be overridden by other
> varargs methods unlike MatchesEvaluator.doWork(Object[]) and
> RecursiveBooleanEvaluator.doWork(Object...)
> --
> [ecj-lint] 7. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/PivotEvaluator.java
> (at line 45)
> [ecj-lint] public Object doWork(Object[] values) throws IOException {
> [ecj-lint] ^^
> [ecj-lint] Varargs methods should only override or be overridden by other
> varargs methods unlike PivotEvaluator.doWork(Object[]) and
> ManyValueWorker.doWork(Object...) {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-13822) Isolated Classloading from packages
[
https://issues.apache.org/jira/browse/SOLR-13822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999529#comment-16999529
]
ASF subversion and git services commented on SOLR-13822:
Commit 221d4ed5572ea21de792b93c228fbc0e4cb91174 in lucene-solr's branch
refs/heads/branch_8_4 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=221d4ed ]
SOLR-13822: Bug fixs and tests for URP loading
> Isolated Classloading from packages
> ---
>
> Key: SOLR-13822
> URL: https://issues.apache.org/jira/browse/SOLR-13822
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13822.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Design is here:
> [https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?ts=5d86a8ad#]
>
> main features:
> * A new file for packages definition (/packages.json) in ZK
> * Public APIs to edit/read the file
> * The APIs are registered at {{/api/cluster/package}}
> * Classes can be loaded from the package classloader using the
> {{:}} syntax
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14115) Deprecate zkcli and bin/solr zk support
[ https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999509#comment-16999509 ] Erick Erickson commented on SOLR-14115: --- I won't argue too hard to remove bin/solr, I'm glad people find it useful. Certainly I've used it to fix up ZK nodes in emergency situations. If there were a good UI for editing Zookeeper, I'd advocate more strongly to remove bin/solr, but I don't find one on a quick search. I see several UI editors, but I don't have any confidence that they'll be maintained long-term. > Deprecate zkcli and bin/solr zk support > --- > > Key: SOLR-14115 > URL: https://issues.apache.org/jira/browse/SOLR-14115 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Reporter: Erick Erickson >Priority: Major > > I think it's a valid argument that these have outlived their usefulness and > we should remove them and have APIs to do what Solr requires. Especially if > we can find and point to a third-party visual ZK tool for _changing_ > arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI > (although I don't see how to change data in ZK with it. Haven't looked very > much). > While we're ripping stuff out of Solr, are these candidates? It would break > my heart to rip ZK support out from bin/solr, but all good things must come > to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of > doing the same thing? > Mark put the zkcli stuff in before we had APIs to do what Solr needs to do > with ZK, mainly uploading configsets at the time. I put the zk support in > bin/solr also before the APIs existed because I thought having to learn our > custom wrapper for ZK was yet another orphan bit of code laying around. All > before we had things like the configsets API. > Personally, I'd prefer removing zkcli rather than bin/solr, but that's > because I originated the bin/solr code ;) > This occurred when reading SOLR-14109, I'm not entirely sure what I _really_ > think about it. -- 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-14095) Remove serialization and/or support serialization filtering
[ https://issues.apache.org/jira/browse/SOLR-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe updated SOLR-14095: - Attachment: SOLR-14095-json.patch Status: Open (was: Open) Here is a patch using Noggit to serialize to Json. The problem with this approach is that from the context of the code we don't know what's being serialized. The "response" NamedList contains the responses that different shards gave to the Overseer for the commands. It's not easy to use in this case, it'll require a lot of work to serialize correctly, and I think it's not worth it. Jackson wouldn't be better for the same reason, we don't know exactly what's going to be in the response (and even worse, could change as Solr evolves). The alternative if we want Json is to change how this code is being used, but I believe that's out of the scope of this issue. I think we should go with the Javabin approach for now, currently the serialization is Java native, so it's unlikely that someone is using the content of the znode currently for debugging/monitoring. > Remove serialization and/or support serialization filtering > --- > > Key: SOLR-14095 > URL: https://issues.apache.org/jira/browse/SOLR-14095 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14095-json.patch > > Time Spent: 1h > Remaining Estimate: 0h > > Removing the use of serialization is greatly preferred. > But if serialization over the wire must really happen, then we must use JDK's > serialization filtering capability to prevent havoc. > https://docs.oracle.com/javase/10/core/serialization-filtering1.htm#JSCOR-GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A -- 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-14044) Support shard/collection deletion in shared storage
[ https://issues.apache.org/jira/browse/SOLR-14044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999475#comment-16999475 ] Andy Vuong commented on SOLR-14044: --- CollectionDeletion and ShardDeletion add new deletion flows we need to support. A few functional requirements for collection deletion: * Deletion of all index files belonging to a collection located in the blob store * Removal of any local in-memory metadata used by the collection such as SharedConcurrencyMetadataCache By nature of using shared storage (S3, GCS), the first requirement may always be “best effort”. Reason being these are eventually consistent systems. In S3, list commands are eventually consistent so if we issue collection API delete, finding all the files belonging to a collection (we’re always key-ed on collection name), then we might not find everything. Fortunately the same isn’t true in GCS. Our design calls for adding an “orphaned” file deleter in the future. By orphan, we mean any index file not referenced by any core.metadata file in the shared store. This isn’t covered in this JIRA but it’s likely where we handle these instances of stale reads. The second requirement refers to an implementation detail of our shard indexing concurrency but is required if we want to support reusing shard/collection names. We store in the JVM cache metadata that needs to be evicted. Achieving this via distributed clean up might be difficult so we may want to do some kind of clean up on creation of replicas that are similarly named. The downside is if no such thing happens, then we have objects sitting in memory until the node restarts. Design-wise, we may want the deletion processes to be flexible to extend beyond these functional requirements if down the line we expand shared collections to store other objects aside from index files in blob. I'd prefer to refactor the BlobDeleteManager and extend its capability beyond the aync deletions it does now but I'll unlikely reuse the same queue we've established as the single deletion process won't scale with more collections/shards per solr node and something like a Collection:Delete API call is likely a task with higher priority than the files being deleted on the indexing flow (also not async). > Support shard/collection deletion in shared storage > --- > > Key: SOLR-14044 > URL: https://issues.apache.org/jira/browse/SOLR-14044 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Andy Vuong >Priority: Major > > The Solr Cloud deletion APIs for collections and shards are not currently > supported by shared storage but are an essential functionality required by > the shared storage design. Deletion of objects from shared storage currently > only happens in the indexing path (on pushes) and after the index file > listings between the local solr process and external store have been resolved. > > This task is to track supporting the delete shard/collection API commands and > its scope does not include cleaning up so called “orphaned” index files from > blob (i.e. files that are no longer referenced by any core.metadata file on > the external store). This will be designed/covered in another subtask. -- 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-9039) Get to the bottom of why clientAuth (SSL certificate) testing on OSX doesn't work
[ https://issues.apache.org/jira/browse/SOLR-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999461#comment-16999461 ] Kevin Risden commented on SOLR-9039: FWIW this still fails if I comment out the assume on Mac so its not just magically fixed. > Get to the bottom of why clientAuth (SSL certificate) testing on OSX doesn't > work > - > > Key: SOLR-9039 > URL: https://issues.apache.org/jira/browse/SOLR-9039 > Project: Solr > Issue Type: Bug >Reporter: Chris M. Hostetter >Priority: Major > > When randomized SSL/clientAuth testing was introduced in SOLR-3854 it was > quickly determined that something about OSX didn't play nicely with the way > we were testing clientAuth certificates... > https://issues.apache.org/jira/browse/SOLR-3854?focusedCommentId=13897983#comment-13897983 > https://svn.apache.org/r1567643 > At the time no additional investigation into the root problem was attempted. > As part of SOLR-9028, I spent a little time trying to verify if this was > still a problem, and determined it was. I briefly attempted to get to the > bottom of it, and compiled a few notes on things to look into -- but > ultimately i don't have the time/resources to do any serious test on OSX > myself, and i didn't want this to block SOLR-9028 so i'm spinning it out into > it's own issue. -- 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-14115) Deprecate zkcli and bin/solr zk support
[ https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999439#comment-16999439 ] Ishan Chattopadhyaya commented on SOLR-14115: - bq. Personally, I'd prefer removing zkcli rather than bin/solr +1 to removing zkcli. Let us keep "bin/solr zk". It is super useful, and something we should maintain, given that API way of uploading configsets can result in a crippled "untrusted" configset. > Deprecate zkcli and bin/solr zk support > --- > > Key: SOLR-14115 > URL: https://issues.apache.org/jira/browse/SOLR-14115 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Reporter: Erick Erickson >Priority: Major > > I think it's a valid argument that these have outlived their usefulness and > we should remove them and have APIs to do what Solr requires. Especially if > we can find and point to a third-party visual ZK tool for _changing_ > arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI > (although I don't see how to change data in ZK with it. Haven't looked very > much). > While we're ripping stuff out of Solr, are these candidates? It would break > my heart to rip ZK support out from bin/solr, but all good things must come > to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of > doing the same thing? > Mark put the zkcli stuff in before we had APIs to do what Solr needs to do > with ZK, mainly uploading configsets at the time. I put the zk support in > bin/solr also before the APIs existed because I thought having to learn our > custom wrapper for ZK was yet another orphan bit of code laying around. All > before we had things like the configsets API. > Personally, I'd prefer removing zkcli rather than bin/solr, but that's > because I originated the bin/solr code ;) > This occurred when reading SOLR-14109, I'm not entirely sure what I _really_ > think about it. -- 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-13778) Windows JDK SSL Test Failure trend: SSLException: Software caused connection abort: recv failed
[
https://issues.apache.org/jira/browse/SOLR-13778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999398#comment-16999398
]
Kevin Risden edited comment on SOLR-13778 at 12/18/19 6:31 PM:
---
So I haven't completely followed what is going on here, but is it possible
SOLR-14091 is related? Specifically from that issue
https://github.com/eclipse/jetty.project/issues/2468?
Edit - E - probably not since we are on Jetty version that ignores the
setting anyway. I just saw Windows and weird exceptions and thought hmmm.
was (Author: risdenk):
So I haven't completely followed what is going on here, but is it possible
SOLR-14091 is related? Specifically from that issue
https://github.com/eclipse/jetty.project/issues/2468?
> Windows JDK SSL Test Failure trend: SSLException: Software caused connection
> abort: recv failed
> ---
>
> Key: SOLR-13778
> URL: https://issues.apache.org/jira/browse/SOLR-13778
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: dumps-LegacyCloud.zip, logs-2019-12-12-1.zip,
> recv-multiple-2019-12-18.zip
>
>
> Now that Uwe's jenkins build has been correctly reporting it's build results
> for my [automated
> reports|http://fucit.org/solr-jenkins-reports/failure-report.html] to pick
> up, I've noticed a pattern of failures that indicate a definite problem with
> using SSL on Windows (even with java 11.0.4
> )
> The symptommatic stack traces all contain...
> {noformat}
> ...
>[junit4]> Caused by: javax.net.ssl.SSLException: Software caused
> connection abort: recv failed
>[junit4]>at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
> ...
>[junit4]> Caused by: java.net.SocketException: Software caused
> connection abort: recv failed
>[junit4]>at
> java.base/java.net.SocketInputStream.socketRead0(Native Method)
> ...
> {noformat}
> I suspect this may be related to
> [https://bugs.openjdk.java.net/browse/JDK-8209333] but i have no concrete
> evidence to back this up.
> I'll post some details of my analysis in comments...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14111) Revert SOLR-13541 which breaks SSL client auth
[ https://issues.apache.org/jira/browse/SOLR-14111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999405#comment-16999405 ] Kevin Risden commented on SOLR-14111: - So I don't think we need to upgrade Jetty. I think if the fix in SOLR-14106 is good, that should be enough to fix problems in branch_8_4. It is worth testing the patch from SOLR-14106 on branch_8_4 in isolation. I think with proper Server and Client, Jetty should work. I could be wrong but that would be my recommendation. I think going backwards on a dependency like Jetty in a bug fix release is a bit weird. It seems like a heavy hammer if we can avoid it. > Revert SOLR-13541 which breaks SSL client auth > -- > > Key: SOLR-14111 > URL: https://issues.apache.org/jira/browse/SOLR-14111 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: 8.2, 8.3, 8.4, 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Propose to revert SOLR-13541 which was the commit introducing the regression. > This means rolling back to Jetty 9.4.14, in branch_8_4 only. Then release a > bugfix version 8.4.1 with this fix. > The full fix of this issue will come in SOLR-14105 and SOLR-14106 in 8.5.0 > but is more involved, requires further upgrade of Jetty beyond 9.4.19 and is > thus not suitable for a bugfix release. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-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=16999406#comment-16999406
]
Lucene/Solr QA commented on SOLR-14106:
---
| (x) *{color:red}-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
39s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 9s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 45m 41s{color}
| {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}121m 9s{color}
| {color:red} solrj in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
28s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}172m 48s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.ZkFailoverTest |
| | solr.cloud.DocValuesNotIndexedTest |
| | solr.cloud.api.collections.CollectionTooManyReplicasTest |
| | solr.cloud.TestSSLRandomization |
| | solr.cloud.LeaderVoteWaitTimeoutTest |
| | solr.handler.component.CustomTermsComponentTest |
| | solr.cloud.TestExactStatsCacheCloud |
| | solr.cloud.DeleteNodeTest |
| | solr.handler.TestSystemCollAutoCreate |
| | solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClientTest |
| | solr.client.solrj.io.stream.MathExpressionTest |
| | solr.client.solrj.io.sql.JdbcTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14106 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12989104/SOLR-14106.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 56839f6 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/634/artifact/out/patch-unit-solr_core.txt
|
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/634/artifact/out/patch-unit-solr_solrj.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/634/testReport/ |
| modules | C: solr/core solr/server solr/solrj solr/test-framework U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/634/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
> ---
>
> Key: SOLR-14106
> URL: https://issues.apache.org/jira/browse/SOLR-14106
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 8.2, 8.3, 8.4, 8.3.1
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Labels: jetty, ssl
> Fix For: 8.5
>
> Attachments: SOLR-14106.patch, SOLR-14106.patch,
> deprecation-warning.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For a client we use SSL certificate authentication with Solr through the
> {{SOLR_SSL_NEED_CLIENT_AUTH=true}} setting. The client must then prove
> through a local pem file that it has the correct client certificate.
> This works well until Solr 8.1.1, but fails with Solr 8.2 and also 8.3.1.
>
[jira] [Created] (SOLR-14114) Add WARN to Solr log that embedded ZK is not supported in production
Jan Høydahl created SOLR-14114:
--
Summary: Add WARN to Solr log that embedded ZK is not supported in
production
Key: SOLR-14114
URL: https://issues.apache.org/jira/browse/SOLR-14114
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: logging
Reporter: Jan Høydahl
When Solr starts with embedded {{-DzkRun}} zookeeper, we currently log these
lines:
{noformat}
2019-12-18 16:38:00.171 INFO (main) [ ] o.a.s.c.SolrZkServerProps Reading
configuration from: /var/solr/data/zoo.cfg
2019-12-18 16:38:00.173 INFO (main) [ ] o.a.s.c.SolrZkServer STARTING
EMBEDDED STANDALONE ZOOKEEPER SERVER at port 9983
2019-12-18 16:38:00.673 INFO (main) [ ] o.a.s.c.ZkContainer Zookeeper
client=localhost:9983 {noformat}
In addition we should log a WARN line about not using it in production
{noformat}
WARN (main) [ ] o.a.s.c.SolrZkServer Embedded Zookeeper is not supported in
production environments{noformat}
This is already stated on the "[Taking Solr to
production|https://lucene.apache.org/solr/guide/8_3/taking-solr-to-production.html#going-to-production-with-solrcloud];
RefGuide page. We should also add a more prominent WARNING box to RefGuide
about the same.
--
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=16999385#comment-16999385 ] ASF subversion and git services commented on SOLR-14054: Commit f06e32c9691ff1b7dfb16199a0563d8293af734e in lucene-solr's branch refs/heads/branch_8x from Tim Allison [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f06e32c ] SOLR-14054 -- need to add xml-apis for Java 8 after upgrading xerces > 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-13778) Windows JDK SSL Test Failure trend: SSLException: Software caused connection abort: recv failed
[
https://issues.apache.org/jira/browse/SOLR-13778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999356#comment-16999356
]
Chris M. Hostetter commented on SOLR-13778:
---
{quote}
The context of these failures is not clear to me. Chris M. Hostetter - could
you take a look at these logs (grep for "recv failed" and look at a few lines
of prior context) and tell if it's expected that these sockets are closed? I
mean – is the server really dropping those connections?
{quote}
I honestly have no idea. I am in no way adapt/fluent in the low level
HTTP/connection management stuff in solr -- that's why i was hopping [~shalin],
[~caomanhdat2], or [~markrmil...@gmail.com] could chime in.
(My level of involvement/knowledge on this issue is really just limited to
noticing that the pattern existed on windows boxes when doing high level
analyzing the jenkins failure rates & failure logs, and trying to raise
awareness of it with people who: a) understand windows, b) understand the
HTTP/SSL code involved.)
> Windows JDK SSL Test Failure trend: SSLException: Software caused connection
> abort: recv failed
> ---
>
> Key: SOLR-13778
> URL: https://issues.apache.org/jira/browse/SOLR-13778
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: dumps-LegacyCloud.zip, logs-2019-12-12-1.zip,
> recv-multiple-2019-12-18.zip
>
>
> Now that Uwe's jenkins build has been correctly reporting it's build results
> for my [automated
> reports|http://fucit.org/solr-jenkins-reports/failure-report.html] to pick
> up, I've noticed a pattern of failures that indicate a definite problem with
> using SSL on Windows (even with java 11.0.4
> )
> The symptommatic stack traces all contain...
> {noformat}
> ...
>[junit4]> Caused by: javax.net.ssl.SSLException: Software caused
> connection abort: recv failed
>[junit4]>at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
> ...
>[junit4]> Caused by: java.net.SocketException: Software caused
> connection abort: recv failed
>[junit4]>at
> java.base/java.net.SocketInputStream.socketRead0(Native Method)
> ...
> {noformat}
> I suspect this may be related to
> [https://bugs.openjdk.java.net/browse/JDK-8209333] but i have no concrete
> evidence to back this up.
> I'll post some details of my analysis in comments...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13822) Isolated Classloading from packages
[
https://issues.apache.org/jira/browse/SOLR-13822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999352#comment-16999352
]
Ishan Chattopadhyaya commented on SOLR-13822:
-
bq. I have other changes I want to make there, so can do it all together. BUT
that means that there will be conflicts backporting the commit as-is.
I'm +1 to that. No worries about backports; we'll take care.
> Isolated Classloading from packages
> ---
>
> Key: SOLR-13822
> URL: https://issues.apache.org/jira/browse/SOLR-13822
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13822.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Design is here:
> [https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?ts=5d86a8ad#]
>
> main features:
> * A new file for packages definition (/packages.json) in ZK
> * Public APIs to edit/read the file
> * The APIs are registered at {{/api/cluster/package}}
> * Classes can be loaded from the package classloader using the
> {{:}} syntax
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[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=16999350#comment-16999350
]
Chris M. Hostetter commented on SOLR-14099:
---
{quote}... shouldn't this be moved into BeforeClass block?
{quote}
As the test is written write now it could be – but then it would run _after_
the logic in {{@BeforeClass}} methods of superclasses – like {{SolrTestCaseJ4}}
where a {{@BeforeClass}} method parses & executres the {{@LogLevel}} annotation
on this test class and mucks with the Loggers
By making this static final i was trying to avoid that and capture the original
default logging level as early as possible, before there is any chance that the
{{LogLevel}} annotation logic invoked by {{SolrTestCaseJ4}} ... ie: exactly
your point about it only being invoked once per JVM, ... that's what i wanted.
An earlier iteration of this test that i never shared was trying to capture the
"DEFAULT" levels of multiple packages before the annotation was run, and ran
into that exact problem – hence I used {{static final}} vars. The current test
only cares about capture the DEFAULT level of the "root" logger so it's less of
an issue because the LogLevel annotation doesn't _intentionally_ muck with the
root logger, but it still seemed prudent not to do this in a {{@BeforeClass}}
to prevent any risk of "contamination" if the Annotation logic is ever broken
in the future so that it _unintentinally_ changes the root logger.
make sense?
> @LogLevel annotation not properly reseting after end of test (causes
> LoggingHandlerTest.testLogLevelHandlerOutput failures)
> ---
>
> Key: SOLR-14099
> URL: https://issues.apache.org/jira/browse/SOLR-14099
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Fix For: master (9.0), 8.5
>
> Attachments: SOLR-14099.patch, SOLR-14099.patch,
> SOLR-14099_test_workaround.patch
>
>
> We've seen a recent uptick in jenkins failures from
> {{LoggingHandlerTest.testLogLevelHandlerOutput}} that indicate the @LogLevel
> usage in other tests that have run earlier in the same JVM are _NOT_ properly
> being reset when those tests complete.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13579) Create resource management API
[
https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999344#comment-16999344
]
Andrzej Bialecki edited comment on SOLR-13579 at 12/18/19 4:54 PM:
---
A few notes on the soft optimization strategy.
Optimization is performed only when the total limit is not exceeded, because it
may want to not only shrink but also expand cache sizes, thus making a bad
situation worse.
Some background on hitRatio vs cache size: the relationship between cache size
and hit ratio is positive and monotonic, ie. larger cache size leads to a
higher hit ratio (an extreme example would be an unlimited cache that has a
perfect recall because it keeps all items). On the other hand there's a point
where increasing the size yields diminishing returns in terms of higher hit
ratio, if you also consider the cost of the resources it consumes. So there's
likely a sweet spot in the cache size where the hit ratio is still "good
enough" but the resource consumption is minimized. In the proposed patch this
hit ratio threshold is 0.8, which is probably too high for realistic loads
(should we use something like 0.6?).
Hit ratio, by its definition, is an average outcome of several trials on a
stochastic process. For this average to have a desired confidence there's a
minimum number of trials (samples) needed. I'm using a formula of {{0.5 /
sqrt(lookups)}} to determine the minimum number of lookups for a given
confidence level - the default value being 100 lookups for a 5% accuracy. If
there are fewer lookups between adjustments then this means the current hit
ratio cannot be determined with enough confidence and the optimization is
skipped.
Maximum possible adjustments are bounded by a {{maxAdjustRatio}} (by default
2.0). This means that we can grow or shrink the cache at most by this factor,
compared to the initially configured limit. This functionality prevents the
algorithm from balooning or shrinking the cache indefinitely for very busy or
very idle caches.
(This algorithm is in fact a very simple P controller, without the ID factors
(yet :) )).
was (Author: ab):
A few notes on the soft optimization strategy.
Optimization is performed only when the total limit is not exceeded, because it
may want to not only shrink but also expand cache sizes, thus making a bad
situation worse.
Some background on hitRatio vs cache size: the relationship between cache size
and hit ratio is positive and monotonic, ie. larger cache size leads to a
higher hit ratio (an extreme example would be an unlimited cache that has a
perfect recall because it keeps all items). On the other hand there's a point
where increasing the size yields diminishing returns in terms of higher hit
ratio, if you also consider the cost of the resources it consumes. So there's
likely a sweet spot in the cache size where the hit ratio is still "good
enough" but the resource consumption is minimized. In the proposed patch this
hit ratio threshold is 0.8, which is probably too high for realistic loads
(should we use something like 0.6?).
Hit ratio, by its definition, is an average outcome of several trials on a
stochastic process. For this average to have a desired confidence there's a
minimum number of trials (samples) needed. I'm using a formula of {{0.5 /
sqrt(lookups)}} to determine the minimum number of lookups for a given
confidence level - the default value being 100 lookups for a 5% accuracy. If
there are fewer lookups between adjustments then this means the current hit
ratio cannot be determined with enough confidence and the optimization is
skipped.
Maximum possible adjustments are bounded by a {{maxAdjustRatio}} (by default
2.0). This means that we can grow or shrink the cache at most by this factor,
compared to the initially configured limit. This functionality prevents the
algorithm from balooning or shrinking the cache indefinitely for very busy or
very idle caches.
> Create resource management API
> --
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
> Issue Type: New Feature
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch,
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch,
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Resource management framework API supporting the goals outlined in SOLR-13578.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail:
[jira] [Commented] (SOLR-13662) Package manager CLI
[ https://issues.apache.org/jira/browse/SOLR-13662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999343#comment-16999343 ] ASF subversion and git services commented on SOLR-13662: Commit 56824fb6d74a6f3df8959de10beda489d92637de in lucene-solr's branch refs/heads/branch_8x from Cassandra Targett [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=56824fb ] SOLR-13662: Improvements for Ref Guide package-manager.adoc > Package manager CLI > --- > > Key: SOLR-13662 > URL: https://issues.apache.org/jira/browse/SOLR-13662 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.4 > > Attachments: plugin-cli.png > > Time Spent: 19h > Remaining Estimate: 0h > > Design details and usage details are here: > https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?ts=5d86a8ad# -- 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-13662) Package manager CLI
[ https://issues.apache.org/jira/browse/SOLR-13662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999342#comment-16999342 ] ASF subversion and git services commented on SOLR-13662: Commit fc2fbb2f7e43b0749d25ab56508aba71a0dc36ac in lucene-solr's branch refs/heads/master from Cassandra Targett [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fc2fbb2 ] SOLR-13662: Improvements for Ref Guide package-manager.adoc > Package manager CLI > --- > > Key: SOLR-13662 > URL: https://issues.apache.org/jira/browse/SOLR-13662 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.4 > > Attachments: plugin-cli.png > > Time Spent: 19h > Remaining Estimate: 0h > > Design details and usage details are here: > https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?ts=5d86a8ad# -- 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-13662) Package manager CLI
[ https://issues.apache.org/jira/browse/SOLR-13662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999345#comment-16999345 ] ASF subversion and git services commented on SOLR-13662: Commit 2738bfe3dc05a6b7b3ca0feab6c53fd6a67c0c7e in lucene-solr's branch refs/heads/branch_8_4 from Cassandra Targett [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2738bfe ] SOLR-13662: Improvements for Ref Guide package-manager.adoc > Package manager CLI > --- > > Key: SOLR-13662 > URL: https://issues.apache.org/jira/browse/SOLR-13662 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.4 > > Attachments: plugin-cli.png > > Time Spent: 19h > Remaining Estimate: 0h > > Design details and usage details are here: > https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?ts=5d86a8ad# -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13579) Create resource management API
[
https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999344#comment-16999344
]
Andrzej Bialecki commented on SOLR-13579:
-
A few notes on the soft optimization strategy.
Optimization is performed only when the total limit is not exceeded, because it
may want to not only shrink but also expand cache sizes, thus making a bad
situation worse.
Some background on hitRatio vs cache size: the relationship between cache size
and hit ratio is positive and monotonic, ie. larger cache size leads to a
higher hit ratio (an extreme example would be an unlimited cache that has a
perfect recall because it keeps all items). On the other hand there's a point
where increasing the size yields diminishing returns in terms of higher hit
ratio, if you also consider the cost of the resources it consumes. So there's
likely a sweet spot in the cache size where the hit ratio is still "good
enough" but the resource consumption is minimized. In the proposed patch this
hit ratio threshold is 0.8, which is probably too high for realistic loads
(should we use something like 0.6?).
Hit ratio, by its definition, is an average outcome of several trials on a
stochastic process. For this average to have a desired confidence there's a
minimum number of trials (samples) needed. I'm using a formula of {{0.5 /
sqrt(lookups)}} to determine the minimum number of lookups for a given
confidence level - the default value being 100 lookups for a 5% accuracy. If
there are fewer lookups between adjustments then this means the current hit
ratio cannot be determined with enough confidence and the optimization is
skipped.
Maximum possible adjustments are bounded by a {{maxAdjustRatio}} (by default
2.0). This means that we can grow or shrink the cache at most by this factor,
compared to the initially configured limit. This functionality prevents the
algorithm from balooning or shrinking the cache indefinitely for very busy or
very idle caches.
> Create resource management API
> --
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
> Issue Type: New Feature
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch,
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch,
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Resource management framework API supporting the goals outlined in SOLR-13578.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13822) Isolated Classloading from packages
[
https://issues.apache.org/jira/browse/SOLR-13822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999336#comment-16999336
]
Cassandra Targett edited comment on SOLR-13822 at 12/18/19 4:50 PM:
I'd be more than happy to backport the docs changes myself - I have other
changes I want to make there, so can do it all together. BUT that means that
there will be conflicts backporting the commit as-is. The bug fixes would need
to be similarly manually applied to branch_8x in that case.
I'll hold on the doc changes until Noble can reply about what's going on with
the code changes.
was (Author: ctargett):
I'd be more than happy to backport the docs changes myself - I have other
changes I want to make there, so can do it all together. BUT that means that
there will be conflicts backporting the commit as-is. The bug fixes would need
to be similarly manually applied to branch_8x.
> Isolated Classloading from packages
> ---
>
> Key: SOLR-13822
> URL: https://issues.apache.org/jira/browse/SOLR-13822
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13822.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Design is here:
> [https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?ts=5d86a8ad#]
>
> main features:
> * A new file for packages definition (/packages.json) in ZK
> * Public APIs to edit/read the file
> * The APIs are registered at {{/api/cluster/package}}
> * Classes can be loaded from the package classloader using the
> {{:}} syntax
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13822) Isolated Classloading from packages
[
https://issues.apache.org/jira/browse/SOLR-13822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999336#comment-16999336
]
Cassandra Targett commented on SOLR-13822:
--
I'd be more than happy to backport the docs changes myself - I have other
changes I want to make there, so can do it all together. BUT that means that
there will be conflicts backporting the commit as-is. The bug fixes would need
to be similarly manually applied to branch_8x.
> Isolated Classloading from packages
> ---
>
> Key: SOLR-13822
> URL: https://issues.apache.org/jira/browse/SOLR-13822
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13822.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Design is here:
> [https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?ts=5d86a8ad#]
>
> main features:
> * A new file for packages definition (/packages.json) in ZK
> * Public APIs to edit/read the file
> * The APIs are registered at {{/api/cluster/package}}
> * Classes can be loaded from the package classloader using the
> {{:}} syntax
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] sigram opened a new pull request #1100: SOLR-13579: Create resource management API
sigram opened a new pull request #1100: SOLR-13579: Create resource management API URL: https://github.com/apache/lucene-solr/pull/1100 Please see JIRA for details. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13822) Isolated Classloading from packages
[
https://issues.apache.org/jira/browse/SOLR-13822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999319#comment-16999319
]
Ishan Chattopadhyaya commented on SOLR-13822:
-
Damn, even I have no clue. I can backport the changes to the doc; they look
important. But, not sure about the other code changes in that commit.
[~noble.paul], can you please take a look?
> Isolated Classloading from packages
> ---
>
> Key: SOLR-13822
> URL: https://issues.apache.org/jira/browse/SOLR-13822
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13822.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Design is here:
> [https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?ts=5d86a8ad#]
>
> main features:
> * A new file for packages definition (/packages.json) in ZK
> * Public APIs to edit/read the file
> * The APIs are registered at {{/api/cluster/package}}
> * Classes can be loaded from the package classloader using the
> {{:}} syntax
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14113) Add more file types to DIH's unit tests to ensure dependency coverage
Tim Allison created SOLR-14113: -- Summary: Add more file types to DIH's unit tests to ensure dependency coverage Key: SOLR-14113 URL: https://issues.apache.org/jira/browse/SOLR-14113 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Tim Allison As part of SOLR-14054, [~dweiss] noted that the unit tests pass without the commons-csv dependency, which is, in fact, required if a csv file is sent to DIH. Let's add several more file types to the unit tests to include dependency coverage. -- 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=16999295#comment-16999295 ] Tim Allison commented on SOLR-14054: Got it. Thank you, [~dweiss]. I see that the Lucene benchmarks module also relies on xerces. Should I add a dependency on xml-apis there, too? Or, given that its unit tests pass, should we hope for the best? > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999265#comment-16999265 ] Dawid Weiss commented on SOLR-14054: ElementTraversal and other xml-api classes are part of the JDK from Java 9. You only need to include them for Java 8. I can't remember but something wasn't working for me with overrides in tika-config... but feel free to share! > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13822) Isolated Classloading from packages
[
https://issues.apache.org/jira/browse/SOLR-13822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999262#comment-16999262
]
Cassandra Targett commented on SOLR-13822:
--
[~noble.paul], [~ichattopadhyaya] - this commit:
https://github.com/apache/lucene-solr/commit/f98555854cbdb9d396c34a93fde9c1610df74882#diff-04f78a3e0960a743f6b4267e2d0f7f49
was only pushed to {{master}} branch and not {{branch_8x}}. Thus these changes
*do not* appear in 8.4, which is contrary to what this issue says. The bug
fixes and doc changes will not be available to users. I can pull out the doc
changes, but it's too late, I guess for the bug fixes?
> Isolated Classloading from packages
> ---
>
> Key: SOLR-13822
> URL: https://issues.apache.org/jira/browse/SOLR-13822
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13822.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Design is here:
> [https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?ts=5d86a8ad#]
>
> main features:
> * A new file for packages definition (/packages.json) in ZK
> * Public APIs to edit/read the file
> * The APIs are registered at {{/api/cluster/package}}
> * Classes can be loaded from the package classloader using the
> {{:}} syntax
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[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=16999254#comment-16999254 ] Tim Allison commented on SOLR-14054: [~dweiss], will do on a separate issue if that's ok. You can tell Tika to avoid loading the TextAndCSVParser and use the TXTParser instead via tika-config.xml. If you'd prefer this behavior either offline or in Solr, I can show you how to do that. > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14112) do not display load average of -1.00 on windows in admin UI
[ https://issues.apache.org/jira/browse/SOLR-14112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-14112: --- Attachment: SOLR-14112.patch > do not display load average of -1.00 on windows in admin UI > --- > > Key: SOLR-14112 > URL: https://issues.apache.org/jira/browse/SOLR-14112 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.5 >Reporter: Robert Muir >Priority: Major > Fix For: 8.5 > > Attachments: SOLR-14112.patch > > > I caused this with SOLR-13983. The OSMXBean returns -1, we should handle that > in the javascript and display nothing at all, to prevent confusion. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14112) do not display load average of -1.00 on windows in admin UI
[ https://issues.apache.org/jira/browse/SOLR-14112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999252#comment-16999252 ] Robert Muir commented on SOLR-14112: untested patch: i have issues with my windows VM crashing my os X kernel from time to time :( > do not display load average of -1.00 on windows in admin UI > --- > > Key: SOLR-14112 > URL: https://issues.apache.org/jira/browse/SOLR-14112 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.5 >Reporter: Robert Muir >Priority: Major > Fix For: 8.5 > > Attachments: SOLR-14112.patch > > > I caused this with SOLR-13983. The OSMXBean returns -1, we should handle that > in the javascript and display nothing at all, to prevent confusion. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [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=16999247#comment-16999247 ] Tim Allison commented on SOLR-14054: [~hossman] I can replicate this now. I should have caught this before the commit. I clearly tested with Java 11 when I thought I was testing with Java 8. This is my fault. The problem is solved if we add the xml-apis dependency, which xerces requires. It looks like the earlier version of xerces didn't happen to require xml-apis on the execution paths the unit tests were exercising. I can't explain why this isn't a problem with Java 11. > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13579) Create resource management API
[ https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-13579: Attachment: SOLR-13579.patch > Create resource management API > -- > > Key: SOLR-13579 > URL: https://issues.apache.org/jira/browse/SOLR-13579 > Project: Solr > Issue Type: New Feature >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch > > > Resource management framework API supporting the goals outlined in SOLR-13578. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13579) Create resource management API
[ https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-13579: Attachment: (was: SOLR-13579.patch) > Create resource management API > -- > > Key: SOLR-13579 > URL: https://issues.apache.org/jira/browse/SOLR-13579 > Project: Solr > Issue Type: New Feature >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch > > > Resource management framework API supporting the goals outlined in SOLR-13578. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13579) Create resource management API
[ https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-13579: Attachment: SOLR-13579.patch > Create resource management API > -- > > Key: SOLR-13579 > URL: https://issues.apache.org/jira/browse/SOLR-13579 > Project: Solr > Issue Type: New Feature >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch > > > Resource management framework API supporting the goals outlined in SOLR-13578. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14110) sandbox javax.script usage in tests
[ https://issues.apache.org/jira/browse/SOLR-14110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999200#comment-16999200 ] ASF subversion and git services commented on SOLR-14110: Commit 612cba38cab168a41392506cda6ebfe03a9af916 in lucene-solr's branch refs/heads/gradle-master from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=612cba3 ] SOLR-14110: sandbox javax.script usage in tests > sandbox javax.script usage in tests > --- > > Key: SOLR-14110 > URL: https://issues.apache.org/jira/browse/SOLR-14110 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Major > Fix For: 8.5 > > Attachments: SOLR-14110.patch > > > Similar to SOLR-13993 we should sandbox the use of javax.script if security > manager is present. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6236) TestICUNormalizer2CharFilter test is failing consistently
[ https://issues.apache.org/jira/browse/LUCENE-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-6236. - Resolution: Won't Fix This is no longer true on master (the test succeeds, generally), and we're not going to go back and fix an issue from 5 major versions ago, even if it is still reproducing there... > TestICUNormalizer2CharFilter test is failing consistently > - > > Key: LUCENE-6236 > URL: https://issues.apache.org/jira/browse/LUCENE-6236 > Project: Lucene - Core > Issue Type: Test >Affects Versions: 4.10.3 >Reporter: Hrishikesh Gadre >Priority: Major > > In my development environment, following unit test is failing consistently. > ant test -Dtestcase=TestICUNormalizer2CharFilter > -Dtests.method=testRandomStrings -Dtests.seed=E27DEA12D513F6FF > -Dtests.slow=true -Dtests.locale=ru -Dtests.timezone=PNT -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 >[junit4] FAILURE 1.70s | TestICUNormalizer2CharFilter.testRandomStrings <<< >[junit4]> Throwable #1: java.lang.AssertionError: startOffset 625 > expected:<5377> but was:<5378> >[junit4]> at > __randomizedtesting.SeedInfo.seed([E27DEA12D513F6FF:6AF4EAAC7617A1CA]:0) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:183) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:296) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:300) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:815) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:614) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:513) >[junit4]> at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:437) >[junit4]> at > org.apache.lucene.analysis.icu.TestICUNormalizer2CharFilter.testRandomStrings(TestICUNormalizer2CharFilter.java:186) >[junit4]> at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999192#comment-16999192 ] Dawid Weiss commented on SOLR-14054: Right. I don't think we can exclude the csv dependency - I recall trying to make the plain text parser avoid pulling csv classes but tika defaulted to using this class (which does some auto-detection): https://github.com/apache/tika/blob/4b330263d1759c35886e6243d5edc5426be54029/tika-parsers/src/main/java/org/apache/tika/parser/csv/TextAndCSVParser.java and csv classes are hard referenced. A test that would fail (on missing dependency) added on top of this patch would be great. > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3006) Javadocs warnings should fail the build
[ https://issues.apache.org/jira/browse/LUCENE-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-3006. - Resolution: Fixed This 8-year-old issue got fixed at some point - checking javadocs is now part of precommit. I think we can close as Fixed. > Javadocs warnings should fail the build > --- > > Key: LUCENE-3006 > URL: https://issues.apache.org/jira/browse/LUCENE-3006 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 3.2, 4.0-ALPHA >Reporter: Grant Ingersoll >Priority: Major > Attachments: LUCENE-3006-javadoc-warning-cleanup.patch, > LUCENE-3006-modules-javadoc-warning-cleanup.patch, LUCENE-3006.patch, > LUCENE-3006.patch, LUCENE-3006.patch > > > We should fail the build when there are javadocs warnings, as this should not > be the Release Manager's job to fix all at once right before the release. > See > http://www.lucidimagination.com/search/document/14bd01e519f39aff/brainstorming_on_improving_the_release_process -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8222) TestICUTokenizerCJK failure
[
https://issues.apache.org/jira/browse/LUCENE-8222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999188#comment-16999188
]
Michael Sokolov commented on LUCENE-8222:
-
The ICU bug was marked fixed in 63.1; we should try upgrading and see we can
re-enable this test
> TestICUTokenizerCJK failure
> ---
>
> Key: LUCENE-8222
> URL: https://issues.apache.org/jira/browse/LUCENE-8222
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Priority: Major
>
> This reproduces for me:
> {code:java}
> [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestICUTokenizerCJK
> -Dtests.method=testRandomHugeStrings -Dtests.seed=2C1F4414ECB02FE4
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=pl-PL
> -Dtests.timezone=Europe/Athens -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
> [junit4] FAILURE 0.57s | TestICUTokenizerCJK.testRandomHugeStrings <<<
> [junit4] > Throwable #1: org.junit.ComparisonFailure: term 128 expected:<ー[]>
> but was:<ー[デ]>
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([2C1F4414ECB02FE4:B43C23D7B2C693AC]:0)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:201)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:325)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:329)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:869)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:668)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:566)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:479)
> [junit4] > at
> org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK.testRandomHugeStrings(TestICUTokenizerCJK.java:107)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit4] > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit4] > at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [junit4] > at java.base/java.lang.Thread.run(Thread.java:844)
> [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70):
> {dummy=PostingsFormat(name=LuceneVarGapDocFreqInterval)}, docValues:{},
> maxPointsInLeafNode=1800, maxMBSortInHeap=7.290162896982681,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@3f70f3d9),
> locale=pl-PL, timezone=Europe/Athens
> [junit4] 2> NOTE: Mac OS X 10.13.3 x86_64/Oracle Corporation 9.0.1
> (64-bit)/cpus=8,threads=1,free=150530048,total=268435456{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8494) CFS leaks a file on exception opening it
[
https://issues.apache.org/jira/browse/LUCENE-8494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999184#comment-16999184
]
Dawid Weiss commented on LUCENE-8494:
-
I think we can close and reopen if needed. Please close JIRA issues with
'cannot reproduce' or a similar status indicating the issue may still be there.
I'm not sure if this is the case here.
> CFS leaks a file on exception opening it
>
>
> Key: LUCENE-8494
> URL: https://issues.apache.org/jira/browse/LUCENE-8494
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/codecs
>Reporter: Robert Muir
>Priority: Major
>
> If CFS hits an exception opening its file, it will leak the file handle.
> Found by Jenkins: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/808/
> {noformat}
> java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are
> still 7 open files: {_j.cfs=1, _h.cfs=1, _e.cfs=1, _g.cfs=1, _i.cfs=1,
> _k.cfs=1, _f.cfs=1}
> ...
> Caused by: java.lang.RuntimeException: unclosed IndexInput: _f.cfs
> at
> org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:730)
> at
> org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:773)
> at
> org.apache.lucene.codecs.lucene50.Lucene50CompoundReader.(Lucene50CompoundReader.java:78)
> {noformat}
> Looks like it needs to move opening of {{handle}} into the try block
> (untested):
> {noformat}
> diff --git
> a/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
>
> b/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
> index 7526c88c20..db54ecdee2 100644
> ---
> a/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
> +++
> b/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50CompoundReader.java
> @@ -75,8 +75,8 @@ final class Lucene50CompoundReader extends Directory {
> }
> expectedLength += CodecUtil.footerLength();
>
> -handle = directory.openInput(dataFileName, context);
> try {
> + handle = directory.openInput(dataFileName, context);
>CodecUtil.checkIndexHeader(handle, Lucene50CompoundFormat.DATA_CODEC,
> version, version, si.getId(), "");
>
>// NOTE: data file is too costly to verify checksum against all the
> bytes on open,
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8488) Javadoc examples should be kept in sync with actual compiled code
[ https://issues.apache.org/jira/browse/LUCENE-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999183#comment-16999183 ] Dawid Weiss commented on LUCENE-8488: - Precisely. I think this would have to wait until the switch to gradle is complete. Doing this in ant is going to be nighmarish. > Javadoc examples should be kept in sync with actual compiled code > - > > Key: LUCENE-8488 > URL: https://issues.apache.org/jira/browse/LUCENE-8488 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Minor > > This isn't something that is done trivially, unfortunately, but can be hacked > around. And it'd help to keep the docs up-to-date. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8488) Javadoc examples should be kept in sync with actual compiled code
[ https://issues.apache.org/jira/browse/LUCENE-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999175#comment-16999175 ] Michael Sokolov commented on LUCENE-8488: - [~dweiss]can you elaborate what your idea here is? Are you thinking of a way to *automatically* keep examples in javadocs up to date? > Javadoc examples should be kept in sync with actual compiled code > - > > Key: LUCENE-8488 > URL: https://issues.apache.org/jira/browse/LUCENE-8488 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Minor > > This isn't something that is done trivially, unfortunately, but can be hacked > around. And it'd help to keep the docs up-to-date. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8517) TestRandomChains.testRandomChainsWithLargeStrings failure
[
https://issues.apache.org/jira/browse/LUCENE-8517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Sokolov resolved LUCENE-8517.
-
Resolution: Fixed
> TestRandomChains.testRandomChainsWithLargeStrings failure
> -
>
> Key: LUCENE-8517
> URL: https://issues.apache.org/jira/browse/LUCENE-8517
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Reporter: Steven Rowe
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> From
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2828/consoleText],
> reproduces for me on Java8:
> {noformat}
> Checking out Revision 216f10026b86627750e133fe24ce6a750c470695
> (refs/remotes/origin/branch_7x)
> [...]
> [java-info] java version "10.0.1"
> [java-info] OpenJDK Runtime Environment (10.0.1+10, Oracle Corporation)
> [java-info] OpenJDK 64-Bit Server VM (10.0.1+10, Oracle Corporation)
> [java-info] Test args: [-XX:-UseCompressedOops -XX:+UseConcMarkSweepGC]
> [...]
>[junit4] Suite: org.apache.lucene.analysis.core.TestRandomChains
>[junit4] 2> Exception from random analyzer:
>[junit4] 2> charfilters=
>[junit4] 2>
> org.apache.lucene.analysis.charfilter.MappingCharFilter(org.apache.lucene.analysis.charfilter.NormalizeCharMap@3ef95503,
> java.io.StringReader@70dde633)
>[junit4] 2>
> org.apache.lucene.analysis.fa.PersianCharFilter(org.apache.lucene.analysis.charfilter.MappingCharFilter@12423b20)
>[junit4] 2> tokenizer=
>[junit4] 2> org.apache.lucene.analysis.th.ThaiTokenizer()
>[junit4] 2> filters=
>[junit4] 2>
> org.apache.lucene.analysis.compound.HyphenationCompoundWordTokenFilter(ValidatingTokenFilter@7914bba7
>
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,
> org.apache.lucene.analysis.compound.hyphenation.HyphenationTree@abd7bca)
>[junit4] 2>
> Conditional:org.apache.lucene.analysis.MockGraphTokenFilter(java.util.Random@56348091,
> OneTimeWrapper@aa1c073
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1)
>[junit4] 2>
> Conditional:org.apache.lucene.analysis.shingle.FixedShingleFilter(OneTimeWrapper@4cf58fce
>
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,
> 4, , )
>[junit4] 2>
> org.apache.lucene.analysis.pt.PortugueseLightStemFilter(ValidatingTokenFilter@3a915324
>
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,keyword=false)
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestRandomChains
> -Dtests.method=testRandomChainsWithLargeStrings -Dtests.seed=92344C536D4E00F4
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en-ZW
> -Dtests.timezone=Atlantic/Faroe -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR 0.46s J2 |
> TestRandomChains.testRandomChainsWithLargeStrings <<<
>[junit4]> Throwable #1: java.lang.IllegalStateException: stage 3:
> inconsistent startOffset at pos=0: 0 vs 5; token=effort
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([92344C536D4E00F4:F86FF34234002007]:0)
>[junit4]> at
> org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:109)
>[junit4]> at
> org.apache.lucene.analysis.pt.PortugueseLightStemFilter.incrementToken(PortugueseLightStemFilter.java:48)
>[junit4]> at
> org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:68)
>[junit4]> at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException(BaseTokenStreamTestCase.java:441)
>[junit4]> at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:546)
>[junit4]> at
> org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings(TestRandomChains.java:897)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70):
> {dummy=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128)))},
> docValues:{}, maxPointsInLeafNode=214,
[jira] [Commented] (LUCENE-8530) fix some 'rawtypes' javac warnings
[ https://issues.apache.org/jira/browse/LUCENE-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999163#comment-16999163 ] Michael Sokolov commented on LUCENE-8530: - [~cpoerschke] did you want to push this? Otherwise, we could close the issue as abandoned/won't fix > fix some 'rawtypes' javac warnings > -- > > Key: LUCENE-8530 > URL: https://issues.apache.org/jira/browse/LUCENE-8530 > Project: Lucene - Core > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: LUCENE-8530.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8547) Add a build target that beasts all of the tests modified in the last commit.
[ https://issues.apache.org/jira/browse/LUCENE-8547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov updated LUCENE-8547: Summary: Add a build target that beasts all of the tests modified in the last commit. (was: Add an ant target that beasts all of the tests modified in the last commit.) > Add a build target that beasts all of the tests modified in the last commit. > > > Key: LUCENE-8547 > URL: https://issues.apache.org/jira/browse/LUCENE-8547 > Project: Lucene - Core > Issue Type: Test >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8561) Heap dump while search the index
[ https://issues.apache.org/jira/browse/LUCENE-8561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-8561. - Resolution: Abandoned closing since the issue is stale and there is no way to repro > Heap dump while search the index > > > Key: LUCENE-8561 > URL: https://issues.apache.org/jira/browse/LUCENE-8561 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 4.3 >Reporter: Roshini >Priority: Major > > A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_IN_PAGE_ERROR (0xc006) at pc=0x08e02b78, pid=9892, > tid=8688 > # > # JRE version: Java(TM) SE Runtime Environment (8.0_74-b02) (build > 1.8.0_74-b02) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.74-b02 mixed mode > windows-amd64 compressed oops) > # Problematic frame: > # J 45372 C2 > org.apache.lucene.store.CompoundFileDirectory.readEntries(Lorg/apache/lucene/store/Directory$IndexInputSlicer;Lorg/apache/lucene/store/Directory;Ljava/lang/String;)Ljava/util/Map; > (387 bytes) @ 0x08e02b78 [0x08e02a40+0x138] > # > # Failed to write core dump. Minidump has been disabled from the command line > # > # If you would like to submit a bug report, please visit: > # [http://bugreport.java.com/bugreport/crash.jsp] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14111) Revert SOLR-13541 which breaks SSL client auth
[ https://issues.apache.org/jira/browse/SOLR-14111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999152#comment-16999152 ] Jan Høydahl commented on SOLR-14111: [~krisden] do you agree that for 8.4.1 it is safer to revert jetty than to upgrade it? As I understood, v9.4.19 is also broken wrt client auth? Doing both jetty upgrade and your fixes for a bugfix release seems a bit too much. > Revert SOLR-13541 which breaks SSL client auth > -- > > Key: SOLR-14111 > URL: https://issues.apache.org/jira/browse/SOLR-14111 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Propose to revert SOLR-13541 which was the commit introducing the regression. > This means rolling back to Jetty 9.4.14, in branch_8_4 only. Then release a > bugfix version 8.4.1 with this fix. > The full fix of this issue will come in SOLR-14105 and SOLR-14106 in 8.5.0 > but is more involved, requires further upgrade of Jetty beyond 9.4.19 and is > thus not suitable for a bugfix release. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14111) Revert SOLR-13541 which breaks SSL client auth
[ https://issues.apache.org/jira/browse/SOLR-14111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-14111: --- Affects Version/s: 8.4 8.2 8.3 8.3.1 > Revert SOLR-13541 which breaks SSL client auth > -- > > Key: SOLR-14111 > URL: https://issues.apache.org/jira/browse/SOLR-14111 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.2, 8.3, 8.4, 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Propose to revert SOLR-13541 which was the commit introducing the regression. > This means rolling back to Jetty 9.4.14, in branch_8_4 only. Then release a > bugfix version 8.4.1 with this fix. > The full fix of this issue will come in SOLR-14105 and SOLR-14106 in 8.5.0 > but is more involved, requires further upgrade of Jetty beyond 9.4.19 and is > thus not suitable for a bugfix release. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14111) Revert SOLR-13541 which breaks SSL client auth
[ https://issues.apache.org/jira/browse/SOLR-14111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-14111: --- Component/s: Server > Revert SOLR-13541 which breaks SSL client auth > -- > > Key: SOLR-14111 > URL: https://issues.apache.org/jira/browse/SOLR-14111 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: 8.2, 8.3, 8.4, 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Propose to revert SOLR-13541 which was the commit introducing the regression. > This means rolling back to Jetty 9.4.14, in branch_8_4 only. Then release a > bugfix version 8.4.1 with this fix. > The full fix of this issue will come in SOLR-14105 and SOLR-14106 in 8.5.0 > but is more involved, requires further upgrade of Jetty beyond 9.4.19 and is > thus not suitable for a bugfix release. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999151#comment-16999151 ] Tim Allison commented on SOLR-14054: [~dweiss], you are right. I only found this issue when I ran all of Tika's unit test docs against the upgraded Solr. I think users would be surprised to get a ClassNotFoundException when they send a csv file to DIH. I can add unit tests for more file format coverage (including csv) or we can configure Tika to use only the TXTParser in Solr. Let me know your preference. > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy opened a new pull request #1099: SOLR-14111: Revert SOLR13541 which breaks SSL client auth
janhoy opened a new pull request #1099: SOLR-14111: Revert SOLR13541 which breaks SSL client auth URL: https://github.com/apache/lucene-solr/pull/1099 See https://issues.apache.org/jira/browse/SOLR-14111 for details This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8596) The replacement of comments is a bug, in "UserDictionary.java"
[
https://issues.apache.org/jira/browse/LUCENE-8596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999146#comment-16999146
]
Michael Sokolov commented on LUCENE-8596:
-
That looks like a real problem we should fix. There's no way to include a
token with a "#" in a user dictionary. However it's problematic since any
change here will not be backwards-compatible.
We can just change the behavior to respect comments only at the beginning of
the line, and document the breaking change. Some users may get bit when they
upgrade (if they have been using the other comment style in their dictionaries).
Or, we can introduce some API change to support both styles of commenting. This
seems overly complex for a pretty small edge case though: I favor fixing the
behavior with a breaking change plus documentation in CHANGES. If there's no
objection, I'll merge this and add a note to CHANGES
> The replacement of comments is a bug, in "UserDictionary.java"
> --
>
> Key: LUCENE-8596
> URL: https://issues.apache.org/jira/browse/LUCENE-8596
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Reporter: miyaharas
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/lucene/analysis/kuromoji/src/java/org/apache/lucene/analysis/ja/dict/UserDictionary.java#L68]
>
> hi
> I think that this is bug.
> I think the following is correct
> {code:java}
> line = line.replaceAll ("^ #. * $", "");
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13190) Fuzzy search treated as server error instead of client error when terms are too complex
[
https://issues.apache.org/jira/browse/SOLR-13190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999118#comment-16999118
]
Andy Webb edited comment on SOLR-13190 at 12/18/19 1:18 PM:
Thanks Mike!
I've [tried adding|https://github.com/apache/lucene-solr/pull/1098] a
{{maxQueryLength}} option to {{Direct(Solr)SpellChecker}} which can be set to
prevent long terms being spellchecked - it's a simple change, largely a
cut-and-paste of the {{minQueryLength}}, and as far as I can see this would
prevent us seeing the exceptions. It could default to 0, i.e. "no limit", to
maintain the existing default behaviour unless it's deliberately set. Would
this be a reasonable change to make to Lucene/Solr or do you think there might
be a better approach?
was (Author: andywebb1975):
Thanks Mike!
I've [tried
adding|https://github.com/apache/lucene-solr/compare/master...andywebb1975:maxQueryLength]
a {{maxQueryLength}} option to {{Direct(Solr)SpellChecker}} which can be set
to prevent long terms being spellchecked - it's a simple change, largely a
cut-and-paste of the {{minQueryLength}}, and as far as I can see this would
prevent us seeing the exceptions. It could default to 0, i.e. "no limit", to
maintain the existing default behaviour unless it's deliberately set. Would
this be a reasonable change to make to Lucene/Solr or do you think there might
be a better approach?
> Fuzzy search treated as server error instead of client error when terms are
> too complex
> ---
>
> Key: SOLR-13190
> URL: https://issues.apache.org/jira/browse/SOLR-13190
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We've seen a fuzzy search end up breaking the automaton and getting reported
> as a server error. This usage should be improved by
> 1) reporting as a client error, because it's similar to something like too
> many boolean clauses queries in how an operator should deal with it
> 2) report what field is causing the error, since that currently must be
> deduced from adjacent query logs and can be difficult if there are multiple
> terms in the search
> This trigger was added to defend against adversarial regex but somehow hits
> fuzzy terms as well, I don't understand enough about the automaton mechanisms
> to really know how to approach a fix there, but improving the operability is
> a good first step.
> relevant stack trace:
> {noformat}
> org.apache.lucene.util.automaton.TooComplexToDeterminizeException:
> Determinizing automaton with 13632 states and 21348 transitions would result
> in more than 1 states.
> at
> org.apache.lucene.util.automaton.Operations.determinize(Operations.java:746)
> at
> org.apache.lucene.util.automaton.RunAutomaton.(RunAutomaton.java:69)
> at
> org.apache.lucene.util.automaton.ByteRunAutomaton.(ByteRunAutomaton.java:32)
> at
> org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:247)
> at
> org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:133)
> at
> org.apache.lucene.search.FuzzyTermsEnum.(FuzzyTermsEnum.java:143)
> at org.apache.lucene.search.FuzzyQuery.getTermsEnum(FuzzyQuery.java:154)
> at
> org.apache.lucene.search.MultiTermQuery$RewriteMethod.getTermsEnum(MultiTermQuery.java:78)
> at
> org.apache.lucene.search.TermCollectingRewrite.collectTerms(TermCollectingRewrite.java:58)
> at
> org.apache.lucene.search.TopTermsRewrite.rewrite(TopTermsRewrite.java:67)
> at
> org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:310)
> at
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:442)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1420)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:567)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1435)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:374)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at
[GitHub] [lucene-solr] andywebb1975 opened a new pull request #1098: SOLR-13190 - added maxQueryLength parameter
andywebb1975 opened a new pull request #1098: SOLR-13190 - added maxQueryLength parameter URL: https://github.com/apache/lucene-solr/pull/1098 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
