[jira] [Resolved] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true

[Shalin Shekhar Mangar (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shalin Shekhar Mangar resolved SOLR-13649.
--
Resolution: Fixed

Thanks Marcus and Jan for all the work!

> BasicAuth's 'blockUnknown' param should default to true
> ---
>
> Key: SOLR-13649
> URL: https://issues.apache.org/jira/browse/SOLR-13649
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI, Authentication, security
>Affects Versions: 7.7.2, 8.1.1
> Environment: All
>Reporter: Marcus Eagan
>Assignee: Shalin Shekhar Mangar
>Priority: Major
>  Labels: Authentication
> Fix For: master (9.0)
>
>  Time Spent: 9h 10m
>  Remaining Estimate: 0h
>
> If someone seeks to enable basic authentication but they do not specify the 
> {{blockUnknown}} parameter, the default value is {{false}}. That default 
> behavior is a bit counterintuitive because if someone wishes to enable basic 
> authentication, you would expect that they would want all unknown users to 
> need to authenticate by default. I can imagine cases where you would not, but 
> those cases would be less frequent.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13718) SPLITSHARD using async can cause data loss

[Ishan Chattopadhyaya (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ishan Chattopadhyaya updated SOLR-13718:

Description: 
When using SPLITSHARD with async, if there are underlying failures in the SPLIT 
core command or other sub-commands of SPLITSHARD, then SPLITSHARD succeeds and 
results in two empty sub-shards.

There are various potential failures with SPLIT core command, here's a way to 
reproduce using a Solr 6x index in Solr 7x.

-Steps to reproduce (in Solr 7x):-
{code}
1. Import the attached configset, and create a collection.
2. Move in the attached data directory (index created in Solr6x) in place of 
the created collection's data directory. Do a collection RELOAD.
3. Issue a *:* query, we see 5 documents.
4. Issue a SPLITSHARD (async), and then issue *:*, we see 0 documents.
{code}

Check attached solr-13718-reproduce.sh script to do the same (without needing 
the zip file).

  was:
When using SPLITSHARD with async, if there are underlying failures in the SPLIT 
core command or other sub-commands of SPLITSHARD, then SPLITSHARD succeeds and 
results in two empty sub-shards.

There are various potential failures with SPLIT core command, here's a way to 
reproduce using a Solr 6x index in Solr 7x.

-Steps to reproduce (in Solr 7x):-
{code}
1. Import the attached configset, and create a collection.
2. Move in the attached data directory (index created in Solr6x) in place of 
the created collection's data directory. Do a collection RELOAD.
3. Issue a *:* query, we see 5 documents.
4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
{code}

Check attached solr-13718-reproduce.sh script to do the same (without needing 
the zip file).


> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7.2, 8.1, 8.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.7.3, 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the 
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD 
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to 
> reproduce using a Solr 6x index in Solr 7x.
> -Steps to reproduce (in Solr 7x):-
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of 
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD (async), and then issue *:*, we see 0 documents.
> {code}
> Check attached solr-13718-reproduce.sh script to do the same (without needing 
> the zip file).



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13718) SPLITSHARD using async can cause data loss

[Ishan Chattopadhyaya (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ishan Chattopadhyaya updated SOLR-13718:

Description: 
When using SPLITSHARD with async, if there are underlying failures in the SPLIT 
core command or other sub-commands of SPLITSHARD, then SPLITSHARD succeeds and 
results in two empty sub-shards.

There are various potential failures with SPLIT core command, here's a way to 
reproduce using a Solr 6x index in Solr 7x.

-Steps to reproduce (in Solr 7x):-
{code}
1. Import the attached configset, and create a collection.
2. Move in the attached data directory (index created in Solr6x) in place of 
the created collection's data directory. Do a collection RELOAD.
3. Issue a *:* query, we see 5 documents.
4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
{code}

Check attached solr-13718-reproduce.sh script to do the same (without needing 
the zip file).

  was:
When using SPLITSHARD with async, if there are underlying failures in the SPLIT 
core command or other sub-commands of SPLITSHARD, then SPLITSHARD succeeds and 
results in two empty sub-shards.

There are various potential failures with SPLIT core command, here's a way to 
reproduce using a Solr 6x index in Solr 7x.

-Steps to reproduce (in Solr 7x):-
{code}
1. Import the attached configset, and create a collection.
2. Move in the attached data directory (index created in Solr6x) in place of 
the created collection's data directory. Do a collection RELOAD.
3. Issue a *:* query, we see 5 documents.
4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
{code}

Check 


> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7.2, 8.1, 8.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.7.3, 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the 
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD 
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to 
> reproduce using a Solr 6x index in Solr 7x.
> -Steps to reproduce (in Solr 7x):-
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of 
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
> {code}
> Check attached solr-13718-reproduce.sh script to do the same (without needing 
> the zip file).



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918293#comment-16918293
 ] 

ASF subversion and git services commented on SOLR-13649:


Commit b37d92bfee63a9ede2a754347cbe8627dedade33 in lucene-solr's branch 
refs/heads/master from Marcus
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b37d92b ]

SOLR-13649 change the default behavior of the basic authentication plugin. 
(#805)

SOLR-13649: Property 'blockUnknown' of BasicAuthPlugin and JWTAuthPlugin now 
defaults to 'true'. This change is backward incompatible. To achieve the 
previous default behavior, explicitly set 'blockUnknown':'false' in 
security.json

> BasicAuth's 'blockUnknown' param should default to true
> ---
>
> Key: SOLR-13649
> URL: https://issues.apache.org/jira/browse/SOLR-13649
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI, Authentication, security
>Affects Versions: 7.7.2, 8.1.1
> Environment: All
>Reporter: Marcus Eagan
>Assignee: Shalin Shekhar Mangar
>Priority: Major
>  Labels: Authentication
> Fix For: master (9.0)
>
>  Time Spent: 9h 10m
>  Remaining Estimate: 0h
>
> If someone seeks to enable basic authentication but they do not specify the 
> {{blockUnknown}} parameter, the default value is {{false}}. That default 
> behavior is a bit counterintuitive because if someone wishes to enable basic 
> authentication, you would expect that they would want all unknown users to 
> need to authenticate by default. I can imagine cases where you would not, but 
> those cases would be less frequent.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918294#comment-16918294
 ] 

ASF subversion and git services commented on SOLR-13649:


Commit b37d92bfee63a9ede2a754347cbe8627dedade33 in lucene-solr's branch 
refs/heads/master from Marcus
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b37d92b ]

SOLR-13649 change the default behavior of the basic authentication plugin. 
(#805)

SOLR-13649: Property 'blockUnknown' of BasicAuthPlugin and JWTAuthPlugin now 
defaults to 'true'. This change is backward incompatible. To achieve the 
previous default behavior, explicitly set 'blockUnknown':'false' in 
security.json

> BasicAuth's 'blockUnknown' param should default to true
> ---
>
> Key: SOLR-13649
> URL: https://issues.apache.org/jira/browse/SOLR-13649
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI, Authentication, security
>Affects Versions: 7.7.2, 8.1.1
> Environment: All
>Reporter: Marcus Eagan
>Assignee: Shalin Shekhar Mangar
>Priority: Major
>  Labels: Authentication
> Fix For: master (9.0)
>
>  Time Spent: 9h 10m
>  Remaining Estimate: 0h
>
> If someone seeks to enable basic authentication but they do not specify the 
> {{blockUnknown}} parameter, the default value is {{false}}. That default 
> behavior is a bit counterintuitive because if someone wishes to enable basic 
> authentication, you would expect that they would want all unknown users to 
> need to authenticate by default. I can imagine cases where you would not, but 
> those cases would be less frequent.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13718) SPLITSHARD using async can cause data loss

[Ishan Chattopadhyaya (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ishan Chattopadhyaya updated SOLR-13718:

Fix Version/s: 7.7.3

> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7.2, 8.1, 8.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.7.3, 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the 
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD 
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to 
> reproduce using a Solr 6x index in Solr 7x.
> Steps to reproduce (in Solr 7x):
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of 
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] shalinmangar merged pull request #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

shalinmangar merged pull request #805: SOLR-13649 change the default behavior 
of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805
 
 
   


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13718) SPLITSHARD using async can cause data loss

[Ishan Chattopadhyaya (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ishan Chattopadhyaya updated SOLR-13718:

Description: 
When using SPLITSHARD with async, if there are underlying failures in the SPLIT 
core command or other sub-commands of SPLITSHARD, then SPLITSHARD succeeds and 
results in two empty sub-shards.

There are various potential failures with SPLIT core command, here's a way to 
reproduce using a Solr 6x index in Solr 7x.

-Steps to reproduce (in Solr 7x):-
{code}
1. Import the attached configset, and create a collection.
2. Move in the attached data directory (index created in Solr6x) in place of 
the created collection's data directory. Do a collection RELOAD.
3. Issue a *:* query, we see 5 documents.
4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
{code}

Check 

  was:
When using SPLITSHARD with async, if there are underlying failures in the SPLIT 
core command or other sub-commands of SPLITSHARD, then SPLITSHARD succeeds and 
results in two empty sub-shards.

There are various potential failures with SPLIT core command, here's a way to 
reproduce using a Solr 6x index in Solr 7x.

Steps to reproduce (in Solr 7x):
{code}
1. Import the attached configset, and create a collection.
2. Move in the attached data directory (index created in Solr6x) in place of 
the created collection's data directory. Do a collection RELOAD.
3. Issue a *:* query, we see 5 documents.
4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
{code}



> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7.2, 8.1, 8.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.7.3, 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the 
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD 
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to 
> reproduce using a Solr 6x index in Solr 7x.
> -Steps to reproduce (in Solr 7x):-
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of 
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
> {code}
> Check 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13718) SPLITSHARD using async can cause data loss

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918292#comment-16918292
 ] 

ASF subversion and git services commented on SOLR-13718:


Commit f5e6334a69d20f6af7b4297c1555885289d1e25a in lucene-solr's branch 
refs/heads/branch_7_7 from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f5e6334 ]

SOLR-13718: SPLITSHARD (async) with failures in underlying sub-operations can 
result in data loss

  When SPLITSHARD is issued asynchronously, any exception in a sub-operation 
isn't propagated and the overall
  SPLITSHARD task proceeds as if there were no failures. This results in 
marking the active parent shard inactive
  and can result in two empty sub-shards, thus causing data loss.


> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7.2, 8.1, 8.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the 
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD 
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to 
> reproduce using a Solr 6x index in Solr 7x.
> Steps to reproduce (in Solr 7x):
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of 
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] shalinmangar commented on issue #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

shalinmangar commented on issue #805: SOLR-13649 change the default behavior of 
the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#issuecomment-526028139
 
 
   +1 LGTM. I'm going to do a squash merge to master.


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 199 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/199/

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClientTest.testCollectionParameters

Error Message:
Captured an uncaught exception in thread: Thread[id=5232, 
name=h2sc-2087-thread-6, state=RUNNABLE, 
group=TGRP-ConcurrentUpdateHttp2SolrClientTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=5232, name=h2sc-2087-thread-6, state=RUNNABLE, 
group=TGRP-ConcurrentUpdateHttp2SolrClientTest]
at 
__randomizedtesting.SeedInfo.seed([68236FDA71F417A9:5D074ABF00134EAB]:0)
Caused by: java.lang.ClassCastException: 
org.eclipse.jetty.io.WriteFlusher$IdleState cannot be cast to 
org.eclipse.jetty.io.WriteFlusher$FailedState
at __randomizedtesting.SeedInfo.seed([68236FDA71F417A9]:0)
at org.eclipse.jetty.io.WriteFlusher.fail(WriteFlusher.java:310)
at 
org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:376)
at 
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.lambda$fill$1(SslConnection.java:670)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 16983 lines...]
   [junit4] Suite: 
org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClientTest
   [junit4]   2> 250012 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> 250013 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.a.s.SolrTestCaseJ4 Created dataDir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClientTest_68236FDA71F417A9-001/data-dir-28-001
   [junit4]   2> 250013 WARN  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2
   [junit4]   2> 250013 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) 
w/NUMERIC_DOCVALUES_SYSPROP=true
   [junit4]   2> 250015 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 250058 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.a.s.SolrTestCaseJ4 initCore
   [junit4]   2> 250058 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.a.s.SolrTestCaseJ4 initCore end
   [junit4]   2> 250058 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.a.s.SolrTestCaseJ4 Writing core.properties file to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClientTest_68236FDA71F417A9-001/tempDir-002/cores/core
   [junit4]   2> 250063 WARN  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.e.j.s.AbstractConnector Ignoring deprecated socket close linger time
   [junit4]   2> 250063 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.a.s.c.s.e.JettySolrRunner Start Jetty (original configured port=0)
   [junit4]   2> 250063 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.a.s.c.s.e.JettySolrRunner Trying to start Jetty on port 0 try number 1 ...
   [junit4]   2> 250063 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.e.j.s.Server jetty-9.4.19.v20190610; built: 2019-06-10T16:30:51.723Z; git: 
