[jira] [Commented] (LUCENE-9383) Port benchmark module Ant build to Gradle
[ https://issues.apache.org/jira/browse/LUCENE-9383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127528#comment-17127528 ] Dawid Weiss commented on LUCENE-9383: - No problem at all, David. Your help is very much appreciated. > Port benchmark module Ant build to Gradle > - > > Key: LUCENE-9383 > URL: https://issues.apache.org/jira/browse/LUCENE-9383 > Project: Lucene - Core > Issue Type: Sub-task > Components: modules/benchmark >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: master (9.0) > > Time Spent: 2h > Remaining Estimate: 0h > > The benchmark's build is more than a conventional build, it also has scripts > to fetch sample data for perf testing, and a task to run a perf test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] iverase commented on pull request #1475: LUCENE-9148: Move the BKD index to its own file.
iverase commented on pull request #1475: URL: https://github.com/apache/lucene-solr/pull/1475#issuecomment-640178481 Once we move a codec to backwards codecs, it can only be used for reading and still we are moving the `Lucene60PointsWriter` to that package. Is that necessary? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14345) Error messages are not properly propagated with non-default response parsers
[
https://issues.apache.org/jira/browse/SOLR-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-14345:
Attachment: SOLR-14345.patch
> Error messages are not properly propagated with non-default response parsers
>
>
> Key: SOLR-14345
> URL: https://issues.apache.org/jira/browse/SOLR-14345
> Project: Solr
> Issue Type: Bug
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-14345.patch, SOLR-14345.patch, SOLR-14345.patch,
> SOLR-14345.patch, SOLR-14345.patch
>
>
> Default {{ResponsParseer}} is {{BinaryResponseParser}}. when non-default
> response parser is specified in the request then, the error message is
> propagated to user. This happens in solrCloud mode.
> I came across this problem when working on adding some test which uses
> {{SolrTestCaseHS}} but similar problem exists with SolrJ client
> Also, same problem exists in both HttpSolrClient and Http2SolrClient
--
This message was sent by Atlassian Jira
(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-14345) Error messages are not properly propagated with non-default response parsers
[
https://issues.apache.org/jira/browse/SOLR-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127553#comment-17127553
]
Munendra S N commented on SOLR-14345:
-
[^SOLR-14345.patch]
Rebased and removed unnecessary refactoring. I will commit this once pre-commit
build succeeds
> Error messages are not properly propagated with non-default response parsers
>
>
> Key: SOLR-14345
> URL: https://issues.apache.org/jira/browse/SOLR-14345
> Project: Solr
> Issue Type: Bug
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-14345.patch, SOLR-14345.patch, SOLR-14345.patch,
> SOLR-14345.patch, SOLR-14345.patch
>
>
> Default {{ResponsParseer}} is {{BinaryResponseParser}}. when non-default
> response parser is specified in the request then, the error message is
> propagated to user. This happens in solrCloud mode.
> I came across this problem when working on adding some test which uses
> {{SolrTestCaseHS}} but similar problem exists with SolrJ client
> Also, same problem exists in both HttpSolrClient and Http2SolrClient
--
This message was sent by Atlassian Jira
(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-14329) Add support to choose field for expand component from multiple collapse groups
[
https://issues.apache.org/jira/browse/SOLR-14329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127555#comment-17127555
]
Munendra S N commented on SOLR-14329:
-
[~ctargett]
Apologies for the delay. I had added documentation for
[{{expand.field}}|https://github.com/apache/lucene-solr/blob/branch_8x/solr/solr-ref-guide/src/collapse-and-expand-results.adoc#expand-component]
in this commit {{dd79ed915d121ae70b2661be2c467e2a880037f8}}. Let me know if
anything else needs to be added
> Add support to choose field for expand component from multiple collapse groups
> --
>
> Key: SOLR-14329
> URL: https://issues.apache.org/jira/browse/SOLR-14329
> Project: Solr
> Issue Type: Improvement
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Fix For: 8.6
>
> Attachments: SOLR-14329.patch
>
>
> SOLR-14073, Fixed NPE issue when multiple collapse groups are specified.
> ExpandComponent could be used with Collapse but expand only supports single
> field. So, There should be way to choose collapse group for expand. Low cost
> collapse group should be given higher priority.
--
This message was sent by Atlassian Jira
(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-13492) Disallow explicit GC by default during Solr startup
[ https://issues.apache.org/jira/browse/SOLR-13492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N updated SOLR-13492: Description: Solr should use the -XX:+DisableExplicitGC option as part of its default GC tuning. None of Solr's stock code uses explicit GCs, so that option will have no effect on most installs. The effective result of this is that if somebody adds custom code to Solr and THAT code does an explicit GC, it won't be allowed to function. Update: Based on the discussion in the JIRA, adding was: Solr should use the -XX:+DisableExplicitGC option as part of its default GC tuning. None of Solr's stock code uses explicit GCs, so that option will have no effect on most installs. The effective result of this is that if somebody adds custom code to Solr and THAT code does an explicit GC, it won't be allowed to function. > Disallow explicit GC by default during Solr startup > --- > > Key: SOLR-13492 > URL: https://issues.apache.org/jira/browse/SOLR-13492 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Major > Attachments: SOLR-13492.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Solr should use the -XX:+DisableExplicitGC option as part of its default GC > tuning. > None of Solr's stock code uses explicit GCs, so that option will have no > effect on most installs. The effective result of this is that if somebody > adds custom code to Solr and THAT code does an explicit GC, it won't be > allowed to function. > > Update: Based on the discussion in the JIRA, adding -- This message was sent by Atlassian Jira (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-13492) Add ExplicitGCInvokesConcurrent by default during Solr startup
[
https://issues.apache.org/jira/browse/SOLR-13492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-13492:
Summary: Add ExplicitGCInvokesConcurrent by default during Solr startup
(was: Disallow explicit GC by default during Solr startup)
> Add ExplicitGCInvokesConcurrent by default during Solr startup
> --
>
> Key: SOLR-13492
> URL: https://issues.apache.org/jira/browse/SOLR-13492
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Major
> Attachments: SOLR-13492.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Solr should use the -XX:+DisableExplicitGC option as part of its default GC
> tuning.
> None of Solr's stock code uses explicit GCs, so that option will have no
> effect on most installs. The effective result of this is that if somebody
> adds custom code to Solr and THAT code does an explicit GC, it won't be
> allowed to function.
>
> Update: Based on the discussion in the JIRA, adding
> {{ExplicitGCInvokesConcurrent}} option instead {{DisableExplicitGC}} so that
> jcmd, jvisualvm could be run
--
This message was sent by Atlassian Jira
(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-13492) Disallow explicit GC by default during Solr startup
[
https://issues.apache.org/jira/browse/SOLR-13492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-13492:
Description:
Solr should use the -XX:+DisableExplicitGC option as part of its default GC
tuning.
None of Solr's stock code uses explicit GCs, so that option will have no effect
on most installs. The effective result of this is that if somebody adds custom
code to Solr and THAT code does an explicit GC, it won't be allowed to function.
Update: Based on the discussion in the JIRA, adding
{{ExplicitGCInvokesConcurrent}} option instead {{DisableExplicitGC}} so that
jcmd, jvisualvm could be run
was:
Solr should use the -XX:+DisableExplicitGC option as part of its default GC
tuning.
None of Solr's stock code uses explicit GCs, so that option will have no effect
on most installs. The effective result of this is that if somebody adds custom
code to Solr and THAT code does an explicit GC, it won't be allowed to function.
Update: Based on the discussion in the JIRA, adding
> Disallow explicit GC by default during Solr startup
> ---
>
> Key: SOLR-13492
> URL: https://issues.apache.org/jira/browse/SOLR-13492
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Major
> Attachments: SOLR-13492.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Solr should use the -XX:+DisableExplicitGC option as part of its default GC
> tuning.
> None of Solr's stock code uses explicit GCs, so that option will have no
> effect on most installs. The effective result of this is that if somebody
> adds custom code to Solr and THAT code does an explicit GC, it won't be
> allowed to function.
>
> Update: Based on the discussion in the JIRA, adding
> {{ExplicitGCInvokesConcurrent}} option instead {{DisableExplicitGC}} so that
> jcmd, jvisualvm could be run
--
This message was sent by Atlassian 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] munendrasn merged pull request #1370: SOLR-13492: Ensure explicit GCs are concurrent by default
munendrasn merged pull request #1370: URL: https://github.com/apache/lucene-solr/pull/1370 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13492) Add ExplicitGCInvokesConcurrent by default during Solr startup
[
https://issues.apache.org/jira/browse/SOLR-13492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127574#comment-17127574
]
ASF subversion and git services commented on SOLR-13492:
Commit aca95a1ec6a28b161e00c377e9929efbd3a9c277 in lucene-solr's branch
refs/heads/master from Guna Sekhar Dora Kovvuru
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=aca95a1 ]
SOLR-13492: perform explicit GC concurrently (#1370)
> Add ExplicitGCInvokesConcurrent by default during Solr startup
> --
>
> Key: SOLR-13492
> URL: https://issues.apache.org/jira/browse/SOLR-13492
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Major
> Attachments: SOLR-13492.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Solr should use the -XX:+DisableExplicitGC option as part of its default GC
> tuning.
> None of Solr's stock code uses explicit GCs, so that option will have no
> effect on most installs. The effective result of this is that if somebody
> adds custom code to Solr and THAT code does an explicit GC, it won't be
> allowed to function.
>
> Update: Based on the discussion in the JIRA, adding
> {{ExplicitGCInvokesConcurrent}} option instead {{DisableExplicitGC}} so that
> jcmd, jvisualvm could be run
--
This message was sent by Atlassian Jira
(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-13492) Add ExplicitGCInvokesConcurrent by default during Solr startup
[
https://issues.apache.org/jira/browse/SOLR-13492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127584#comment-17127584
]
ASF subversion and git services commented on SOLR-13492:
Commit b674d50ae3282641e8f29007b5a288349d8328f6 in lucene-solr's branch
refs/heads/branch_8x from Guna Sekhar Dora Kovvuru
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b674d50 ]
SOLR-13492: perform explicit GC concurrently (#1370)
> Add ExplicitGCInvokesConcurrent by default during Solr startup
> --
>
> Key: SOLR-13492
> URL: https://issues.apache.org/jira/browse/SOLR-13492
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Major
> Attachments: SOLR-13492.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Solr should use the -XX:+DisableExplicitGC option as part of its default GC
> tuning.
> None of Solr's stock code uses explicit GCs, so that option will have no
> effect on most installs. The effective result of this is that if somebody
> adds custom code to Solr and THAT code does an explicit GC, it won't be
> allowed to function.
>
> Update: Based on the discussion in the JIRA, adding
> {{ExplicitGCInvokesConcurrent}} option instead {{DisableExplicitGC}} so that
> jcmd, jvisualvm could be run
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler commented on pull request #1475: LUCENE-9148: Move the BKD index to its own file.
uschindler commented on pull request #1475: URL: https://github.com/apache/lucene-solr/pull/1475#issuecomment-640195438 I think the writer should only be in the test sources like the RWCodec This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13492) Add ExplicitGCInvokesConcurrent by default during Solr startup
[
https://issues.apache.org/jira/browse/SOLR-13492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127585#comment-17127585
]
Munendra S N commented on SOLR-13492:
-
Thanks [~kgsdora]
> Add ExplicitGCInvokesConcurrent by default during Solr startup
> --
>
> Key: SOLR-13492
> URL: https://issues.apache.org/jira/browse/SOLR-13492
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Major
> Attachments: SOLR-13492.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Solr should use the -XX:+DisableExplicitGC option as part of its default GC
> tuning.
> None of Solr's stock code uses explicit GCs, so that option will have no
> effect on most installs. The effective result of this is that if somebody
> adds custom code to Solr and THAT code does an explicit GC, it won't be
> allowed to function.
>
> Update: Based on the discussion in the JIRA, adding
> {{ExplicitGCInvokesConcurrent}} option instead {{DisableExplicitGC}} so that
> jcmd, jvisualvm could be run
--
This message was sent by Atlassian Jira
(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-13492) Add ExplicitGCInvokesConcurrent by default during Solr startup
[
https://issues.apache.org/jira/browse/SOLR-13492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-13492:
Fix Version/s: 8.6
Assignee: Munendra S N (was: Shawn Heisey)
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Add ExplicitGCInvokesConcurrent by default during Solr startup
> --
>
> Key: SOLR-13492
> URL: https://issues.apache.org/jira/browse/SOLR-13492
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Reporter: Shawn Heisey
>Assignee: Munendra S N
>Priority: Major
> Fix For: 8.6
>
> Attachments: SOLR-13492.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Solr should use the -XX:+DisableExplicitGC option as part of its default GC
> tuning.
> None of Solr's stock code uses explicit GCs, so that option will have no
> effect on most installs. The effective result of this is that if somebody
> adds custom code to Solr and THAT code does an explicit GC, it won't be
> allowed to function.
>
> Update: Based on the discussion in the JIRA, adding
> {{ExplicitGCInvokesConcurrent}} option instead {{DisableExplicitGC}} so that
> jcmd, jvisualvm could be run
--
This message was sent by Atlassian Jira
(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-13203) RuntimeException causing a 500 response code for invalid user input
[
https://issues.apache.org/jira/browse/SOLR-13203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-13203:
Status: Patch Available (was: Open)
> RuntimeException causing a 500 response code for invalid user input
> ---
>
> Key: SOLR-13203
> URL: https://issues.apache.org/jira/browse/SOLR-13203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Johannes Kloos
>Priority: Trivial
> Labels: diffblue, newdev
> Attachments: home.zip
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?uf=fl=gen*,id&defType=edismax
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.RuntimeException: dynamic field name must start or end with *
> at
> org.apache.solr.search.ExtendedDismaxQParser$DynamicField.(ExtendedDismaxQParser.java:1610)
> {noformat}
> The DynamicField parser throws this RuntimeException to tell the user that
> the given query is invalid. Sadly, the exception is never caught, so it
> manifests as a 500 error instead of a 400 error.
> We found this issue and ~70 more like this using [Diffblue Microservices
> Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. Find more
> information on this [fuzz testing
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] iverase commented on pull request #1475: LUCENE-9148: Move the BKD index to its own file.
iverase commented on pull request #1475: URL: https://github.com/apache/lucene-solr/pull/1475#issuecomment-640198022 I missed that, it is on the test sources. Thanks for the clarification! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Reopened] (SOLR-14524) Harden MultiThreadedOCPTest
[
https://issues.apache.org/jira/browse/SOLR-14524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reopened SOLR-14524:
---
Saw this one go by today, so reopening...
{color:#00}Build:
{color}[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/26913/]
{color:#00}Java: 64bit/jdk-11.0.6 -XX:-UseCompressedOops
-XX:+UseConcMarkSweepGC{color}
{color:#00}1 tests failed.{color}
{color:#00}FAILED: org.apache.solr.cloud.MultiThreadedOCPTest.test{color}
{color:#00}Error Message:{color}
{color:#00}Long running task finished too early, can't test expected null,
but was:<1591494388303>{color}
{color:#00}Stack Trace:{color}
{color:#00}java.lang.AssertionError: Long running task finished too early,
can't test expected null, but was:<1591494388303>{color}
{color:#00}at
__randomizedtesting.SeedInfo.seed([F72E290521C3A7BB:7F7A16DF8F3FCA43]:0){color}
{color:#00}at org.junit.Assert.fail(Assert.java:88){color}
{color:#00}at org.junit.Assert.failNotNull(Assert.java:755){color}
{color:#00}at org.junit.Assert.assertNull(Assert.java:737){color}
{color:#00}at
org.apache.solr.cloud.MultiThreadedOCPTest.testFillWorkQueue(MultiThreadedOCPTest.java:94){color}
{color:#00}at
org.apache.solr.cloud.MultiThreadedOCPTest.test(MultiThreadedOCPTest.java:67){color}
{color:#00}at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method){color}
{color:#00}at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62){color}
{color:#00}at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){color}
{color:#00}at
java.base/java.lang.reflect.Method.invoke(Method.java:566){color}
{color:#00}at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1754){color}
{color:#00}at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:942){color}
{color:#00}at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:978){color}
{color:#00}at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992){color}
{color:#00}at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1081){color}
{color:#00}at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1053){color}
{color:#00}at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57){color}
{color:#00}at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49){color}
{color:#00}at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45){color}
{color:#00}at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48){color}
{color:#00}at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64){color}
{color:#00}at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47){color}
{color:#00}at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36){color}
{color:#00}at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:370){color}
{color:#00}at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:819){color}
{color:#00}at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:470){color}
{color:#00}at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:951){color}
{color:#00}at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:836){color}
{color:#00}at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:887){color}
{color:#00}at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:898){color}
{color:#00}at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36){color}
{color:#00}at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57){color}
{color:#00}at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45){color}
{color:#00}at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36){color}
{color:#00}at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41){color}
{color:#00}at
[jira] [Commented] (SOLR-14542) Fix or suppress warnings in solr/handler/dataimport
[ https://issues.apache.org/jira/browse/SOLR-14542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127616#comment-17127616 ] ASF subversion and git services commented on SOLR-14542: Commit f96488180cfbd03903f69db077f45420a4199858 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f964881 ] SOLR-14542: Fix or suppress warnings in solr/handler/dataimport > Fix or suppress warnings in solr/handler/dataimport > --- > > Key: SOLR-14542 > URL: https://issues.apache.org/jira/browse/SOLR-14542 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14542) Fix or suppress warnings in solr/handler/dataimport
[ https://issues.apache.org/jira/browse/SOLR-14542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127617#comment-17127617 ] ASF subversion and git services commented on SOLR-14542: Commit 1c49976a002c24bd3270b700f062ddd298449a7f in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1c49976 ] SOLR-14542: Fix or suppress warnings in solr/handler/dataimport > Fix or suppress warnings in solr/handler/dataimport > --- > > Key: SOLR-14542 > URL: https://issues.apache.org/jira/browse/SOLR-14542 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14542) Fix or suppress warnings in solr/handler/dataimport
[ https://issues.apache.org/jira/browse/SOLR-14542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14542. --- Fix Version/s: 8.6 Resolution: Fixed > Fix or suppress warnings in solr/handler/dataimport > --- > > Key: SOLR-14542 > URL: https://issues.apache.org/jira/browse/SOLR-14542 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.6 > > -- This message was sent by Atlassian Jira (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-13203) RuntimeException causing a 500 response code for invalid user input
[
https://issues.apache.org/jira/browse/SOLR-13203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127618#comment-17127618
]
ASF subversion and git services commented on SOLR-13203:
Commit 291e358a3d7823082316bd0fa63642b9900adf27 in lucene-solr's branch
refs/heads/master from mrsoong
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=291e358 ]
SOLR-13203: return 400 on invalid dynamic field for edismax uf (#1502)
> RuntimeException causing a 500 response code for invalid user input
> ---
>
> Key: SOLR-13203
> URL: https://issues.apache.org/jira/browse/SOLR-13203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Johannes Kloos
>Priority: Trivial
> Labels: diffblue, newdev
> Attachments: home.zip
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?uf=fl=gen*,id&defType=edismax
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.RuntimeException: dynamic field name must start or end with *
> at
> org.apache.solr.search.ExtendedDismaxQParser$DynamicField.(ExtendedDismaxQParser.java:1610)
> {noformat}
> The DynamicField parser throws this RuntimeException to tell the user that
> the given query is invalid. Sadly, the exception is never caught, so it
> manifests as a 500 error instead of a 400 error.
> We found this issue and ~70 more like this using [Diffblue Microservices
> Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. Find more
> information on this [fuzz testing
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].
--
This message was sent by Atlassian 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] munendrasn merged pull request #1502: SOLR-13203: Added 400 status code to exception in DynamicField
munendrasn merged pull request #1502: URL: https://github.com/apache/lucene-solr/pull/1502 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] munendrasn commented on pull request #1502: SOLR-13203: Added 400 status code to exception in DynamicField
munendrasn commented on pull request #1502: URL: https://github.com/apache/lucene-solr/pull/1502#issuecomment-640209147 @mrsoong Thanks for the contribution. I have included your GitHub username in the changes.txt. Let me know if that needs to be modified This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13203) RuntimeException causing a 500 response code for invalid user input
[
https://issues.apache.org/jira/browse/SOLR-13203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127619#comment-17127619
]
ASF subversion and git services commented on SOLR-13203:
Commit ef0309553a32c124cef0a67b962ef0b1ce0091b7 in lucene-solr's branch
refs/heads/branch_8x from mrsoong
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ef03095 ]
SOLR-13203: return 400 on invalid dynamic field for edismax uf (#1502)
> RuntimeException causing a 500 response code for invalid user input
> ---
>
> Key: SOLR-13203
> URL: https://issues.apache.org/jira/browse/SOLR-13203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Johannes Kloos
>Priority: Trivial
> Labels: diffblue, newdev
> Attachments: home.zip
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?uf=fl=gen*,id&defType=edismax
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.RuntimeException: dynamic field name must start or end with *
> at
> org.apache.solr.search.ExtendedDismaxQParser$DynamicField.(ExtendedDismaxQParser.java:1610)
> {noformat}
> The DynamicField parser throws this RuntimeException to tell the user that
> the given query is invalid. Sadly, the exception is never caught, so it
> manifests as a 500 error instead of a 400 error.
> We found this issue and ~70 more like this using [Diffblue Microservices
> Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. Find more
> information on this [fuzz testing
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].
--
This message was sent by Atlassian 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] ErickErickson closed pull request #1509: SOLR-10810: Examine precommit lint WARNINGs in non-test code
ErickErickson closed pull request #1509: URL: https://github.com/apache/lucene-solr/pull/1509 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson commented on pull request #1509: SOLR-10810: Examine precommit lint WARNINGs in non-test code
ErickErickson commented on pull request #1509: URL: https://github.com/apache/lucene-solr/pull/1509#issuecomment-640209358 This has being handled in SOLR-10778 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13203) RuntimeException causing a 500 response code for invalid user input
[
https://issues.apache.org/jira/browse/SOLR-13203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-13203:
Fix Version/s: 8.6
Assignee: Munendra S N
Resolution: Fixed
Status: Resolved (was: Patch Available)
> RuntimeException causing a 500 response code for invalid user input
> ---
>
> Key: SOLR-13203
> URL: https://issues.apache.org/jira/browse/SOLR-13203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Johannes Kloos
>Assignee: Munendra S N
>Priority: Trivial
> Labels: diffblue, newdev
> Fix For: 8.6
>
> Attachments: home.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?uf=fl=gen*,id&defType=edismax
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.RuntimeException: dynamic field name must start or end with *
> at
> org.apache.solr.search.ExtendedDismaxQParser$DynamicField.(ExtendedDismaxQParser.java:1610)
> {noformat}
> The DynamicField parser throws this RuntimeException to tell the user that
> the given query is invalid. Sadly, the exception is never caught, so it
> manifests as a 500 error instead of a 400 error.
> We found this issue and ~70 more like this using [Diffblue Microservices
> Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. Find more
> information on this [fuzz testing
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].
--
This message was sent by Atlassian 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] munendrasn commented on pull request #922: SOLR-13793: limit number of remote queries to number of shard replicas
munendrasn commented on pull request #922: URL: https://github.com/apache/lucene-solr/pull/922#issuecomment-640211222 This is released with 8.3 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] munendrasn closed pull request #922: SOLR-13793: limit number of remote queries to number of shard replicas
munendrasn closed pull request #922: URL: https://github.com/apache/lucene-solr/pull/922 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14345) Error messages are not properly propagated with non-default response parsers
[
https://issues.apache.org/jira/browse/SOLR-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127685#comment-17127685
]
Lucene/Solr QA commented on SOLR-14345:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
26s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 3s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 45m
29s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m
46s{color} | {color:green} solrj in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
14s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 55m 12s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14345 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13005022/SOLR-14345.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 291e358a3d7 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/761/testReport/ |
| modules | C: solr/core solr/solrj solr/test-framework U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/761/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Error messages are not properly propagated with non-default response parsers
>
>
> Key: SOLR-14345
> URL: https://issues.apache.org/jira/browse/SOLR-14345
> Project: Solr
> Issue Type: Bug
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-14345.patch, SOLR-14345.patch, SOLR-14345.patch,
> SOLR-14345.patch, SOLR-14345.patch
>
>
> Default {{ResponsParseer}} is {{BinaryResponseParser}}. when non-default
> response parser is specified in the request then, the error message is
> propagated to user. This happens in solrCloud mode.
> I came across this problem when working on adding some test which uses
> {{SolrTestCaseHS}} but similar problem exists with SolrJ client
> Also, same problem exists in both HttpSolrClient and Http2SolrClient
--
This message was sent by Atlassian Jira
(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-14524) Harden MultiThreadedOCPTest
[
https://issues.apache.org/jira/browse/SOLR-14524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127696#comment-17127696
]
Ilan Ginzburg commented on SOLR-14524:
--
I am actively looking at this (week-end permitting). Here are my notes so far,
to be considered WIP.
Looking at the logs from the test
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/26896/consoleFull]
(run 26913 is similar)
The long running task is added at timestamp 281488 (log "{{MOCK task added
2}}").
The first task (id 0, fast one) got added 6ms earlier at 281482 and we see it
getting processed at 281498. Total time from enqueue to finished processing is
16ms.
Interestingly, the long running task 2 gets executed BEFORE task 1 get executed
even though task 1 was enqueued before it. Task 2 completed execution at
291532, which is 10 seconds and 44ms after it got enqueued. This makes sense:
its processing duration was set to 10 seconds and task 0 shows that dequeuing
by the {{OverseerCollectionMessageHandler}} is quick.
+The surprising bit now+: at 291603 (i.e. after task 2 completed), task 1
completes. Logs from {{OverseerCollectionMessageHandler}} show it got processed
by the same thread that first processed task 2.
The test is failing for a simple reason: it waits for task 1 to complete before
proceeding, but then verifies that task 2 hasn't completed yet to make sure
it's possible to test how task 2 is scheduled compared to another task then
enqueued for another collection.
The real question therefore is: why does {{OverseerCollectionMessageHandler}}
process (or appears to process) messages on the same collection out of order?
This is not expected.
> Harden MultiThreadedOCPTest
> ---
>
> Key: SOLR-14524
> URL: https://issues.apache.org/jira/browse/SOLR-14524
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Ilan Ginzburg
>Assignee: Mike Drob
>Priority: Minor
> Labels: test
> Fix For: master (9.0)
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{MultiThreadedOCPTest.test()}} fails occasionally in Jenkins because of
> timing of tasks enqueue to the Collection API queue.
> This test in {{testFillWorkQueue()}} enqueues a large number of tasks (115,
> more than the 100 Collection API parallel executors) to the Collection API
> queue for a collection COLL_A, then observes a short delay and enqueues a
> task for another collection COLL_B.
> It verifies that the COLL_B task (that does not require the same lock as the
> COLL_A tasks) completes before the third COLL_A task.
> Test failures happen because when enqueues are slowed down enough, the first
> 3 tasks on COLL_A complete even before the COLL_B task gets enqueued!
> In one sample failed Jenkins test execution, the COLL_B task enqueue happened
> 1275ms after the enqueue of the first COLL_A, leaving plenty of time for a
> few (and possibly all) COLL_A tasks to complete.
> Fix will be along the lines of:
> * Make the “blocking” COLL_A task longer to execute (currently 1 second) to
> compensate for slow enqueues.
> * Verify the COLL_B task (a 1ms task) finishes before the long running
> COLL_A task does. This would be a good indication that even though the
> collection queue was filled with tasks waiting for a busy lock, a non
> competing task was picked and executed right away.
> * Delay the enqueue of the COLL_B task to the end of processing of the first
> COLL_A task. This would guarantee that COLL_B is enqueued once at least some
> COLL_A tasks started processing at the Overseer. Possibly also verify that
> the long running task of COLL_A didn't finish execution yet when the COLL_B
> task is enqueued...
> * It might be possible to set a (very) long duration for the slow task of
> COLL_A (to be less vulnerable to execution delays) without requiring the test
> to wait for that task to complete, but only wait for the COLL_B task to
> complete (so the test doesn't run for too long).
--
This message was sent by Atlassian Jira
(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-13169) Move Replica Docs need improvement (V1 and V2 introspect)
[
https://issues.apache.org/jira/browse/SOLR-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127704#comment-17127704
]
ASF subversion and git services commented on SOLR-13169:
Commit 12280819a179d622d83d1c6e483832eadef33a26 in lucene-solr's branch
refs/heads/master from Gus Heck
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1228081 ]
SOLR-13169 Improve docs for MOVEREPLICA - Warn that maxShardsPerNode is ignored,
better detail on when some parameters are ignored
> Move Replica Docs need improvement (V1 and V2 introspect)
> -
>
> Key: SOLR-13169
> URL: https://issues.apache.org/jira/browse/SOLR-13169
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
>Reporter: Gus Heck
>Priority: Major
> Attachments: screenshot-1.png, testing.txt
>
>
> At a minimum required parameters should be noted equally in both places.
> Conversation with [~ab] indicates that there are also some discrepancies in
> what is and is not actually required in docs vs code. ("in MoveReplicaCmd if
> you specify “replica” then “shard” is completely ignored")
> Also in v2 it seems shard might be inferred from the URL and in that case
> it's not clear if the URL or the json takes precedence.
> From introspect:
> {code:java}
> "move-replica": {
> "type": "object",
> "documentation":
> "https://lucene.apache.org/solr/guide/collections-api.html#movereplica";,
> "description": "This command moves a replica from one
> node to a new node. In case of shared filesystems the `dataDir` and `ulogDir`
> may be reused.",
> "properties": {
> "replica": {
> "type": "string",
> "description": "The name of the replica"
> },
> "shard": {
> "type": "string",
> "description": "The name of the shard"
> },
> "sourceNode": {
> "type": "string",
> "description": "The name of the node that
> contains the replica."
> },
> "targetNode": {
> "type": "string",
> "description": "The name of the destination node.
> This parameter is required."
> },
> "waitForFinalState": {
> "type": "boolean",
> "default": "false",
> "description": "Wait for the moved replica to
> become active."
> },
> "timeout": {
> "type": "integer",
> "default": 600,
> "description": "Timeout to wait for replica to
> become active. For very large replicas this may need to be increased."
> },
> "inPlaceMove": {
> "type": "boolean",
> "default": "true",
> "description": "For replicas that use shared
> filesystems allow 'in-place' move that reuses shared data."
> }
> {code}
> From ref guide for V1:
> MOVEREPLICA Parameters
> collection
> The name of the collection. This parameter is required.
> shard
> The name of the shard that the replica belongs to. This parameter is required.
> replica
> The name of the replica. This parameter is required.
> sourceNode
> The name of the node that contains the replica. This parameter is required.
> targetNode
> The name of the destination node. This parameter is required.
> async
> Request ID to track this action which will be processed asynchronously.
--
This message was sent by Atlassian Jira
(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-14532) Add iml file to gitignore
[
https://issues.apache.org/jira/browse/SOLR-14532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127724#comment-17127724
]
Erick Erickson commented on SOLR-14532:
---
Perhaps just add a note to helpAnt? The file is ./help/ant.txt. I'm thinking of
something like:
ant idea => gradlew idea [better: open the project in IntelliJ, the project
will build automatically]
> Add iml file to gitignore
> -
>
> Key: SOLR-14532
> URL: https://issues.apache.org/jira/browse/SOLR-14532
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andras Salamon
>Priority: Trivial
> Attachments: SOLR-14532.patch
>
>
> If I execute {{gradlew idea}} in my {{lucene-solr-upstream}} directory, it
> will create three files in the root directory:
> {noformat}
> lucene-solr-upstream.iml
> lucene-solr-upstream.ipr
> lucene-solr-upstream.iws
> {noformat}
> Git will ignore the {{ipr}} and the {{iws}} file, but it lists the iml file
> as a new file. We should also ignore that one.
--
This message was sent by Atlassian Jira
(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-14544) Fix or suppress warnings in solr/client/solrj/io/eval
Erick Erickson created SOLR-14544: - Summary: Fix or suppress warnings in solr/client/solrj/io/eval Key: SOLR-14544 URL: https://issues.apache.org/jira/browse/SOLR-14544 Project: Solr Issue Type: Sub-task Reporter: Erick Erickson Assignee: Erick Erickson -- This message was sent by Atlassian Jira (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-14532) Add iml file to gitignore
[
https://issues.apache.org/jira/browse/SOLR-14532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127732#comment-17127732
]
Jason Gerlowski commented on SOLR-14532:
I'm happy to bundle that in too here if we want.
Curious - does doing a normal IntelliJ import bring in everything that running
"gradlew idea" would? Including code-formatter settings and everything? (Do we
have code-formatter settings for IntelliJ? I guess I was assuming we did)
That'd be awesome.
In any case, I'll come back through and commit the gitignore and help-text
change tomorrow.
> Add iml file to gitignore
> -
>
> Key: SOLR-14532
> URL: https://issues.apache.org/jira/browse/SOLR-14532
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andras Salamon
>Priority: Trivial
> Attachments: SOLR-14532.patch
>
>
> If I execute {{gradlew idea}} in my {{lucene-solr-upstream}} directory, it
> will create three files in the root directory:
> {noformat}
> lucene-solr-upstream.iml
> lucene-solr-upstream.ipr
> lucene-solr-upstream.iws
> {noformat}
> Git will ignore the {{ipr}} and the {{iws}} file, but it lists the iml file
> as a new file. We should also ignore that one.
--
This message was sent by Atlassian Jira
(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-14532) Add iml file to gitignore
[
https://issues.apache.org/jira/browse/SOLR-14532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127750#comment-17127750
]
Dawid Weiss commented on SOLR-14532:
No code formatter settings are automatically set up, you need to do it manually
for now.
> Add iml file to gitignore
> -
>
> Key: SOLR-14532
> URL: https://issues.apache.org/jira/browse/SOLR-14532
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andras Salamon
>Priority: Trivial
> Attachments: SOLR-14532.patch
>
>
> If I execute {{gradlew idea}} in my {{lucene-solr-upstream}} directory, it
> will create three files in the root directory:
> {noformat}
> lucene-solr-upstream.iml
> lucene-solr-upstream.ipr
> lucene-solr-upstream.iws
> {noformat}
> Git will ignore the {{ipr}} and the {{iws}} file, but it lists the iml file
> as a new file. We should also ignore that one.
--
This message was sent by Atlassian Jira
(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-14524) Harden MultiThreadedOCPTest
[
https://issues.apache.org/jira/browse/SOLR-14524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127786#comment-17127786
]
Ilan Ginzburg commented on SOLR-14524:
--
I was able to reproduce the issue locally. There is most likely an actual issue
impacting dequeue order (and correctness - I suspect lost messages) in the
{{OverseerCollectionMessageHandler}}, this doesn't seem to be a test issue.
Will file a Jira tomorrow.
> Harden MultiThreadedOCPTest
> ---
>
> Key: SOLR-14524
> URL: https://issues.apache.org/jira/browse/SOLR-14524
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Ilan Ginzburg
>Assignee: Mike Drob
>Priority: Minor
> Labels: test
> Fix For: master (9.0)
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{MultiThreadedOCPTest.test()}} fails occasionally in Jenkins because of
> timing of tasks enqueue to the Collection API queue.
> This test in {{testFillWorkQueue()}} enqueues a large number of tasks (115,
> more than the 100 Collection API parallel executors) to the Collection API
> queue for a collection COLL_A, then observes a short delay and enqueues a
> task for another collection COLL_B.
> It verifies that the COLL_B task (that does not require the same lock as the
> COLL_A tasks) completes before the third COLL_A task.
> Test failures happen because when enqueues are slowed down enough, the first
> 3 tasks on COLL_A complete even before the COLL_B task gets enqueued!
> In one sample failed Jenkins test execution, the COLL_B task enqueue happened
> 1275ms after the enqueue of the first COLL_A, leaving plenty of time for a
> few (and possibly all) COLL_A tasks to complete.
> Fix will be along the lines of:
> * Make the “blocking” COLL_A task longer to execute (currently 1 second) to
> compensate for slow enqueues.
> * Verify the COLL_B task (a 1ms task) finishes before the long running
> COLL_A task does. This would be a good indication that even though the
> collection queue was filled with tasks waiting for a busy lock, a non
> competing task was picked and executed right away.
> * Delay the enqueue of the COLL_B task to the end of processing of the first
> COLL_A task. This would guarantee that COLL_B is enqueued once at least some
> COLL_A tasks started processing at the Overseer. Possibly also verify that
> the long running task of COLL_A didn't finish execution yet when the COLL_B
> task is enqueued...
> * It might be possible to set a (very) long duration for the slow task of
> COLL_A (to be less vulnerable to execution delays) without requiring the test
> to wait for that task to complete, but only wait for the COLL_B task to
> complete (so the test doesn't run for too long).
--
This message was sent by Atlassian 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 merged pull request #1403: SOLR-9679: Exception when removing zk node /security.json
janhoy merged pull request #1403: URL: https://github.com/apache/lucene-solr/pull/1403 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9679) Exception when removing zk node /security.json
[
https://issues.apache.org/jira/browse/SOLR-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127797#comment-17127797
]
ASF subversion and git services commented on SOLR-9679:
---
Commit f404a38fa6d508b9dad78ce7d38e2a9cd6bf2ed1 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f404a38 ]
SOLR-9679: Exception when removing zk node /security.json (#1403)
> Exception when removing zk node /security.json
> --
>
> Key: SOLR-9679
> URL: https://issues.apache.org/jira/browse/SOLR-9679
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> To reproduce:
> # Upload {{security.json}} to zk
> # {{bin/solr zk rm zk:/security.json -z localhost:9983}}
> {noformat}
> 2016-10-22 22:17:32.264 DEBUG (main-EventThread) [ ] o.a.s.c.c.SolrZkClient
> Submitting job to respond to event WatchedEvent state:SyncConnected
> type:NodeDeleted path:/security.json
> 2016-10-22 22:17:32.265 DEBUG
> (zkCallback-3-thread-1-processing-n:192.168.0.11:8983_solr) [ ]
> o.a.s.c.c.ZkStateReader Updating [/security.json] ...
> 2016-10-22 22:17:32.266 ERROR
> (zkCallback-3-thread-1-processing-n:192.168.0.11:8983_solr) [ ]
> o.a.s.c.c.ZkStateReader A ZK error has occurred
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /security.json
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155)
> at
> org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:356)
> at
> org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:353)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at
> org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:353)
> at
> org.apache.solr.common.cloud.ZkStateReader$3.process(ZkStateReader.java:455)
> at
> org.apache.solr.common.cloud.SolrZkClient$3.lambda$process$0(SolrZkClient.java:268)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I'm not sure what should happen, but it would be sweet to be able to disable
> security by simply removing the znode... [~noble.paul] ?
--
This message was sent by Atlassian Jira
(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-9679) Exception when removing zk node /security.json
[
https://issues.apache.org/jira/browse/SOLR-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127799#comment-17127799
]
ASF subversion and git services commented on SOLR-9679:
---
Commit 0ff0c45b981cd723d046420d80753d975b9b1965 in lucene-solr's branch
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0ff0c45 ]
SOLR-9679: Exception when removing zk node /security.json (#1403)
(cherry picked from commit f404a38fa6d508b9dad78ce7d38e2a9cd6bf2ed1)
> Exception when removing zk node /security.json
> --
>
> Key: SOLR-9679
> URL: https://issues.apache.org/jira/browse/SOLR-9679
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> To reproduce:
> # Upload {{security.json}} to zk
> # {{bin/solr zk rm zk:/security.json -z localhost:9983}}
> {noformat}
> 2016-10-22 22:17:32.264 DEBUG (main-EventThread) [ ] o.a.s.c.c.SolrZkClient
> Submitting job to respond to event WatchedEvent state:SyncConnected
> type:NodeDeleted path:/security.json
> 2016-10-22 22:17:32.265 DEBUG
> (zkCallback-3-thread-1-processing-n:192.168.0.11:8983_solr) [ ]
> o.a.s.c.c.ZkStateReader Updating [/security.json] ...
> 2016-10-22 22:17:32.266 ERROR
> (zkCallback-3-thread-1-processing-n:192.168.0.11:8983_solr) [ ]
> o.a.s.c.c.ZkStateReader A ZK error has occurred
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /security.json
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155)
> at
> org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:356)
> at
> org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:353)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at
> org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:353)
> at
> org.apache.solr.common.cloud.ZkStateReader$3.process(ZkStateReader.java:455)
> at
> org.apache.solr.common.cloud.SolrZkClient$3.lambda$process$0(SolrZkClient.java:268)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I'm not sure what should happen, but it would be sweet to be able to disable
> security by simply removing the znode... [~noble.paul] ?
--
This message was sent by Atlassian Jira
(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-9679) Exception when removing zk node /security.json
[
https://issues.apache.org/jira/browse/SOLR-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-9679.
---
Resolution: Fixed
> Exception when removing zk node /security.json
> --
>
> Key: SOLR-9679
> URL: https://issues.apache.org/jira/browse/SOLR-9679
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> To reproduce:
> # Upload {{security.json}} to zk
> # {{bin/solr zk rm zk:/security.json -z localhost:9983}}
> {noformat}
> 2016-10-22 22:17:32.264 DEBUG (main-EventThread) [ ] o.a.s.c.c.SolrZkClient
> Submitting job to respond to event WatchedEvent state:SyncConnected
> type:NodeDeleted path:/security.json
> 2016-10-22 22:17:32.265 DEBUG
> (zkCallback-3-thread-1-processing-n:192.168.0.11:8983_solr) [ ]
> o.a.s.c.c.ZkStateReader Updating [/security.json] ...
> 2016-10-22 22:17:32.266 ERROR
> (zkCallback-3-thread-1-processing-n:192.168.0.11:8983_solr) [ ]
> o.a.s.c.c.ZkStateReader A ZK error has occurred
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /security.json
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155)
> at
> org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:356)
> at
> org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:353)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at
> org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:353)
> at
> org.apache.solr.common.cloud.ZkStateReader$3.process(ZkStateReader.java:455)
> at
> org.apache.solr.common.cloud.SolrZkClient$3.lambda$process$0(SolrZkClient.java:268)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I'm not sure what should happen, but it would be sweet to be able to disable
> security by simply removing the znode... [~noble.paul] ?
--
This message was sent by Atlassian Jira
(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-9679) Exception when removing zk node /security.json
[
https://issues.apache.org/jira/browse/SOLR-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-9679:
--
Fix Version/s: 8.6
> Exception when removing zk node /security.json
> --
>
> Key: SOLR-9679
> URL: https://issues.apache.org/jira/browse/SOLR-9679
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> To reproduce:
> # Upload {{security.json}} to zk
> # {{bin/solr zk rm zk:/security.json -z localhost:9983}}
> {noformat}
> 2016-10-22 22:17:32.264 DEBUG (main-EventThread) [ ] o.a.s.c.c.SolrZkClient
> Submitting job to respond to event WatchedEvent state:SyncConnected
> type:NodeDeleted path:/security.json
> 2016-10-22 22:17:32.265 DEBUG
> (zkCallback-3-thread-1-processing-n:192.168.0.11:8983_solr) [ ]
> o.a.s.c.c.ZkStateReader Updating [/security.json] ...
> 2016-10-22 22:17:32.266 ERROR
> (zkCallback-3-thread-1-processing-n:192.168.0.11:8983_solr) [ ]
> o.a.s.c.c.ZkStateReader A ZK error has occurred
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /security.json
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155)
> at
> org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:356)
> at
> org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:353)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at
> org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:353)
> at
> org.apache.solr.common.cloud.ZkStateReader$3.process(ZkStateReader.java:455)
> at
> org.apache.solr.common.cloud.SolrZkClient$3.lambda$process$0(SolrZkClient.java:268)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I'm not sure what should happen, but it would be sweet to be able to disable
> security by simply removing the znode... [~noble.paul] ?
--
This message was sent by Atlassian Jira
(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-14543) Fix or suppress warnings in apache/solr/search
[ https://issues.apache.org/jira/browse/SOLR-14543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127818#comment-17127818 ] ASF subversion and git services commented on SOLR-14543: Commit 04ba04c29d5079d74231aa5a54d5f0a93bd16f2b in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=04ba04c ] SOLR-14543: Fix or suppress warnings in apache/solr/search > Fix or suppress warnings in apache/solr/search > -- > > Key: SOLR-14543 > URL: https://issues.apache.org/jira/browse/SOLR-14543 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14543) Fix or suppress warnings in apache/solr/search
[ https://issues.apache.org/jira/browse/SOLR-14543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127819#comment-17127819 ] ASF subversion and git services commented on SOLR-14543: Commit d1fd4bda3a4bcc9be278f353165202aaca615801 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d1fd4bd ] SOLR-14543: Fix or suppress warnings in apache/solr/search > Fix or suppress warnings in apache/solr/search > -- > > Key: SOLR-14543 > URL: https://issues.apache.org/jira/browse/SOLR-14543 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14544) Fix or suppress warnings in solr/client/solrj/io/eval
[ https://issues.apache.org/jira/browse/SOLR-14544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127822#comment-17127822 ] ASF subversion and git services commented on SOLR-14544: Commit 7bf59a16bda85b19b68b639b395d143019a89fde in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7bf59a1 ] SOLR-14544: Fix or suppress warnings in solr/client/solrj/io/eval > Fix or suppress warnings in solr/client/solrj/io/eval > - > > Key: SOLR-14544 > URL: https://issues.apache.org/jira/browse/SOLR-14544 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14544) Fix or suppress warnings in solr/client/solrj/io/eval
[ https://issues.apache.org/jira/browse/SOLR-14544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127823#comment-17127823 ] ASF subversion and git services commented on SOLR-14544: Commit b804cb4531b9b82d1395c7faea22d67db518e55a in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b804cb4 ] SOLR-14544: Fix or suppress warnings in solr/client/solrj/io/eval > Fix or suppress warnings in solr/client/solrj/io/eval > - > > Key: SOLR-14544 > URL: https://issues.apache.org/jira/browse/SOLR-14544 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14544) Fix or suppress warnings in solr/client/solrj/io/eval
[ https://issues.apache.org/jira/browse/SOLR-14544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14544. --- Fix Version/s: 8.6 Resolution: Fixed > Fix or suppress warnings in solr/client/solrj/io/eval > - > > Key: SOLR-14544 > URL: https://issues.apache.org/jira/browse/SOLR-14544 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.6 > > -- This message was sent by Atlassian Jira (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-14543) Fix or suppress warnings in apache/solr/search
[ https://issues.apache.org/jira/browse/SOLR-14543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14543. --- Fix Version/s: 8.6 Resolution: Fixed > Fix or suppress warnings in apache/solr/search > -- > > Key: SOLR-14543 > URL: https://issues.apache.org/jira/browse/SOLR-14543 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.6 > > -- This message was sent by Atlassian Jira (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-14545) Fix or suppress warnings in apache/solr/update
Erick Erickson created SOLR-14545: - Summary: Fix or suppress warnings in apache/solr/update Key: SOLR-14545 URL: https://issues.apache.org/jira/browse/SOLR-14545 Project: Solr Issue Type: Sub-task Reporter: Erick Erickson Assignee: Erick Erickson -- This message was sent by Atlassian Jira (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-9390) Kuromoji tokenizer discards tokens if they start with a punctuation character
[ https://issues.apache.org/jira/browse/LUCENE-9390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127839#comment-17127839 ] Jun Ohtani commented on LUCENE-9390: Not exactly related, but we discussed around discard punctuation flag in https://issues.apache.org/jira/browse/SOLR-3524 > Kuromoji tokenizer discards tokens if they start with a punctuation character > - > > Key: LUCENE-9390 > URL: https://issues.apache.org/jira/browse/LUCENE-9390 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Minor > > This issue was first raised in Elasticsearch > [here|https://github.com/elastic/elasticsearch/issues/57614] > The unidic dictionary that is used by the Kuromoji tokenizer contains entries > that mix punctuations and other characters. For instance the following entry: > _（株）,1285,1285,3690,名詞,一般,*,*,*,*,（株）,カブシキガイシャ,カブシキガイシャ_ > can be found in the Noun.csv file. > Today, tokens that start with punctuations are automatically removed by > default (discardPunctuation is true). I think the code was written this way > because we expect punctuations to be separated from normal tokens but there > are exceptions in the original dictionary. Maybe we should check the entire > token when discarding punctuations ? > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