afcf563148970e98786327af5e07c261fda175d3; jvm 1.8.0_191-b12
   [junit4]   2> 250067 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.e.j.s.session DefaultSessionIdManager workerName=node0
   [junit4]   2> 250067 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.e.j.s.session No SessionScavenger set, using defaults
   [junit4]   2> 250067 INFO  
(SUITE-ConcurrentUpdateHttp2SolrClientTest-seed#[68236FDA71F417A9]-worker) [
 ] o.e.j.s.session node0 Scavenging every 60ms
   [junit4]   2> 250067 INFO  

[jira] [Commented] (SOLR-12291) Async prematurely reports completed status that causes severe shard loss

[Ishan Chattopadhyaya (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-12291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918281#comment-16918281
 ] 

Ishan Chattopadhyaya commented on SOLR-12291:
-

Does this affect the 7x branch as well? Should we port to 7.7 branch as well?

> Async prematurely reports completed status that causes severe shard loss
> 
>
> Key: SOLR-12291
> URL: https://issues.apache.org/jira/browse/SOLR-12291
> Project: Solr
>  Issue Type: Bug
>  Components: Backup/Restore, SolrCloud
>Reporter: Varun Thacker
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, 
> SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, 
> SOLR-122911.patch
>
>
> The OverseerCollectionMessageHandler sliceCmd assumes only one replica exists 
> on one node
> When multiple replicas of a slice are on the same node we only track one 
> replica's async request. This happens because the async requestMap's key is 
> "node_name"
> I discovered this when [~alabax] shared some logs of a restore issue, where 
> the second replica got added before the first replica had completed it's 
> restorecore action.
> While looking at the logs I noticed that the overseer never called 
> REQUESTSTATUS for the restorecore action , almost as if it had missed 
> tracking that particular async request.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

please care and vote for Chinese people under cruel autocracy of CCP, great thanks!

[ant_fighter]

Hi all,
Sorry for disturbing you guys. Though I don't think here as a proper place to 
do this, I need your help, your vote, your holy vote, for us Chinese, for 
conscience and justice, for better world.

In the over 70 years of ruling over China, the Chinese Communist Party has done 
many horrible things humans can think of. These malicious and evil deeds 
include but are not limited to: falsifying national history, suppression of 
freedom of speech and press, money laundering in the scale of trillions, live 
organ harvesting, sexual harassment and assault to underaged females, 
slaughtering innocent citizens with counter-revolutionary excuses, etc.

In light of the recent violent actions to Hong Kongers by the People's 
Liberation Army (PLA) disguised as Hong Kong Police Force, we the people 
petition to officially recognize the Chinese Communist Party as a terrorist 
organization.

PLEASE SIGNUP and VOTE for us：
https://petitions.whitehouse.gov/petition/call-official-recognition-chinese-communist-party-terrorist-organization

Thanks again for all!

nameless, an ant fighter
2019.8.29

[jira] [Commented] (SOLR-13718) SPLITSHARD using async can cause data loss

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918280#comment-16918280
 ] 

ASF subversion and git services commented on SOLR-13718:


Commit d606ffdea92513a29bd7d7a1af3cfdf556aae93c in lucene-solr's branch 
refs/heads/branch_8x from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d606ffd ]

SOLR-13718: SPLITSHARD (async) with failures in underlying sub-operations can 
result in data loss

  When SPLITSHARD is issued asynchronously, any exception in a sub-operation 
isn't propagated and the overall
  SPLITSHARD task proceeds as if there were no failures. This results in 
marking the active parent shard inactive
  and can result in two empty sub-shards, thus causing data loss.


> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7.2, 8.1, 8.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the 
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD 
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to 
> reproduce using a Solr 6x index in Solr 7x.
> Steps to reproduce (in Solr 7x):
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of 
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-13718) SPLITSHARD using async can cause data loss

[Ishan Chattopadhyaya (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918279#comment-16918279
 ] 

Ishan Chattopadhyaya edited comment on SOLR-13718 at 8/29/19 4:41 AM:
--

I found it very hard to reproduce a SPLIT core operation failure in a unit 
test. Attaching a script (for testing on master) to test the same. This uses a 
backward compatible index (which is already under the lucene's directory tree).


was (Author: ichattopadhyaya):
I found it very hard to reproduce a SPLIT core operation failure in a unit 
test. Attaching a script (for testing on master) to test the same. This uses a 
backward compatible index.

> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7.2, 8.1, 8.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the 
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD 
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to 
> reproduce using a Solr 6x index in Solr 7x.
> Steps to reproduce (in Solr 7x):
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of 
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13718) SPLITSHARD using async can cause data loss

[Ishan Chattopadhyaya (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ishan Chattopadhyaya updated SOLR-13718:

   Attachment: solr-13718-reproduce.sh
Fix Version/s: 8.3
Affects Version/s: 8.1
   8.2
   Status: Open  (was: Open)

I found it very hard to reproduce a SPLIT core operation failure in a unit 
test. Attaching a script (for testing on master) to test the same. This uses a 
backward compatible index.

> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2, 8.1, 7.7.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the 
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD 
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to 
> reproduce using a Solr 6x index in Solr 7x.
> Steps to reproduce (in Solr 7x):
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of 
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13718) SPLITSHARD using async can cause data loss

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918278#comment-16918278
 ] 

ASF subversion and git services commented on SOLR-13718:


Commit a8d5bd34bf494da8f59baea52f6578bf3ba44ce8 in lucene-solr's branch 
refs/heads/master from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a8d5bd3 ]

SOLR-13718: SPLITSHARD (async) with failures in underlying sub-operations can 
result in data loss

  When SPLITSHARD is issued asynchronously, any exception in a sub-operation 
isn't propagated and the overall
  SPLITSHARD task proceeds as if there were no failures. This results in 
marking the active parent shard inactive
  and can result in two empty sub-shards, thus causing data loss.


> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-13718.patch, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the 
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD 
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to 
> reproduce using a Solr 6x index in Solr 7x.
> Steps to reproduce (in Solr 7x):
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of 
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD, and then issue *:*, we see 0 documents.
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13723) JettySolrRunner should support /api/* (the v2 end point)

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918268#comment-16918268
 ] 

ASF subversion and git services commented on SOLR-13723:


Commit da02e9f83cbb531dda12962d91558c3a979608f9 in lucene-solr's branch 
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=da02e9f ]

SOLR-13723: JettySolrRunner should support /api/* (the v2 end point)


> JettySolrRunner should support /api/* (the v2 end point)
> 
>
> Key: SOLR-13723
> URL: https://issues.apache.org/jira/browse/SOLR-13723
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Minor
>  Labels: test-framework
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Today we are not able to write proper v2 API testcases because of this



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13723) JettySolrRunner should support /api/* (the v2 end point)

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918267#comment-16918267
 ] 

ASF subversion and git services commented on SOLR-13723:


Commit 7d026f803d03467e9152de07381bdc246b26c8ce in lucene-solr's branch 
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7d026f8 ]

SOLR-13723: JettySolrRunner should support /api/* (the v2 end point)


> JettySolrRunner should support /api/* (the v2 end point)
> 
>
> Key: SOLR-13723
> URL: https://issues.apache.org/jira/browse/SOLR-13723
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Minor
>  Labels: test-framework
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Today we are not able to write proper v2 API testcases because of this



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13723) JettySolrRunner should support /api/* (the v2 end point)

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918263#comment-16918263
 ] 

ASF subversion and git services commented on SOLR-13723:


Commit cf21340294a52ad764deac7b9cdd38d06cfbc3da in lucene-solr's branch 
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cf21340 ]

SOLR-13723: JettySolrRunner should support /api/* (the v2 end point)



> JettySolrRunner should support /api/* (the v2 end point)
> 
>
> Key: SOLR-13723
> URL: https://issues.apache.org/jira/browse/SOLR-13723
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Minor
>  Labels: test-framework
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Today we are not able to write proper v2 API testcases because of this



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] noblepaul merged pull request #847: SOLR-13723 JettySolrRunner should support /api/* (the v2 end point)

[GitBox]

noblepaul merged pull request #847: SOLR-13723 JettySolrRunner should support 
/api/* (the v2 end point)
URL: https://github.com/apache/lucene-solr/pull/847
 
 
   


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13725) TermsFacetMap.setLimit() unnecessarily rejects negative parameter value

[Richard Walker (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Walker updated SOLR-13725:
--
Priority: Trivial  (was: Major)

> TermsFacetMap.setLimit() unnecessarily rejects negative parameter value
> ---
>
> Key: SOLR-13725
> URL: https://issues.apache.org/jira/browse/SOLR-13725
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 8.2
>Reporter: Richard Walker
>Priority: Trivial
>
> SolrJ's {{TermsFacetMap.setLimit(int maximumBuckets)}} rejects a negative 
> parameter value with an IllegalArgumentException "Parameter 'maximumBuckets' 
> must be non-negative".
> But a negative value for the limit parameter is accepted by Solr server, and 
> is meaningful: i.e., it means "no limit".
> The {{setLimit()}} method shouldn't reject a negative parameter value.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] MarcusSorealheis commented on issue #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

MarcusSorealheis commented on issue #805: SOLR-13649 change the default 
behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#issuecomment-525982234
 
 
   
![image](https://user-images.githubusercontent.com/2353608/63902942-960f4e00-c9c0-11e9-8360-9a2e8e8caafb.png)
   
   See above, `ant precommit` is fixed now. Thanks again @janhoy @shalinmangar 


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1944 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1944/

No tests ran.

Build Log:
[...truncated 25 lines...]
ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data
org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the 
server
svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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:744)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 
org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
... 4 more
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

[jira] [Created] (SOLR-13725) TermsFacetMap.setLimit() unnecessarily rejects negative parameter value

[Richard Walker (Jira)]

Richard Walker created SOLR-13725:
-

 Summary: TermsFacetMap.setLimit() unnecessarily rejects negative 
parameter value
 Key: SOLR-13725
 URL: https://issues.apache.org/jira/browse/SOLR-13725
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrJ
Affects Versions: 8.2
Reporter: Richard Walker


SolrJ's {{TermsFacetMap.setLimit(int maximumBuckets)}} rejects a negative 
parameter value with an IllegalArgumentException "Parameter 'maximumBuckets' 
must be non-negative".

But a negative value for the limit parameter is accepted by Solr server, and is 
meaningful: i.e., it means "no limit".

The {{setLimit()}} method shouldn't reject a negative parameter value.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] MarcusSorealheis commented on issue #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

MarcusSorealheis commented on issue #805: SOLR-13649 change the default 
behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#issuecomment-525952277
 
 
   @janhoy I need to make a few changes for precommit to pass. making now.


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] MarcusSorealheis removed a comment on issue #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

MarcusSorealheis removed a comment on issue #805: SOLR-13649 change the default 
behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#issuecomment-525944739
 
 
   Ok. Will do. Thank you.
   
   On Wed, Aug 28, 2019 at 3:20 PM Jan Høydahl 
   wrote:
   
   > @MarcusSorealheis  Can you try to
   > address this precommit error:
   >
   > [java] ERROR: Orphan page:
   > 
/Users/janhoy/git/lucene-solr/solr/build/solr-ref-guide/content/major-changes-in-solr-9.adoc
   >
   > All new adoc pages need to be linked into the structure from somewhere.
   > You need to add it to the top of solr-upgrade-notes.adoc. Then simply run 
ant
   > precommit afterwards to verify that it is fixed.
   >
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > 
,
   > or mute the thread
   > 

   > .
   >
   -- 
   Marcus Eagan
   


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] MarcusSorealheis commented on issue #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

MarcusSorealheis commented on issue #805: SOLR-13649 change the default 
behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#issuecomment-525944739
 
 
   Ok. Will do. Thank you.
   
   On Wed, Aug 28, 2019 at 3:20 PM Jan Høydahl 
   wrote:
   
   > @MarcusSorealheis  Can you try to
   > address this precommit error:
   >
   > [java] ERROR: Orphan page:
   > 
/Users/janhoy/git/lucene-solr/solr/build/solr-ref-guide/content/major-changes-in-solr-9.adoc
   >
   > All new adoc pages need to be linked into the structure from somewhere.
   > You need to add it to the top of solr-upgrade-notes.adoc. Then simply run 
ant
   > precommit afterwards to verify that it is fixed.
   >
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > 
,
   > or mute the thread
   > 

   > .
   >
   -- 
   Marcus Eagan
   


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] janhoy commented on issue #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

janhoy commented on issue #805: SOLR-13649 change the default behavior of the 
basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#issuecomment-525944463
 
 
   @MarcusSorealheis Can you try to address this precommit error:
   
   > [java] ERROR: Orphan page: 
/Users/janhoy/git/lucene-solr/solr/build/solr-ref-guide/content/major-changes-in-solr-9.adoc
   
   All new adoc pages need to be linked into the structure from somewhere. You 
need to add it to the top of `solr-upgrade-notes.adoc`. Then simply run `ant 
precommit` afterwards to verify that it is fixed.


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

MarcusSorealheis commented on a change in pull request #805: SOLR-13649 change 
the default behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#discussion_r318801263
 
 

 ##
 File path: 
solr/core/src/test/org/apache/solr/security/BasicAuthStandaloneTest.java
 ##
 @@ -96,35 +96,35 @@ public void testBasicAuth() throws Exception {
   String baseUrl = buildUrl(jetty.getLocalPort(), "/solr"); 
   httpSolrClient = getHttpSolrClient(baseUrl);
   
-  verifySecurityStatus(cl, baseUrl + authcPrefix, "/errorMessages", null, 
20);
 
 Review comment:
   ahh, I see what you meant. Very cool.


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] MarcusSorealheis commented on issue #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

MarcusSorealheis commented on issue #805: SOLR-13649 change the default 
behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#issuecomment-525929484
 
 
   very big help @janhoy. That was awesome. L-ingGTM?


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

MarcusSorealheis commented on a change in pull request #805: SOLR-13649 change 
the default behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#discussion_r318798645
 
 

 ##
 File path: 
solr/core/src/test/org/apache/solr/security/BasicAuthStandaloneTest.java
 ##
 @@ -96,35 +96,35 @@ public void testBasicAuth() throws Exception {
   String baseUrl = buildUrl(jetty.getLocalPort(), "/solr"); 
   httpSolrClient = getHttpSolrClient(baseUrl);
   
-  verifySecurityStatus(cl, baseUrl + authcPrefix, "/errorMessages", null, 
20);
 
 Review comment:
   
![image](https://user-images.githubusercontent.com/2353608/63893447-09a06380-c99f-11e9-8de4-867a9776094b.png)
 <-- I'm only at 205
   
   I will merge it in. thanks for it. I understood what you meant, mostly. 
Wasn't sure if the tests were supposed to get updated. received a few bits of 
conflicting feedback and trying to incorporate all because I'm new.


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13724) Reject v1 API updates for (non-routed) multi-collection aliases

[Jason Gerlowski (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918122#comment-16918122
 ] 

Jason Gerlowski commented on SOLR-13724:


Here's a quick way to reproduce the behavior:

{code}
➜  solr git:(fcbe46c28ce) ✗ bin/solr start -c
Waiting up to 180 seconds to see Solr running on port 8983 [\]  
Started Solr server on port 8983 (pid=20921). Happy searching!

➜  solr git:(fcbe46c28ce) ✗ bin/solr create -c foo
Created collection 'foo' with 1 shard(s), 1 replica(s) with config-set 'foo'
➜  solr git:(fcbe46c28ce) ✗ bin/solr create -c bar
Created collection 'bar' with 1 shard(s), 1 replica(s) with config-set 'bar'
➜  solr git:(fcbe46c28ce) ✗ curl -ilk -X GET 
"http://localhost:8983/solr/admin/collections?action=CREATEALIAS=my_alias=foo,bar;
HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
Content-Length: 57

{
  "responseHeader":{
"status":0,
"QTime":128}}
➜  solr git:(fcbe46c28ce) ✗ curl -ilk -X POST -H "Content-type: 
application/json" "http://localhost:8983/solr/my_alias/update?commit=true; -d 
'[{"id": "asdf", "val_i": 4}]'
HTTP/1.1 200 OK
Content-Type: text/plain;charset=utf-8
Content-Length: 69

{
  "responseHeader":{
"rf":1,
"status":0,
"QTime":373}}
{code}

> Reject v1 API updates for (non-routed) multi-collection aliases
> ---
>
> Key: SOLR-13724
> URL: https://issues.apache.org/jira/browse/SOLR-13724
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.1, master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
>
> The intent of SOLR-13407 was to block all updates on aliases that represent 
> multiple collections.  Currently, this works for deletes, commits, and 
> optimize requests.  Users get a message like: {{Update request to non-routed 
> multi-collection alias not supported}}.
> But currently we still allow document adds/updates to go through.
> We should either close this last hole, so _no_ update requests are allowed, 
> or document it so the behavior clearer.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-13724) Reject v1 API updates for (non-routed) multi-collection aliases

[Jason Gerlowski (Jira)]

Jason Gerlowski created SOLR-13724:
--

 Summary: Reject v1 API updates for (non-routed) multi-collection 
aliases
 Key: SOLR-13724
 URL: https://issues.apache.org/jira/browse/SOLR-13724
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.1, master (9.0)
Reporter: Jason Gerlowski


The intent of SOLR-13407 was to block all updates on aliases that represent 
multiple collections.  Currently, this works for deletes, commits, and optimize 
requests.  Users get a message like: {{Update request to non-routed 
multi-collection alias not supported}}.

But currently we still allow document adds/updates to go through.

We should either close this last hole, so _no_ update requests are allowed, or 
document it so the behavior clearer.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13035) Utilize solr.data.home / solrDataHome in solr.xml to set all writable files in single directory

[Mikhail Khludnev (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918114#comment-16918114
 ] 

Mikhail Khludnev commented on SOLR-13035:
-

Hello [~sarkaramr...@gmail.com] , I resolved conflicts a little, and launched 
windows script. Here's what I have

At first I added -v -V and examine output. This one make sense 
GC_LOG_OPTS = "-Xlog:gc*:file=\"data\logs\solr_gc.log\":time,up

This one looks odd 

SOLR_DATA_HOME = data\data\data

Here's what I have in Solr Admin. Shouldn't tmp folder moved to writable home

-Djava.io.tmpdir=lucene-solr\solr\server\tmp

That's odd

-Dsolr.data.home=data\data\data

This is ok 

-Dsolr.log.dir=data\logs

-Dsolr.solr.home=\lucene-solr\solr\server\solr

-Xlog:gc*:file="data\logs\solr_gc.log":

!image-2019-08-28-23-57-39-826.png!

I'm not sure if this is expected behavior. 

Also usage prompt seems vague to me 

-w dir Solr will create all writable directories and files relative to this.
 solr.data.home if relative, will be set as SOLR_VAR_ROOT\{this}/solr.data.home
 solr.log.dir if relative, will be set as SOLR_VAR_ROOT\{this}/solr.log.dir

These references SOLR_VAR_ROOT\{this} isn't obvious. 

 

 

> Utilize solr.data.home / solrDataHome in solr.xml to set all writable files 
> in single directory
> ---
>
> Key: SOLR-13035
> URL: https://issues.apache.org/jira/browse/SOLR-13035
> Project: Solr
>  Issue Type: Improvement
>Reporter: Amrit Sarkar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13035.patch, SOLR-13035.patch, SOLR-13035.patch, 
> SOLR-13035.patch, SOLR-13035.patch, image-2019-08-28-23-57-39-826.png
>
>
> {{solr.data.home}} system property or {{solrDataHome}} in _solr.xml_ is 
> already available as per SOLR-6671.
> The writable content in Solr are index files, core properties, and ZK data if 
> embedded zookeeper is started in SolrCloud mode. It would be great if all 
> writable content can come under the same directory to have separate READ-ONLY 
> and WRITE-ONLY directories.
> It can then also solve official docker Solr image issues:
> https://github.com/docker-solr/docker-solr/issues/74
> https://github.com/docker-solr/docker-solr/issues/133



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser

[Lucene/Solr QA (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918105#comment-16918105
 ] 

Lucene/Solr QA commented on SOLR-13720:
---

| (/) *{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}  2m  
8s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 59s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 30m 
21s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 37m 37s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13720 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12978816/SOLR-13720.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 / 62f55c073c |
| 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/542/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/542/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Impossible to create effective ToParenBlockJoinQuery in custom QParser
> --
>
> Key: SOLR-13720
> URL: https://issues.apache.org/jira/browse/SOLR-13720
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Stanislav Livotov
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13720.patch
>
>
> According to Solr [ducumentation|#SolrPlugins-QParserPlugin]  QParser is 
> treated as a legal plugin.
>  
> However, it is impossible to create an effective ToParentBlockJoin query 
> without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter 
> method from BlockJoinParentQParser) or dirty hacks(like creating 
> org.apache.solr.search.join package with some accessor method to 
> package-private methods in plugin code and adding it in WEB-INF/lib directory 
> in order to be loaded by the same ClassLoader).
> I don't see a truly clean way how to fix it, but at least we can help custom 
> plugin developers to create it a little bit easier by making 
> BlockJoinParentQParser#getCachedFilter public and 
> BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for 
> BitDocIdSetFilterWrapper#filter. 
>  
>  
> In order to create 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13035) Utilize solr.data.home / solrDataHome in solr.xml to set all writable files in single directory

[Mikhail Khludnev (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev updated SOLR-13035:

Attachment: image-2019-08-28-23-57-39-826.png

> Utilize solr.data.home / solrDataHome in solr.xml to set all writable files 
> in single directory
> ---
>
> Key: SOLR-13035
> URL: https://issues.apache.org/jira/browse/SOLR-13035
> Project: Solr
>  Issue Type: Improvement
>Reporter: Amrit Sarkar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13035.patch, SOLR-13035.patch, SOLR-13035.patch, 
> SOLR-13035.patch, SOLR-13035.patch, image-2019-08-28-23-57-39-826.png
>
>
> {{solr.data.home}} system property or {{solrDataHome}} in _solr.xml_ is 
> already available as per SOLR-6671.
> The writable content in Solr are index files, core properties, and ZK data if 
> embedded zookeeper is started in SolrCloud mode. It would be great if all 
> writable content can come under the same directory to have separate READ-ONLY 
> and WRITE-ONLY directories.
> It can then also solve official docker Solr image issues:
> https://github.com/docker-solr/docker-solr/issues/74
> https://github.com/docker-solr/docker-solr/issues/133



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 195 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/195/

No tests ran.

Build Log:
[...truncated 30 lines...]
ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data
org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the 
server
svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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:744)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 
org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
... 4 more
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

[GitHub] [lucene-solr] janhoy commented on a change in pull request #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

janhoy commented on a change in pull request #805: SOLR-13649 change the 
default behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#discussion_r318767322
 
 

 ##
 File path: 
solr/core/src/test/org/apache/solr/security/BasicAuthStandaloneTest.java
 ##
 @@ -96,35 +96,35 @@ public void testBasicAuth() throws Exception {
   String baseUrl = buildUrl(jetty.getLocalPort(), "/solr"); 
   httpSolrClient = getHttpSolrClient(baseUrl);
   
-  verifySecurityStatus(cl, baseUrl + authcPrefix, "/errorMessages", null, 
20);
 
 Review comment:
   My latest simplifications reduces the patch from 1446 to 391 lines 


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] janhoy commented on a change in pull request #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

janhoy commented on a change in pull request #805: SOLR-13649 change the 
default behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#discussion_r318763377
 
 

 ##
 File path: 
solr/core/src/test/org/apache/solr/security/BasicAuthStandaloneTest.java
 ##
 @@ -96,35 +96,35 @@ public void testBasicAuth() throws Exception {
   String baseUrl = buildUrl(jetty.getLocalPort(), "/solr"); 
   httpSolrClient = getHttpSolrClient(baseUrl);
   
-  verifySecurityStatus(cl, baseUrl + authcPrefix, "/errorMessages", null, 
20);
 
 Review comment:
   So my point was that there is no need to change the test behavior for this 
change, we can instead add the blockUnknown=false to these tests (which is 
exactly what users would do to keep existing behavior) and that's it.
   
   I opened a PR https://github.com/MarcusSorealheis/lucene-solr/pull/1 with my 
proposal which removes a bunch of unnecessary and complicating changes. You 
should be able to merge it into this PR :)


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] erikhatcher commented on issue #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

erikhatcher commented on issue #805: SOLR-13649 change the default behavior of 
the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#issuecomment-525892861
 
 
   Looks great, Marcus!   I've run the tests and they are passing.


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1435 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1435/

No tests ran.

Build Log:
[...truncated 24456 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2594 links (2120 relative) to 3411 anchors in 259 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-9.0.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

[jira] [Updated] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser

[Stanislav Livotov (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stanislav Livotov updated SOLR-13720:
-
Attachment: SOLR-13720.patch

> Impossible to create effective ToParenBlockJoinQuery in custom QParser
> --
>
> Key: SOLR-13720
> URL: https://issues.apache.org/jira/browse/SOLR-13720
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Stanislav Livotov
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13720.patch
>
>
> According to Solr [ducumentation|#SolrPlugins-QParserPlugin]  QParser is 
> treated as a legal plugin.
>  
> However, it is impossible to create an effective ToParentBlockJoin query 
> without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter 
> method from BlockJoinParentQParser) or dirty hacks(like creating 
> org.apache.solr.search.join package with some accessor method to 
> package-private methods in plugin code and adding it in WEB-INF/lib directory 
> in order to be loaded by the same ClassLoader).
> I don't see a truly clean way how to fix it, but at least we can help custom 
> plugin developers to create it a little bit easier by making 
> BlockJoinParentQParser#getCachedFilter public and 
> BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for 
> BitDocIdSetFilterWrapper#filter. 
>  
>  
> In order to create 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser

[Stanislav Livotov (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stanislav Livotov updated SOLR-13720:
-
Attachment: (was: SOLR-13720.patch)

> Impossible to create effective ToParenBlockJoinQuery in custom QParser
> --
>
> Key: SOLR-13720
> URL: https://issues.apache.org/jira/browse/SOLR-13720
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Stanislav Livotov
>Priority: Major
> Fix For: master (9.0)
>
>
> According to Solr [ducumentation|#SolrPlugins-QParserPlugin]  QParser is 
> treated as a legal plugin.
>  
> However, it is impossible to create an effective ToParentBlockJoin query 
> without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter 
> method from BlockJoinParentQParser) or dirty hacks(like creating 
> org.apache.solr.search.join package with some accessor method to 
> package-private methods in plugin code and adding it in WEB-INF/lib directory 
> in order to be loaded by the same ClassLoader).
> I don't see a truly clean way how to fix it, but at least we can help custom 
> plugin developers to create it a little bit easier by making 
> BlockJoinParentQParser#getCachedFilter public and 
> BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for 
> BitDocIdSetFilterWrapper#filter. 
>  
>  
> In order to create 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser

[Stanislav Livotov (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stanislav Livotov updated SOLR-13720:
-
Attachment: (was: SOLR-13720.patch)

> Impossible to create effective ToParenBlockJoinQuery in custom QParser
> --
>
> Key: SOLR-13720
> URL: https://issues.apache.org/jira/browse/SOLR-13720
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Stanislav Livotov
>Priority: Major
> Fix For: master (9.0)
>
>
> According to Solr [ducumentation|#SolrPlugins-QParserPlugin]  QParser is 
> treated as a legal plugin.
>  
> However, it is impossible to create an effective ToParentBlockJoin query 
> without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter 
> method from BlockJoinParentQParser) or dirty hacks(like creating 
> org.apache.solr.search.join package with some accessor method to 
> package-private methods in plugin code and adding it in WEB-INF/lib directory 
> in order to be loaded by the same ClassLoader).
> I don't see a truly clean way how to fix it, but at least we can help custom 
> plugin developers to create it a little bit easier by making 
> BlockJoinParentQParser#getCachedFilter public and 
> BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for 
> BitDocIdSetFilterWrapper#filter. 
>  
>  
> In order to create 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13690) Migrate field type configurations in default/example schema files to look up factories by "name"

[Tomoko Uchida (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomoko Uchida updated SOLR-13690:
-
Fix Version/s: master (9.0)

> Migrate field type configurations in default/example schema files to look up 
> factories by "name"
> 
>
> Key: SOLR-13690
> URL: https://issues.apache.org/jira/browse/SOLR-13690
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
>
> This is a follow-up task for SOLR-13593.
> To encourage users to use the "name" attribute in field type configurations, 
> we should migrate all managed-schema files bundled with Solr.
> There are 8 managed-schemas (except for test resources) in solr.
> {code}
> lucene-solr-mirror $ find solr -name "managed-schema" | grep -v test
> solr/server/solr/configsets/sample_techproducts_configs/conf/managed-schema
> solr/server/solr/configsets/_default/conf/managed-schema
> solr/example/files/conf/managed-schema
> solr/example/example-DIH/solr/solr/conf/managed-schema
> solr/example/example-DIH/solr/db/conf/managed-schema
> solr/example/example-DIH/solr/atom/conf/managed-schema
> solr/example/example-DIH/solr/mail/conf/managed-schema
> solr/example/example-DIH/solr/tika/conf/managed-schema
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13690) Migrate field type configurations in default/example schema files to look up factories by "name"

[Tomoko Uchida (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomoko Uchida updated SOLR-13690:
-
Description: 
This is a follow-up task for SOLR-13593.

To encourage users to use the "name" attribute in field type configurations, we 
should migrate all managed-schema files bundled with Solr.

There are 8 managed-schemas (except for test resources) in solr.

{code}
lucene-solr-mirror $ find solr -name "managed-schema" | grep -v test
solr/server/solr/configsets/sample_techproducts_configs/conf/managed-schema
solr/server/solr/configsets/_default/conf/managed-schema
solr/example/files/conf/managed-schema
solr/example/example-DIH/solr/solr/conf/managed-schema
solr/example/example-DIH/solr/db/conf/managed-schema
solr/example/example-DIH/solr/atom/conf/managed-schema
solr/example/example-DIH/solr/mail/conf/managed-schema
solr/example/example-DIH/solr/tika/conf/managed-schema
{code}

  was:
This is a follow-up task for SOLR-13593.

To encourage users to use the "name" attribute in field type configurations, we 
should migrate all managed-schema files bundled with Solr.


> Migrate field type configurations in default/example schema files to look up 
> factories by "name"
> 
>
> Key: SOLR-13690
> URL: https://issues.apache.org/jira/browse/SOLR-13690
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
>
> This is a follow-up task for SOLR-13593.
> To encourage users to use the "name" attribute in field type configurations, 
> we should migrate all managed-schema files bundled with Solr.
> There are 8 managed-schemas (except for test resources) in solr.
> {code}
> lucene-solr-mirror $ find solr -name "managed-schema" | grep -v test
> solr/server/solr/configsets/sample_techproducts_configs/conf/managed-schema
> solr/server/solr/configsets/_default/conf/managed-schema
> solr/example/files/conf/managed-schema
> solr/example/example-DIH/solr/solr/conf/managed-schema
> solr/example/example-DIH/solr/db/conf/managed-schema
> solr/example/example-DIH/solr/atom/conf/managed-schema
> solr/example/example-DIH/solr/mail/conf/managed-schema
> solr/example/example-DIH/solr/tika/conf/managed-schema
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-13257) Enable replica routing affinity for better cache usage

[Anshum Gupta (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anshum Gupta resolved SOLR-13257.
-
Resolution: Fixed

> Enable replica routing affinity for better cache usage
> --
>
> Key: SOLR-13257
> URL: https://issues.apache.org/jira/browse/SOLR-13257
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Michael Gibney
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: master (9.0), 8.3
>
> Attachments: AffinityShardHandlerFactory.java, SOLR-13257.patch, 
> SOLR-13257.patch
>
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> For each shard in a distributed request, Solr currently routes each request 
> randomly via 
> [ShufflingReplicaListTransformer|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/ShufflingReplicaListTransformer.java]
>  to a particular replica. In setups with replication factor >1, this normally 
> results in a situation where subsequent requests (which one would hope/expect 
> to leverage cached results from previous related requests) end up getting 
> routed to a replica that hasn't seen any related requests.
> The problem can be replicated by issuing a relatively expensive query (maybe 
> containing common terms?). The first request initializes the 
> {{queryResultCache}} on the consulted replicas. If replication factor >1 and 
> there are a sufficient number of shards, subsequent requests will likely be 
> routed to at least one replica that _hasn't_ seen the query before. The 
> replicas with uninitialized caches become a bottleneck, and from the client's 
> perspective, many subsequent requests appear not to benefit from caching at 
> all.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-master - Build # 3638 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3638/

All tests passed

Build Log:
[...truncated 63940 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj500611701
 [ecj-lint] Compiling 1289 source files to /tmp/ecj500611701
 [ecj-lint] Processing annotations
 [ecj-lint] Annotations processed
 [ecj-lint] Processing annotations
 [ecj-lint] No elements to process
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
 (at line 219)
 [ecj-lint] return (NamedList) new 
JavaBinCodec(resolver).unmarshal(in);
 [ecj-lint]^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
 (at line 232)
 [ecj-lint] ReplicationHandler replicationHandler = (ReplicationHandler) 
handler;
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'replicationHandler' is never closed
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
 (at line 628)
 [ecj-lint] PeerSyncWithLeader peerSyncWithLeader = new 
PeerSyncWithLeader(core,
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'peerSyncWithLeader' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java
 (at line 186)
 [ecj-lint] PeerSync peerSync = new PeerSync(core, syncWith, 
core.getUpdateHandler().getUpdateLog().getNumRecordsToKeep(), true, 
peerSyncOnlyWithActive, false);
 [ecj-lint]  
 [ecj-lint] Resource leak: 'peerSync' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 5. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 788)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 6. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 794)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 7. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/CoreContainer.java
 (at line 726)
 [ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean();
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'fieldCacheBean' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 19)
 [ecj-lint] import javax.naming.Context;
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 20)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible
 [ecj-lint] --
 [ecj-lint] 10. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 21)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 11. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 

[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

MarcusSorealheis commented on a change in pull request #805: SOLR-13649 change 
the default behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#discussion_r318667994
 
 

 ##
 File path: 
solr/core/src/test/org/apache/solr/security/BasicAuthStandaloneTest.java
 ##
 @@ -96,35 +96,35 @@ public void testBasicAuth() throws Exception {
   String baseUrl = buildUrl(jetty.getLocalPort(), "/solr"); 
   httpSolrClient = getHttpSolrClient(baseUrl);
   
-  verifySecurityStatus(cl, baseUrl + authcPrefix, "/errorMessages", null, 
20);
 
 Review comment:
   all tests pass as well, but of course, I will allow you to see that for 
yourself. Don't take my word for it.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] chatman commented on issue #768: SOLR-13472: Defer authorization to be done on forwarded nodes

[GitBox]

chatman commented on issue #768: SOLR-13472: Defer authorization to be done on 
forwarded nodes
URL: https://github.com/apache/lucene-solr/pull/768#issuecomment-525813230
 
 
   @anshumg, apologies for the confusion. This is already merged, but I forgot 
to close the PR after merging.


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] chatman closed pull request #768: SOLR-13472: Defer authorization to be done on forwarded nodes

[GitBox]

chatman closed pull request #768: SOLR-13472: Defer authorization to be done on 
forwarded nodes
URL: https://github.com/apache/lucene-solr/pull/768
 
 
   


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] anshumg commented on issue #768: SOLR-13472: Defer authorization to be done on forwarded nodes

[GitBox]

anshumg commented on issue #768: SOLR-13472: Defer authorization to be done on 
forwarded nodes
URL: https://github.com/apache/lucene-solr/pull/768#issuecomment-525812178
 
 
   Should've checked the code, this is already merged directly. Let's close 
this one out @chatman ?


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

MarcusSorealheis commented on a change in pull request #805: SOLR-13649 change 
the default behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#discussion_r318664696
 
 

 ##
 File path: 
solr/core/src/test/org/apache/solr/security/BasicAuthStandaloneTest.java
 ##
 @@ -96,35 +96,35 @@ public void testBasicAuth() throws Exception {
   String baseUrl = buildUrl(jetty.getLocalPort(), "/solr"); 
   httpSolrClient = getHttpSolrClient(baseUrl);
   
-  verifySecurityStatus(cl, baseUrl + authcPrefix, "/errorMessages", null, 
20);
 
 Review comment:
   @janhoy Ok, I've made this change and the associated changes. Thanks so much 
for the review. 


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13257) Enable replica routing affinity for better cache usage

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917861#comment-16917861
 ] 

ASF subversion and git services commented on SOLR-13257:


Commit 7c101fba4a38e8cd1240d2ee057dc0329f52fea1 in lucene-solr's branch 
refs/heads/branch_8x from Anshum Gupta
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7c101fb ]

SOLR-13257: Cleanup code and make the AffinityReplicaTransformer constructors 
private (#848) (#849)

SOLR-13257: Cleanup code and make the constructors private as the constructor 
is supposed to be called via the static getInstance method.

> Enable replica routing affinity for better cache usage
> --
>
> Key: SOLR-13257
> URL: https://issues.apache.org/jira/browse/SOLR-13257
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Michael Gibney
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: master (9.0), 8.3
>
> Attachments: AffinityShardHandlerFactory.java, SOLR-13257.patch, 
> SOLR-13257.patch
>
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> For each shard in a distributed request, Solr currently routes each request 
> randomly via 
> [ShufflingReplicaListTransformer|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/ShufflingReplicaListTransformer.java]
>  to a particular replica. In setups with replication factor >1, this normally 
> results in a situation where subsequent requests (which one would hope/expect 
> to leverage cached results from previous related requests) end up getting 
> routed to a replica that hasn't seen any related requests.
> The problem can be replicated by issuing a relatively expensive query (maybe 
> containing common terms?). The first request initializes the 
> {{queryResultCache}} on the consulted replicas. If replication factor >1 and 
> there are a sufficient number of shards, subsequent requests will likely be 
> routed to at least one replica that _hasn't_ seen the query before. The 
> replicas with uninitialized caches become a bottleneck, and from the client's 
> perspective, many subsequent requests appear not to benefit from caching at 
> all.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13257) Enable replica routing affinity for better cache usage

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917862#comment-16917862
 ] 

ASF subversion and git services commented on SOLR-13257:


Commit 7c101fba4a38e8cd1240d2ee057dc0329f52fea1 in lucene-solr's branch 
refs/heads/branch_8x from Anshum Gupta
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7c101fb ]

SOLR-13257: Cleanup code and make the AffinityReplicaTransformer constructors 
private (#848) (#849)

SOLR-13257: Cleanup code and make the constructors private as the constructor 
is supposed to be called via the static getInstance method.

> Enable replica routing affinity for better cache usage
> --
>
> Key: SOLR-13257
> URL: https://issues.apache.org/jira/browse/SOLR-13257
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Michael Gibney
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: master (9.0), 8.3
>
> Attachments: AffinityShardHandlerFactory.java, SOLR-13257.patch, 
> SOLR-13257.patch
>
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> For each shard in a distributed request, Solr currently routes each request 
> randomly via 
> [ShufflingReplicaListTransformer|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/ShufflingReplicaListTransformer.java]
>  to a particular replica. In setups with replication factor >1, this normally 
> results in a situation where subsequent requests (which one would hope/expect 
> to leverage cached results from previous related requests) end up getting 
> routed to a replica that hasn't seen any related requests.
> The problem can be replicated by issuing a relatively expensive query (maybe 
> containing common terms?). The first request initializes the 
> {{queryResultCache}} on the consulted replicas. If replication factor >1 and 
> there are a sufficient number of shards, subsequent requests will likely be 
> routed to at least one replica that _hasn't_ seen the query before. The 
> replicas with uninitialized caches become a bottleneck, and from the client's 
> perspective, many subsequent requests appear not to benefit from caching at 
> all.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] anshumg merged pull request #849: SOLR-13257: Cleanup code and make the AffinityReplicaTransformer constructors private (#848)

[GitBox]

anshumg merged pull request #849: SOLR-13257: Cleanup code and make the 
AffinityReplicaTransformer constructors private (#848)
URL: https://github.com/apache/lucene-solr/pull/849
 
 
   


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

MarcusSorealheis commented on a change in pull request #805: SOLR-13649 change 
the default behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#discussion_r318611751
 
 

 ##
 File path: 
solr/core/src/test/org/apache/solr/security/BasicAuthIntegrationTest.java
 ##
 @@ -114,7 +114,7 @@ public void testBasicAuth() throws Exception {
   String baseUrl = randomJetty.getBaseUrl().toString();
   verifySecurityStatus(cl, baseUrl + authcPrefix, "/errorMessages", null, 
20);
   zkClient().setData("/security.json", STD_CONF.replaceAll("'", 
"\"").getBytes(UTF_8), true);
-  verifySecurityStatus(cl, baseUrl + authcPrefix, "authentication/class", 
"solr.BasicAuthPlugin", 20);
+  verifySecurityStatus(cl, baseUrl + authcPrefix, "authentication/class", 
"solr.BasicAuthPlugin", 20, "solr", "SolrRocks");
 
 Review comment:
   Done. thanks for feedback


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-master - Build # 3637 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3637/

All tests passed

Build Log:
[...truncated 63973 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj199070987
 [ecj-lint] Compiling 1289 source files to /tmp/ecj199070987
 [ecj-lint] Processing annotations
 [ecj-lint] Annotations processed
 [ecj-lint] Processing annotations
 [ecj-lint] No elements to process
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
 (at line 219)
 [ecj-lint] return (NamedList) new 
JavaBinCodec(resolver).unmarshal(in);
 [ecj-lint]^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
 (at line 232)
 [ecj-lint] ReplicationHandler replicationHandler = (ReplicationHandler) 
handler;
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'replicationHandler' is never closed
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
 (at line 628)
 [ecj-lint] PeerSyncWithLeader peerSyncWithLeader = new 
PeerSyncWithLeader(core,
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'peerSyncWithLeader' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java
 (at line 186)
 [ecj-lint] PeerSync peerSync = new PeerSync(core, syncWith, 
core.getUpdateHandler().getUpdateLog().getNumRecordsToKeep(), true, 
peerSyncOnlyWithActive, false);
 [ecj-lint]  
 [ecj-lint] Resource leak: 'peerSync' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 5. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 788)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 6. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 794)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 7. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/CoreContainer.java
 (at line 726)
 [ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean();
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'fieldCacheBean' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 19)
 [ecj-lint] import javax.naming.Context;
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 20)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible
 [ecj-lint] --
 [ecj-lint] 10. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 21)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 11. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 

[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early 
Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-525754830
 
 
   @jimczi Thanks, I updated per your comments. Please let me know if it seems 
fine.
   
   RE: benchmarks, the numbers I posted earlier were on wikimedium10k. I did a 
run of wikimedium2m and saw the following:
   
   TaskQPS baseline  StdDevQPS my_modified_version  
StdDevPct diff
  HighTermMonthSort  256.49 (14.6%)  240.49 (13.0%)   
-6.2% ( -29% -   24%)
  HighTermDayOfYearSort  140.97  (8.4%)  137.26  (8.6%)   
-2.6% ( -18% -   15%)
 Fuzzy2   67.54 (20.4%)   65.90 (19.3%)   
-2.4% ( -34% -   46%)
MedTerm 1430.97  (4.8%) 1404.31  (4.2%)   
-1.9% ( -10% -7%)
 AndHighLow  859.98  (5.2%)  847.48  (4.1%)   
-1.5% ( -10% -8%)
Respell  111.18  (2.4%)  110.17  (2.5%)   
-0.9% (  -5% -4%)
Prefix3  278.56  (3.3%)  276.16  (2.5%)   
-0.9% (  -6% -5%)
LowTerm 1635.42  (5.3%) 1628.34  (3.2%)   
-0.4% (  -8% -8%)
 Fuzzy1   65.18 (11.5%)   64.94 (12.6%)   
-0.4% ( -21% -   26%)
   Wildcard  184.51  (3.0%)  183.97  (3.3%)   
-0.3% (  -6% -6%)
 HighPhrase  150.25  (2.8%)  149.83  (2.9%)   
-0.3% (  -5% -5%)
   PKLookup  124.37  (3.6%)  124.04  (3.4%)   
-0.3% (  -7% -7%)
   HighTerm  991.92  (4.7%)  990.52  (4.7%)   
-0.1% (  -9% -9%)
   BrowseDayOfYearTaxoFacets 9293.85  (4.9%) 9291.07  (5.4%)   
-0.0% (  -9% -   10%)
LowSloppyPhrase  143.41  (1.9%)  143.38  (2.1%)   
-0.0% (  -3% -4%)
  BrowseMonthSSDVFacets   43.43  (0.9%)   43.42  (1.0%)   
-0.0% (  -1% -1%)
  MedPhrase   93.36  (1.5%)   93.41  (2.2%)
0.0% (  -3% -3%)
   HighSloppyPhrase   43.97  (2.4%)   43.99  (2.4%)
0.1% (  -4% -5%)
MedSloppyPhrase  108.07  (2.1%)  108.15  (1.8%)
0.1% (  -3% -4%)
   BrowseDayOfYearSSDVFacets   38.85  (0.6%)   38.88  (0.5%)
0.1% (  -1% -1%)
  LowPhrase  181.55  (1.8%)  181.82  (1.6%)
0.1% (  -3% -3%)
MedSpanNear   66.17  (4.4%)   66.28  (3.0%)
0.2% (  -7% -8%)
   HighSpanNear  110.26  (3.3%)  110.57  (2.6%)
0.3% (  -5% -6%)
LowSpanNear   84.69  (1.9%)   84.94  (2.0%)
0.3% (  -3% -4%)
   HighIntervalsOrdered   47.21  (0.9%)   47.37  (1.5%)
0.3% (  -1% -2%)
AndHighHigh  118.46  (4.3%)  119.01  (3.9%)
0.5% (  -7% -8%)
 AndHighMed  187.97  (3.8%)  188.85  (3.4%)
0.5% (  -6% -8%)
 OrHighHigh   79.07  (3.0%)   79.45  (2.5%)
0.5% (  -4% -6%)
 IntNRQ  238.67  (4.3%)  239.97  (3.5%)
0.5% (  -6% -8%)
  OrHighLow  429.26  (4.4%)  432.55  (3.3%)
0.8% (  -6% -8%)
  OrHighMed  170.16  (3.0%)  171.65  (2.8%)
0.9% (  -4% -6%)
   BrowseDateTaxoFacets   11.28  (2.6%)   11.39  (3.7%)
0.9% (  -5% -7%)
  BrowseMonthTaxoFacets 9470.41  (6.2%) 9584.95  (4.7%)
1.2% (  -9% -   12%)


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917769#comment-16917769
 ] 

Uwe Schindler commented on LUCENE-8951:
---

No idea, ask Infra. Did you get the moderation of my 3rd test mail?

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] jimczi commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

jimczi commented on a change in pull request #823: LUCENE-8939: Introduce 
Shared Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r318559088
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/TopFieldCollector.java
 ##
 @@ -282,6 +293,7 @@ public void collect(int doc) throws IOException {
   private static final ScoreDoc[] EMPTY_SCOREDOCS = new ScoreDoc[0];
 
   final int numHits;
+  final HitsThresholdChecker hitsThresholdChecker;
   final int totalHitsThreshold;
 
 Review comment:
   This is unused so we can remove it ?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] jimczi commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

jimczi commented on a change in pull request #823: LUCENE-8939: Introduce 
Shared Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r318562876
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/search/TopScoreDocCollector.java
 ##
 @@ -207,16 +210,23 @@ public static TopScoreDocCollector create(int numHits, 
ScoreDoc after, int total
 }
   }
 
-  final int totalHitsThreshold;
   ScoreDoc pqTop;
+  final HitsThresholdChecker hitsThresholdChecker;
 
   // prevents instantiation
-  TopScoreDocCollector(int numHits, int totalHitsThreshold) {
+  TopScoreDocCollector(int numHits, int totalHitsThreshold, 
HitsThresholdChecker hitsThresholdChecker) {
 
 Review comment:
   `totalHitsThreshold` is not needed


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] jimczi commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

jimczi commented on a change in pull request #823: LUCENE-8939: Introduce 
Shared Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r318563308
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/search/TopScoreDocCollector.java
 ##
 @@ -207,16 +210,23 @@ public static TopScoreDocCollector create(int numHits, 
ScoreDoc after, int total
 }
   }
 
-  final int totalHitsThreshold;
   ScoreDoc pqTop;
+  final HitsThresholdChecker hitsThresholdChecker;
 
   // prevents instantiation
-  TopScoreDocCollector(int numHits, int totalHitsThreshold) {
+  TopScoreDocCollector(int numHits, int totalHitsThreshold, 
HitsThresholdChecker hitsThresholdChecker) {
 super(new HitQueue(numHits, true));
-this.totalHitsThreshold = totalHitsThreshold;
+assert hitsThresholdChecker != null;
+
 // HitQueue implements getSentinelObject to return a ScoreDoc, so we know
 // that at this point top() is already initialized.
 pqTop = pq.top();
+this.hitsThresholdChecker = hitsThresholdChecker;
+  }
+
+  // Same as above but uses a local hits checker for hits threshold checks
+  TopScoreDocCollector(int numHits, int totalHitsThreshold) {
 
 Review comment:
   Same as `TopFieldCollector`, we should have a single constructor that takes 
a `HitsThresholdChecker` and build the `totalHitsThreshold` logic in the static 
function.


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] jimczi commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

jimczi commented on a change in pull request #823: LUCENE-8939: Introduce 
Shared Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r318562576
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/TopFieldCollector.java
 ##
 @@ -414,6 +428,45 @@ public static TopFieldCollector create(Sort sort, int 
numHits, FieldDoc after,
 }
   }
 
+  /**
+   * Same as above with an additional parameter to allow passing in the 
threshold checker
+   */
+  public static TopFieldCollector create(Sort sort, int numHits, FieldDoc 
after,
+ int totalHitsThreshold, 
HitsThresholdChecker hitsThresholdChecker) {
 
 Review comment:
   We don't need the `totalHitsThreshold` here, is it possible to move the 
argument validation (totalHitsThreshold < 0) in the HitsThresholdChecker ctr ?


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] jimczi commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

jimczi commented on a change in pull request #823: LUCENE-8939: Introduce 
Shared Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r318559370
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/TopFieldCollector.java
 ##
 @@ -297,10 +309,12 @@ public void collect(int doc) throws IOException {
   // internal versions. If someone will define a constructor with any other
   // visibility, then anyone will be able to extend the class, which is not 
what
   // we want.
-  private TopFieldCollector(FieldValueHitQueue pq, int numHits, int 
totalHitsThreshold, boolean needsScores) {
+  private TopFieldCollector(FieldValueHitQueue pq, int numHits, int 
totalHitsThreshold,
 
 Review comment:
   We don't need the `totalHitsThreshold` if we have the `hitsThresholdChecker` 
below


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] jimczi commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

jimczi commented on a change in pull request #823: LUCENE-8939: Introduce 
Shared Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r318562103
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/TopFieldCollector.java
 ##
 @@ -200,6 +204,12 @@ public PagingFieldCollector(Sort sort, 
FieldValueHitQueue queue, FieldDoc
   }
 }
 
+// Default case -- single threaded execution
+public PagingFieldCollector(Sort sort, FieldValueHitQueue queue, 
FieldDoc after, int numHits,
+int totalHitsThreshold) {
 
 Review comment:
   We should have a single ctr


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] jimczi commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

jimczi commented on a change in pull request #823: LUCENE-8939: Introduce 
Shared Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r318561896
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/TopFieldCollector.java
 ##
 @@ -96,16 +96,21 @@ private static boolean canEarlyTerminateOnPrefix(Sort 
searchSort, Sort indexSort
* document scores and maxScore.
*/
   private static class SimpleFieldCollector extends TopFieldCollector {
-
 final Sort sort;
 final FieldValueHitQueue queue;
 
-public SimpleFieldCollector(Sort sort, FieldValueHitQueue queue, 
int numHits, int totalHitsThreshold) {
-  super(queue, numHits, totalHitsThreshold, sort.needsScores());
+public SimpleFieldCollector(Sort sort, FieldValueHitQueue queue, 
int numHits, int totalHitsThreshold,
+HitsThresholdChecker hitsThresholdChecker) {
+  super(queue, numHits, totalHitsThreshold, hitsThresholdChecker, 
sort.needsScores());
   this.sort = sort;
   this.queue = queue;
 }
 
+/* Default case -- Single threaded execution */
+public SimpleFieldCollector(Sort sort, FieldValueHitQueue queue, 
int numHits, int totalHitsThreshold) {
 
 Review comment:
   Could we replace this ctr with a static function that calls 
`TopFieldCollector#create` with the appropriate `LocalHitsThresholdChecker`? 
This way we don't need to reimplement the logic to create 
`SimpleFieldCollector` or `PagingCollector` twice, e.g.:
   
   public static TopFieldCollector create(Sort sort, int numHits, FieldDoc 
after, int totalHitsThreshold) {
   if (totalHitsThreshold < 0) {
 throw new IllegalArgumentException("totalHitsThreshold must be >= 0, 
got " + totalHitsThreshold);
   }
   return create(sort, numHits, new 
LocalHitsThresholdChecker(totalHitsThreshold));
   } 
   `
   


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] atris edited a comment on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

atris edited a comment on issue #823: LUCENE-8939: Introduce Shared Count Early 
Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-525720523
 
 
   @jimczi Updated the PR with implementation for `TopScoreDocsCollector`. 
Haven't added the corresponding `CollectorManager` yet though, I presume that 
can be done separately?
   
   Luceneutil numbers on the latest version:
   ```
 TaskQPS baseline  StdDevQPS my_modified_version  
StdDevPct diff
MedSloppyPhrase  498.64  (6.9%)  484.94 (16.3%)   
-2.7% ( -24% -   21%)
   HighIntervalsOrdered  303.56 (10.5%)  296.03 (11.8%)   
-2.5% ( -22% -   22%)
   BrowseDateTaxoFacets 3366.36  (5.2%) 3328.48  (5.4%)   
-1.1% ( -11% -9%)
   HighSloppyPhrase  500.45  (8.4%)  496.32  (9.1%)   
-0.8% ( -16% -   18%)
 IntNRQ 1108.56  (3.3%) 1104.31  (4.6%)   
-0.4% (  -7% -7%)
 Fuzzy1  321.49  (4.8%)  320.92  (4.1%)   
-0.2% (  -8% -9%)
 HighPhrase  571.71  (9.5%)  571.13  (8.8%)   
-0.1% ( -16% -   20%)
Respell  386.71  (8.4%)  386.35  (8.1%)   
-0.1% ( -15% -   17%)
AndHighHigh  807.05  (2.5%)  806.66  (4.2%)   
-0.0% (  -6% -6%)
HighTermDayOfYearSort  733.99  (4.4%)  733.77  (5.6%)   
-0.0% (  -9% -   10%)
  OrHighLow 1158.52  (1.7%) 1159.52  (3.6%)
0.1% (  -5% -5%)
   BrowseDayOfYearTaxoFacets 8364.69  (2.9%) 8375.25  (2.8%)
0.1% (  -5% -5%)
  BrowseMonthSSDVFacets 1999.10  (2.9%) 2005.14  (3.8%)
0.3% (  -6% -7%)
  BrowseMonthTaxoFacets 8403.68  (2.5%) 8430.34  (3.5%)
0.3% (  -5% -6%)
MedTerm 3481.42  (3.0%) 3495.13  (3.0%)
0.4% (  -5% -6%)
  MedPhrase  813.12  (4.0%)  816.40  (4.0%)
0.4% (  -7% -8%)
   BrowseDayOfYearSSDVFacets 1762.24  (2.9%) 1770.51  (4.5%)
0.5% (  -6% -8%)
  OrHighMed  408.00  (3.8%)  409.94  (4.7%)
0.5% (  -7% -9%)
   PKLookup  148.60  (3.5%)  149.33  (6.3%)
0.5% (  -9% -   10%)
  HighTermMonthSort 1869.60 (12.7%) 1879.81 (13.1%)
0.5% ( -22% -   30%)
   Wildcard  898.93  (3.8%)  903.87  (3.7%)
0.5% (  -6% -8%)
   HighTerm 2075.22  (3.2%) 2088.85  (2.9%)
0.7% (  -5% -6%)
  LowPhrase  610.73  (4.6%)  617.56  (3.8%)
1.1% (  -6% -9%)
LowSloppyPhrase  825.44  (3.2%)  835.72  (3.3%)
1.2% (  -5% -7%)
LowSpanNear 1388.73  (2.2%) 1409.14  (2.8%)
1.5% (  -3% -6%)
 AndHighLow 3047.72  (5.5%) 3096.11  (5.9%)
1.6% (  -9% -   13%)
MedSpanNear  750.19  (2.9%)  763.02  (2.0%)
1.7% (  -3% -6%)
LowTerm 3670.47  (3.6%) 3736.25  (4.9%)
1.8% (  -6% -   10%)
   HighSpanNear  401.49  (5.4%)  408.94  (4.5%)
1.9% (  -7% -   12%)
Prefix3  390.52  (9.0%)  397.98  (7.5%)
1.9% ( -13% -   20%)
 OrHighHigh  319.58 (15.3%)  326.27  (9.9%)
2.1% ( -20% -   32%)
 AndHighMed 1011.67  (3.5%) 1035.03  (3.8%)
2.3% (  -4% -9%)
 Fuzzy2   37.75 (25.1%)   39.47 (24.4%)
4.6% ( -35% -   72%)
   ```


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[David Smiley (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917738#comment-16917738
 ] 

David Smiley commented on LUCENE-8951:
--

Ugh; why do mailing lists have to be such a usability nightmare.  Ancient 
software.

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] atris edited a comment on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

atris edited a comment on issue #823: LUCENE-8939: Introduce Shared Count Early 
Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-525720523
 
 
   @jimczi Updated the PR with implementation for `TopScoreDocsCollector`. 
Haven't added the corresponding `CollectorManager` yet though, I presume that 
can be done separately?
   
   Luceneutil numbers on the latest version:
   
 TaskQPS baseline  StdDevQPS my_modified_version  
StdDevPct diff
MedSloppyPhrase  498.64  (6.9%)  484.94 (16.3%)   
-2.7% ( -24% -   21%)
   HighIntervalsOrdered  303.56 (10.5%)  296.03 (11.8%)   
-2.5% ( -22% -   22%)
   BrowseDateTaxoFacets 3366.36  (5.2%) 3328.48  (5.4%)   
-1.1% ( -11% -9%)
   HighSloppyPhrase  500.45  (8.4%)  496.32  (9.1%)   
-0.8% ( -16% -   18%)
 IntNRQ 1108.56  (3.3%) 1104.31  (4.6%)   
-0.4% (  -7% -7%)
 Fuzzy1  321.49  (4.8%)  320.92  (4.1%)   
-0.2% (  -8% -9%)
 HighPhrase  571.71  (9.5%)  571.13  (8.8%)   
-0.1% ( -16% -   20%)
Respell  386.71  (8.4%)  386.35  (8.1%)   
-0.1% ( -15% -   17%)
AndHighHigh  807.05  (2.5%)  806.66  (4.2%)   
-0.0% (  -6% -6%)
  HighTermDayOfYearSort  733.99  (4.4%)  733.77  (5.6%)   
-0.0% (  -9% -   10%)
  OrHighLow 1158.52  (1.7%) 1159.52  (3.6%)
0.1% (  -5% -5%)
   BrowseDayOfYearTaxoFacets 8364.69  (2.9%) 8375.25  (2.8%)
0.1% (  -5% -5%)
  BrowseMonthSSDVFacets 1999.10  (2.9%) 2005.14  (3.8%)
0.3% (  -6% -7%)
  BrowseMonthTaxoFacets 8403.68  (2.5%) 8430.34  (3.5%)
0.3% (  -5% -6%)
MedTerm 3481.42  (3.0%) 3495.13  (3.0%)
0.4% (  -5% -6%)
  MedPhrase  813.12  (4.0%)  816.40  (4.0%)
0.4% (  -7% -8%)
   BrowseDayOfYearSSDVFacets 1762.24  (2.9%) 1770.51  (4.5%)
0.5% (  -6% -8%)
  OrHighMed  408.00  (3.8%)  409.94  (4.7%)
0.5% (  -7% -9%)
   PKLookup  148.60  (3.5%)  149.33  (6.3%)
0.5% (  -9% -   10%)
  HighTermMonthSort 1869.60 (12.7%) 1879.81 (13.1%)
0.5% ( -22% -   30%)
   Wildcard  898.93  (3.8%)  903.87  (3.7%)
0.5% (  -6% -8%)
   HighTerm 2075.22  (3.2%) 2088.85  (2.9%)
0.7% (  -5% -6%)
  LowPhrase  610.73  (4.6%)  617.56  (3.8%)
1.1% (  -6% -9%)
LowSloppyPhrase  825.44  (3.2%)  835.72  (3.3%)
1.2% (  -5% -7%)
LowSpanNear 1388.73  (2.2%) 1409.14  (2.8%)
1.5% (  -3% -6%)
 AndHighLow 3047.72  (5.5%) 3096.11  (5.9%)
1.6% (  -9% -   13%)
MedSpanNear  750.19  (2.9%)  763.02  (2.0%)
1.7% (  -3% -6%)
LowTerm 3670.47  (3.6%) 3736.25  (4.9%)
1.8% (  -6% -   10%)
   HighSpanNear  401.49  (5.4%)  408.94  (4.5%)
1.9% (  -7% -   12%)
Prefix3  390.52  (9.0%)  397.98  (7.5%)
1.9% ( -13% -   20%)
 OrHighHigh  319.58 (15.3%)  326.27  (9.9%)
2.1% ( -20% -   32%)
 AndHighMed 1011.67  (3.5%) 1035.03  (3.8%)
2.3% (  -4% -9%)
 Fuzzy2   37.75 (25.1%)   39.47 (24.4%)
4.6% ( -35% -   72%)
   


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early 
Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-525720523
 
 
   @jimczi Updated the PR with implementation for `TopScoreDocsCollector'. 
Haven't added the corresponding `CollectorManager` yet though, I presume that 
can be done separately?
   
   Luceneutil numbers on the latest version:
   
 TaskQPS baseline  StdDevQPS my_modified_version  
StdDevPct diff
MedSloppyPhrase  498.64  (6.9%)  484.94 (16.3%)   
-2.7% ( -24% -   21%)
   HighIntervalsOrdered  303.56 (10.5%)  296.03 (11.8%)   
-2.5% ( -22% -   22%)
   BrowseDateTaxoFacets 3366.36  (5.2%) 3328.48  (5.4%)   
-1.1% ( -11% -9%)
   HighSloppyPhrase  500.45  (8.4%)  496.32  (9.1%)   
-0.8% ( -16% -   18%)
 IntNRQ 1108.56  (3.3%) 1104.31  (4.6%)   
-0.4% (  -7% -7%)
 Fuzzy1  321.49  (4.8%)  320.92  (4.1%)   
-0.2% (  -8% -9%)
 HighPhrase  571.71  (9.5%)  571.13  (8.8%)   
-0.1% ( -16% -   20%)
Respell  386.71  (8.4%)  386.35  (8.1%)   
-0.1% ( -15% -   17%)
AndHighHigh  807.05  (2.5%)  806.66  (4.2%)   
-0.0% (  -6% -6%)
  HighTermDayOfYearSort  733.99  (4.4%)  733.77  (5.6%)   
-0.0% (  -9% -   10%)
  OrHighLow 1158.52  (1.7%) 1159.52  (3.6%)
0.1% (  -5% -5%)
   BrowseDayOfYearTaxoFacets 8364.69  (2.9%) 8375.25  (2.8%)
0.1% (  -5% -5%)
  BrowseMonthSSDVFacets 1999.10  (2.9%) 2005.14  (3.8%)
0.3% (  -6% -7%)
  BrowseMonthTaxoFacets 8403.68  (2.5%) 8430.34  (3.5%)
0.3% (  -5% -6%)
MedTerm 3481.42  (3.0%) 3495.13  (3.0%)
0.4% (  -5% -6%)
  MedPhrase  813.12  (4.0%)  816.40  (4.0%)
0.4% (  -7% -8%)
   BrowseDayOfYearSSDVFacets 1762.24  (2.9%) 1770.51  (4.5%)
0.5% (  -6% -8%)
  OrHighMed  408.00  (3.8%)  409.94  (4.7%)
0.5% (  -7% -9%)
   PKLookup  148.60  (3.5%)  149.33  (6.3%)
0.5% (  -9% -   10%)
  HighTermMonthSort 1869.60 (12.7%) 1879.81 (13.1%)
0.5% ( -22% -   30%)
   Wildcard  898.93  (3.8%)  903.87  (3.7%)
0.5% (  -6% -8%)
   HighTerm 2075.22  (3.2%) 2088.85  (2.9%)
0.7% (  -5% -6%)
  LowPhrase  610.73  (4.6%)  617.56  (3.8%)
1.1% (  -6% -9%)
LowSloppyPhrase  825.44  (3.2%)  835.72  (3.3%)
1.2% (  -5% -7%)
LowSpanNear 1388.73  (2.2%) 1409.14  (2.8%)
1.5% (  -3% -6%)
 AndHighLow 3047.72  (5.5%) 3096.11  (5.9%)
1.6% (  -9% -   13%)
MedSpanNear  750.19  (2.9%)  763.02  (2.0%)
1.7% (  -3% -6%)
LowTerm 3670.47  (3.6%) 3736.25  (4.9%)
1.8% (  -6% -   10%)
   HighSpanNear  401.49  (5.4%)  408.94  (4.5%)
1.9% (  -7% -   12%)
Prefix3  390.52  (9.0%)  397.98  (7.5%)
1.9% ( -13% -   20%)
 OrHighHigh  319.58 (15.3%)  326.27  (9.9%)
2.1% ( -20% -   32%)
 AndHighMed 1011.67  (3.5%) 1035.03  (3.8%)
2.3% (  -4% -9%)
 Fuzzy2   37.75 (25.1%)   39.47 (24.4%)
4.6% ( -35% -   72%)
   


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[Jira]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917702#comment-16917702
 ] 

Jan Høydahl commented on LUCENE-8951:
-

I ran the {{allow-list}} command and got this reply
{noformat}
Fra: builds-allow-h...@lucene.apache.org
Emne: Subscriber list for bui...@lucene.apache.org
Dato: 28. august 2019 kl. 13:34:58 CEST
Til: jan...@apache.org

Hi! This is the ezmlm program. I'm managing the
builds-al...@lucene.apache.org mailing list.

I'm working for my owner, who can be reached
at builds-allow-ow...@lucene.apache.org.

Subscribers to this list are:
jenk...@thetaphi.de

 ==> 1{noformat}

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[Jira]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917700#comment-16917700
 ] 

Jan Høydahl commented on LUCENE-8951:
-

What I did 2 days ago was sent an email to 
{{builds-allow-subscribe-jenkins=thetaphi...@lucene.apache.org}} (using 
[https://whimsy.apache.org/committers/moderationhelper] to help build the 
command), and then got a response
{noformat}
Hi! This is the ezmlm program. I'm managing the
builds-al...@lucene.apache.org mailing list.

I'm working for my owner, who can be reached
at builds-allow-ow...@lucene.apache.org.

I respectfully request your permission to add

  jenk...@thetaphi.de

to the subscribers of the builds-allow mailing list. This request
either came from you, or it has already been verified by
the potential subscriber.

To confirm, please send a short reply to this address:

  
builds-allow-rc.1566814551.iejafhgalokpajfflood-jenkins=thetaphi...@lucene.apache.org
... {noformat}
I tried replying to that mail but obviously it is still not added. I think 
maybe the reply has to come from that email itself? I'm not very steady in 
ezmlm commands.

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] jimczi commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

jimczi commented on issue #823: LUCENE-8939: Introduce Shared Count Early 
Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-525703089
 
 
   > Should we commit this then, and then follow up on the other JIRA that I 
opened?
   
   Let's benchmark `TopScoreDocCollector` first since the logic is already 
implemented ?


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early 
Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-525695991
 
 
   > > Looks like the performance is consistent and we see no degradation. WDYT?
   > 
   > I don't think that these tasks use a `TopFieldDocCollector` with early 
termination ? This is why I said that it would be easier to test with the 
`TopScoreDocCollector`.
   
   I thought some of the tasks do, but apparently not.
   
   Should we commit this then, and then follow up on the other JIRA that I 
opened?


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917666#comment-16917666
 ] 

Uwe Schindler edited comment on LUCENE-8951 at 8/28/19 10:51 AM:
-

FYI, please DO NOT SUBSCRIBE jenk...@thetaphi.de This mail cannot receive 
mails, all mail coming in is rejected with some special error code and 
mailer-daemon message. It's only to send mails (a typing do-dot-reply one). If 
yozu subscribe it, the ML will remove him asap because of error code. So you 
must put it on the ALLOW list of the mailing list, not the subscription list.


was (Author: thetaphi):
FYI, please DO NOT SUBSCRIBE jenk...@thetaphi.de This mail cannot receive 
mails, all mail coming in is rejected with some special error code and 
mailer-daemon message. It's only to sent mails (a typing do-dot-reply one). If 
yozu subscribe it, the ML will remove him asap because of error code. So you 
must put it on the ALLOW list of the mailing list, not the subscription list.

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917666#comment-16917666
 ] 

Uwe Schindler edited comment on LUCENE-8951 at 8/28/19 10:50 AM:
-

FYI, please DO NOT SUBSCRIBE jenk...@thetaphi.de This mail cannot receive 
mails, all mail coming in is rejected with some special error code and 
mailer-daemon message. It's only to sent mails (a typing do-dot-reply one). If 
yozu subscribe it, the ML will remove him asap because of error code. So you 
must put it on the ALLOW list of the mailing list, not the subscription list.


was (Author: thetaphi):
FYI, please DO NOT SUBSCRIBE jenk...@thetaphi.de This mail cannot receive 
mails, all mail coming in is rejected with some special error code and 
mailer-daemon message. It's only to sent mails (a typing do-dot-reply one). If 
yozu subscribe it, the ML will remove him forevwer. So you must put it on the 
ALLOW list of the mailing list, not the subscription list.

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917666#comment-16917666
 ] 

Uwe Schindler commented on LUCENE-8951:
---

FYI, please DO NOT SUBSCRIBE jenk...@thetaphi.de This mail cannot receive 
mails, all mail coming in is rejected with some special error code and 
mailer-daemon message. It's only to sent mails (a typing do-dot-reply one). If 
yozu subscribe it, the ML will remove him forevwer. So you must put it on the 
ALLOW list of the mailing list, not the subscription list.

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-repro - Build # 3574 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/3574/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/194/consoleText

[repro] Revision: 8459fde68e1a5d96c745ff528ed5cbb3921900f4

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=ShardSplitTest 
-Dtests.method=testSplitWithChaosMonkey -Dtests.seed=97BB7CA1C967B0B 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=is -Dtests.timezone=Indian/Reunion -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=ShardSplitTest 
-Dtests.seed=97BB7CA1C967B0B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=is -Dtests.timezone=Indian/Reunion -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
62f55c073c2bdc478db4254065857a1b9c6e8da4
[repro] git fetch
[repro] git checkout 8459fde68e1a5d96c745ff528ed5cbb3921900f4

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   ShardSplitTest
[repro] ant compile-test

[...truncated 3579 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.ShardSplitTest" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=97BB7CA1C967B0B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=is -Dtests.timezone=Indian/Reunion -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[...truncated 84106 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   1/5 failed: org.apache.solr.cloud.api.collections.ShardSplitTest
[repro] git checkout 62f55c073c2bdc478db4254065857a1b9c6e8da4

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917661#comment-16917661
 ] 

Uwe Schindler commented on LUCENE-8951:
---

I sent another one, I keep it up to your to enable (maybe I have not enough 
rights on the laist). The CC address of the moderation mail is the the one to 
allow the sender forever (this is why reply-all works).

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] jimczi edited a comment on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

jimczi edited a comment on issue #823: LUCENE-8939: Introduce Shared Count 
Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-525687970
 
 
   > Looks like the performance is consistent and we see no degradation. WDYT?
   
   I don't think that these tasks use a `TopFieldDocCollector` with early 
termination ? This is why I said that it would be easier to test with the 
`TopScoreDocCollector`.


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] jimczi commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search

[GitBox]

jimczi commented on issue #823: LUCENE-8939: Introduce Shared Count Early 
Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-525687970
 
 
   > Looks like the performance is consistent and we see no degradation. WDYT?
   
   I don't think that these tasks use a `TopFieldDocCollector` with early 
termination ? This is why I said that it would be easier to test with the 
`TopScoreDocCollector` ?


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917659#comment-16917659
 ] 

Uwe Schindler commented on LUCENE-8951:
---

Hi, I sent a test email, but it went to moderation. I then used replay-all, to 
put the mail on the allow list of the ML, but it did not help (it sent it to 2 
mails, accept-xxx@ and allow-xxx@). I did a 2nd test mail was also stuck in 
moderation.

Maybe somebody has to manually put the mail on the allow list.

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917637#comment-16917637
 ] 

Uwe Schindler commented on LUCENE-8951:
---

OK, I changed Policeman Jenkins. I will send a test e-mail, but before that I 
will subscribe to both new lists.

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] iverase commented on a change in pull request #844: LUCENE-8860: Make more decision on inner nodes in ShapeBoundingBoxQuery

[GitBox]

iverase commented on a change in pull request #844: LUCENE-8860: Make more 
decision on inner nodes in ShapeBoundingBoxQuery
URL: https://github.com/apache/lucene-solr/pull/844#discussion_r318499448
 
 

 ##
 File path: 
lucene/sandbox/src/java/org/apache/lucene/document/LatLonShapeBoundingBoxQuery.java
 ##
 @@ -42,7 +42,8 @@ public LatLonShapeBoundingBoxQuery(String field, 
QueryRelation queryRelation, do
   @Override
   protected Relation relateRangeBBoxToQuery(int minXOffset, int minYOffset, 
byte[] minTriangle,
 int maxXOffset, int maxYOffset, 
byte[] maxTriangle) {
-return rectangle2D.relateRangeBBox(minXOffset, minYOffset, minTriangle, 
maxXOffset, maxYOffset, maxTriangle);
+return rectangle2D.relateRangeBBox(minXOffset, minYOffset, minTriangle, 
maxXOffset, maxYOffset, maxTriangle,
+queryRelation == QueryRelation.INTERSECTS);
 
 Review comment:
   Shouldn't this work as well for Disjoint?


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] iverase commented on a change in pull request #844: LUCENE-8860: Make more decision on inner nodes in ShapeBoundingBoxQuery

[GitBox]

iverase commented on a change in pull request #844: LUCENE-8860: Make more 
decision on inner nodes in ShapeBoundingBoxQuery
URL: https://github.com/apache/lucene-solr/pull/844#discussion_r318499931
 
 

 ##
 File path: lucene/sandbox/src/java/org/apache/lucene/geo/Rectangle2D.java
 ##
 @@ -183,6 +191,33 @@ private static Relation compareBBoxToRangeBBox(final 
byte[] bbox,
 Arrays.compareUnsigned(maxTriangle, maxYOffset, maxYOffset + BYTES, 
bbox, 2 * BYTES, 3 * BYTES) <= 0) {
   return Relation.CELL_INSIDE_QUERY;
 }
+
 
 Review comment:
   This first check can be skipped for intersects? maybe add it in an else 
statement


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] iverase commented on a change in pull request #844: LUCENE-8860: Make more decision on inner nodes in ShapeBoundingBoxQuery

[GitBox]

iverase commented on a change in pull request #844: LUCENE-8860: Make more 
decision on inner nodes in ShapeBoundingBoxQuery
URL: https://github.com/apache/lucene-solr/pull/844#discussion_r318499581
 
 

 ##
 File path: 
lucene/sandbox/src/java/org/apache/lucene/document/XYShapeBoundingBoxQuery.java
 ##
 @@ -41,7 +41,8 @@ public XYShapeBoundingBoxQuery(String field, QueryRelation 
queryRelation, double
   @Override
   protected PointValues.Relation relateRangeBBoxToQuery(int minXOffset, int 
minYOffset, byte[] minTriangle,
 int maxXOffset, int 
maxYOffset, byte[] maxTriangle) {
-return rectangle2D.relateRangeBBox(minXOffset, minYOffset, minTriangle, 
maxXOffset, maxYOffset, maxTriangle);
+return rectangle2D.relateRangeBBox(minXOffset, minYOffset, minTriangle, 
maxXOffset, maxYOffset, maxTriangle,
+queryRelation == QueryRelation.INTERSECTS);
 
 Review comment:
   Shouldn't this work as well for Disjoint?


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Problem of Shutdown Process for Windows Server

[Kayak28]

Hello, Community:

I use Solr with Windows servers, and cannot shutdown Solr successfully.
When I try to stop Solr using solr.cmd, which is kicked from Windows Task
Manager, it "looks" like Solr stops without any problem.
Here "looks" means that at least log file that Solr wrote does not seem to
have any error.
(I pasted a piece of the log where I believe "success" at the end of this
email )

However, next time I start up the Solr, I face the error message that says
"Address already in use."

This problem happens occasionally, happens a different server at irregular
time/date.
So, I could not simulate the situation yet.
I wonder why Solr could not shutdown successfully.

If anyone of you has faced a similar incident or knows a solution, then it
is very helpful to share your bits of advice.
Any clue will be very appreciated.


*Environment*
OS: Windows Server 2012 R2
Java: Oracle JDK 1.8.0
Solr  Version: 5.2.1
Solr Structures:15 Solr server, enabled to distributed search with sharding
(Not using SolrCloud)
Memory(Solr / physical) : 20GB/32GB
Index Size: around 300GB

*Logs*
INFO  - 2019-05-25 21:06:15.996; [   ]
org.apache.solr.core.CachingDirectoryFactory; looking to close
D:\Documents\solr-home\collection1\data
[CachedDir<>]
INFO  - 2019-05-25 21:06:15.996; [   ]
org.apache.solr.core.CachingDirectoryFactory; Closing directory:
D:\Documents\solr-home\collection1\data
INFO  - 2019-05-25 21:06:15.996; [   ]
org.apache.solr.core.CachingDirectoryFactory; looking to close
D:\Documents\solr-home\collection1\data\index
[CachedDir<>]
INFO  - 2019-05-25 21:06:15.996; [   ]
org.apache.solr.core.CachingDirectoryFactory; Closing directory:
D:\Documents\solr-home\collection1\data\index
INFO  - 2019-05-25 21:06:16.199; [   ]
org.eclipse.jetty.server.handler.ContextHandler; Stopped
o.e.j.w.WebAppContext@4b9e13df
{/solr,file:/D:/Documents/solr/server/solr-webapp/webapp/,UNAVAILABLE}{/solr.war}

* Note: solr-home directory is the directory where I store Solr cores.

Sincerely,
Kaya Ota

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.3) - Build # 24623 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24623/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.core.TestSolrDeletionPolicy1.testNumCommitsConfigured

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([DBD81028BA3ADC8B:721B8A3A832064B]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.solr.core.TestSolrDeletionPolicy1.testNumCommitsConfigured(TestSolrDeletionPolicy1.java:108)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  org.apache.solr.core.TestSolrDeletionPolicy1.testNumCommitsConfigured

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([DBD81028BA3ADC8B:721B8A3A832064B]:0)
at org.junit.Assert.fail(Assert.java:86)
at 

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[Jira]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917583#comment-16917583
 ] 

Jan Høydahl commented on LUCENE-8951:
-

{quote}I didn't see anything come in. 
{quote}
No-one are auto subscribed to the new lists, will send out an email to dev@ to 
ask people to subscribe if they wish.

Also, I expect no emails have been sent to those lists either, so even if you 
are a moderator there has been nothing to moderate yet :)

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8566) Deprecate methods in CustomAnalyzer.Builder which take factory classes

[Tomoko Uchida (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917578#comment-16917578
 ] 

Tomoko Uchida commented on LUCENE-8566:
---

The Javadoc example was updated in LUCENE-8957.

> Deprecate methods in CustomAnalyzer.Builder which take factory classes
> --
>
> Key: LUCENE-8566
> URL: https://issues.apache.org/jira/browse/LUCENE-8566
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Uwe Schindler
>Priority: Minor
>
> CustomAnalyzer.Builder has methods which take implementation classes as 
> follows.
>  - withTokenizer(Class factory, String... params)
>  - withTokenizer(Class factory, 
> Map params)
>  - addTokenFilter(Class factory, String... 
> params)
>  - addTokenFilter(Class factory, 
> Map params)
>  - addCharFilter(Class factory, String... params)
>  - addCharFilter(Class factory, 
> Map params)
> Since the builder also has methods which take service names, it seems like 
> that above methods are unnecessary and a little bit misleading. Giving 
> symbolic names is preferable to implementation factory classes, but for now, 
> users can write code depending on implementation classes.
> What do you think about deprecating those methods (adding {{@Deprecated}} 
> annotations) and deleting them in the future releases? Those are called by 
> only test cases so deleting them should have no impact on current lucene/solr 
> codebase.
> If this proposal gains your consent, I will create a patch. (Let me know if I 
> missed some point. I'll close it.)



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-8957) Update examples in CustomAnalyzer Javadocs

[Tomoko Uchida (Jira)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomoko Uchida resolved LUCENE-8957.
---
Fix Version/s: 8.3
   master (9.0)
   Resolution: Fixed

> Update examples in CustomAnalyzer Javadocs
> --
>
> Key: LUCENE-8957
> URL: https://issues.apache.org/jira/browse/LUCENE-8957
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0), 8.3
>
> Attachments: LUCENE-8957.patch
>
>
> CustomAnalyzer Javadocs need to be updated:
> - Remove {{StandardFilterFactory}} from examples
> - Use {{Factory.NAME}} instead of {{Factory.class}} in the examples



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8957) Update examples in CustomAnalyzer Javadocs

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917576#comment-16917576
 ] 

ASF subversion and git services commented on LUCENE-8957:
-

Commit 56f85884fe099529b0a8ed7bb6f7eac5161e45e4 in lucene-solr's branch 
refs/heads/branch_8x from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=56f8588 ]

LUCENE-8957: Update examples in CustomAnalyzar Javadocs


> Update examples in CustomAnalyzer Javadocs
> --
>
> Key: LUCENE-8957
> URL: https://issues.apache.org/jira/browse/LUCENE-8957
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: LUCENE-8957.patch
>
>
> CustomAnalyzer Javadocs need to be updated:
> - Remove {{StandardFilterFactory}} from examples
> - Use {{Factory.NAME}} instead of {{Factory.class}} in the examples



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8957) Update examples in CustomAnalyzer Javadocs

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917573#comment-16917573
 ] 

ASF subversion and git services commented on LUCENE-8957:
-

Commit 62f55c073c2bdc478db4254065857a1b9c6e8da4 in lucene-solr's branch 
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=62f55c0 ]

LUCENE-8957: Update examples in CustomAnalyzar Javadocs


> Update examples in CustomAnalyzer Javadocs
> --
>
> Key: LUCENE-8957
> URL: https://issues.apache.org/jira/browse/LUCENE-8957
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: LUCENE-8957.patch
>
>
> CustomAnalyzer Javadocs need to be updated:
> - Remove {{StandardFilterFactory}} from examples
> - Use {{Factory.NAME}} instead of {{Factory.class}} in the examples



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[Shawn Heisey (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917564#comment-16917564
 ] 

Shawn Heisey commented on LUCENE-8951:
--

I didn't see anything come in.  Will they sign up my @apache.org email address?

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-master - Build # 3635 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3635/

All tests passed

Build Log:
[...truncated 64978 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /tmp/ecj391831939
 [ecj-lint] Compiling 48 source files to /tmp/ecj391831939
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 23)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 28)
 [ecj-lint] public class MockInitialContextFactory implements 
InitialContextFactory {
 [ecj-lint]  ^
 [ecj-lint] The type MockInitialContextFactory must implement the inherited 
abstract method InitialContextFactory.getInitialContext(Hashtable)
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 30)
 [ecj-lint] private final javax.naming.Context context;
 [ecj-lint]   
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 33)
 [ecj-lint] context = mock(javax.naming.Context.class);
 [ecj-lint] ^^^
 [ecj-lint] context cannot be resolved to a variable
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 33)
 [ecj-lint] context = mock(javax.naming.Context.class);
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 36)
 [ecj-lint] when(context.lookup(anyString())).thenAnswer(invocation -> 
objects.get(invocation.getArgument(0)));
 [ecj-lint]  ^^^
 [ecj-lint] context cannot be resolved
 [ecj-lint] --
 [ecj-lint] 7. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 38)
 [ecj-lint] } catch (NamingException e) {
 [ecj-lint]  ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 45)
 [ecj-lint] public javax.naming.Context getInitialContext(Hashtable env) {
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 46)
 [ecj-lint] return context;
 [ecj-lint]^^^
 [ecj-lint] context cannot be resolved to a variable
 [ecj-lint] --
 [ecj-lint] 9 problems (9 errors)

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:634: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:101: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build.xml:651:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/common-build.xml:479:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2015:
 The following error occurred while executing this line:

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[Jira]

[ 
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917549#comment-16917549
 ] 

Jan Høydahl commented on LUCENE-8951:
-

[~thetaphi] perhaps you can try to send policeman jenkins results to the new 
list already, and confirm that it works. I'll get to the website updates and 
ANNOUNCE email later if no-one beats me to it.

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list (/)
>  # Subscribe all emails that will be allowed to post (/)
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] janhoy commented on a change in pull request #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

janhoy commented on a change in pull request #805: SOLR-13649 change the 
default behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#discussion_r318452959
 
 

 ##
 File path: 
solr/core/src/test/org/apache/solr/security/BasicAuthStandaloneTest.java
 ##
 @@ -96,35 +96,35 @@ public void testBasicAuth() throws Exception {
   String baseUrl = buildUrl(jetty.getLocalPort(), "/solr"); 
   httpSolrClient = getHttpSolrClient(baseUrl);
   
-  verifySecurityStatus(cl, baseUrl + authcPrefix, "/errorMessages", null, 
20);
 
 Review comment:
   > you cannot anymore, which makes sense
   
   With an explicit `blockUnknown=false` sure you can do anonymous requests if 
those are not covered by any of the permissions set up for authentication. So 
also this test class could be reverted to initial state and just explicitly set 
blockUnknown=false -- as long as blockUnknown=true is tested elsewhere.


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] janhoy commented on a change in pull request #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

janhoy commented on a change in pull request #805: SOLR-13649 change the 
default behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#discussion_r318451600
 
 

 ##
 File path: 
solr/core/src/test/org/apache/solr/security/BasicAuthIntegrationTest.java
 ##
 @@ -114,7 +114,7 @@ public void testBasicAuth() throws Exception {
   String baseUrl = randomJetty.getBaseUrl().toString();
   verifySecurityStatus(cl, baseUrl + authcPrefix, "/errorMessages", null, 
20);
   zkClient().setData("/security.json", STD_CONF.replaceAll("'", 
"\"").getBytes(UTF_8), true);
-  verifySecurityStatus(cl, baseUrl + authcPrefix, "authentication/class", 
"solr.BasicAuthPlugin", 20);
+  verifySecurityStatus(cl, baseUrl + authcPrefix, "authentication/class", 
"solr.BasicAuthPlugin", 20, "solr", "SolrRocks");
 
 Review comment:
   The `protected static final String STD_CONF` in that test class actually 
*does* define an initial user...


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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org