[jira] [Updated] (SOLR-9835) Create another replication mode for SolrCloud

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-9835:
---
Attachment: SOLR-9835.patch

[~shalinmangar] sure,
This is the updated patch, that I added doc for all new public methods at 
{{UpdateLog}}

> Create another replication mode for SolrCloud
> -
>
> Key: SOLR-9835
> URL: https://issues.apache.org/jira/browse/SOLR-9835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch
>
>
> The current replication mechanism of SolrCloud is called state machine, which 
> replicas start in same initial state and for each input, the input is 
> distributed across replicas so all replicas will end up with same next state. 
> But this type of replication have some drawbacks
> - The commit (which costly) have to run on all replicas
> - Slow recovery, because if replica miss more than N updates on its down 
> time, the replica have to download entire index from its leader.
> So we create create another replication mode for SolrCloud called state 
> transfer, which acts like master/slave replication. In basically
> - Leader distribute the update to other replicas, but the leader only apply 
> the update to IW, other replicas just store the update to UpdateLog (act like 
> replication).
> - Replicas frequently polling the latest segments from leader.
> Pros:
> - Lightweight for indexing, because only leader are running the commit, 
> updates.
> - Very fast recovery, replicas just have to download the missing segments.
> On CAP point of view, this ticket will trying to promise to end users a 
> distributed systems :
> - Partition tolerance
> - Weak Consistency for normal query : clusters can serve stale data. This 
> happen when leader finish a commit and slave is fetching for latest segment. 
> This period can at most {{pollInterval + time to fetch latest segment}}.
> - Consistency for RTG : if we *do not use DQBs*, replicas will consistence 
> with master just like original SolrCloud mode
> - Weak Availability : just like original SolrCloud mode. If a leader down, 
> client must wait until new leader being elected.
> To use this new replication mode, a new collection must be created with an 
> additional parameter {{liveReplicas=1}}
> {code}
> http://localhost:8983/solr/admin/collections?action=CREATE=newCollection=2=1=1
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9401:
-
Attachment: SOLR-9401.patch

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Attachments: SOLR-9401.patch, SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9401:
--

Still getting NPEs with the patch on the first iteration before the retry is 
attempted, e.g.:

{noformat}
   [junit4] ERROR   7.74s | TestPKIAuthenticationPlugin.test <<<
   [junit4]> Throwable #1: java.lang.NullPointerException
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([64FDA0C26386B4F:8E1BE5D688C406B7]:0)
   [junit4]>at 
org.apache.solr.security.TestPKIAuthenticationPlugin.run(TestPKIAuthenticationPlugin.java:166)
   [junit4]>at 
org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:101)
{noformat}

Maybe add an assert that the user principal is not null before testing for the 
expected principal name, something like?:

{code:java} 
assertNotNull(((HttpServletRequest) 
wrappedRequestByFilter.get()).getUserPrincipal());
{code}

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Attachments: SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9401:
-
Attachment: SOLR-9401.patch

retry so that timeout is taken care of

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Attachments: SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-9401:


Assignee: Noble Paul

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10196) ElectionContext#runLeaderProcess can hit NPE on core close.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10196:


Commit 04ba9968c0686a5fa1a9c5d89a7cd92839902f32 in lucene-solr's branch 
refs/heads/master from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=04ba996 ]

SOLR-10196: ElectionContext#runLeaderProcess can hit NPE on core close.


> ElectionContext#runLeaderProcess can hit NPE on core close.
> ---
>
> Key: SOLR-10196
> URL: https://issues.apache.org/jira/browse/SOLR-10196
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
>
> {noformat}
>[junit4]   2> 191445 INFO  
> (zkCallback-7-thread-7-processing-n:127.0.0.1:45055_) [n:127.0.0.1:45055_ 
> c:solrj_collection2 s:shard2 r:core_node3 
> x:solrj_collection2_shard2_replica1] o.a.s.m.SolrMetricManager Closing metric 
> reporters for: solr.core.solrj_collection2.shard2.replica1
>[junit4]   2> 191445 INFO  
> (zkCallback-7-thread-7-processing-n:127.0.0.1:45055_) [n:127.0.0.1:45055_ 
> c:solrj_collection2 s:shard2 r:core_node3 
> x:solrj_collection2_shard2_replica1] o.a.s.s.h.HdfsDirectory Closing hdfs 
> directory 
> hdfs://localhost:34043/solr_hdfs_home/solrj_collection2/core_node3/data
>[junit4]   2> 191476 INFO  
> (zkCallback-7-thread-7-processing-n:127.0.0.1:45055_) [n:127.0.0.1:45055_ 
> c:solrj_collection2 s:shard2 r:core_node3 
> x:solrj_collection2_shard2_replica1] o.a.s.s.h.HdfsDirectory Closing hdfs 
> directory 
> hdfs://localhost:34043/solr_hdfs_home/solrj_collection2/core_node3/data/index
>[junit4]   2> 191484 INFO  
> (zkCallback-7-thread-7-processing-n:127.0.0.1:45055_) [n:127.0.0.1:45055_ 
> c:solrj_collection2 s:shard2 r:core_node3 
> x:solrj_collection2_shard2_replica1] o.a.s.s.h.HdfsDirectory Closing hdfs 
> directory 
> hdfs://localhost:34043/solr_hdfs_home/solrj_collection2/core_node3/data/snapshot_metadata
>[junit4]   2> 191523 INFO  (coreCloseExecutor-172-thread-6) 
> [n:127.0.0.1:45055_ c:solrj_collection4 s:shard5 r:core_node4 
> x:solrj_collection4_shard5_replica1] o.a.s.m.SolrMetricManager Closing metric 
> reporters for: solr.core.solrj_collection4.shard5.replica1
>[junit4]   2> 191530 INFO  
> (zkCallback-7-thread-9-processing-n:127.0.0.1:45055_) [n:127.0.0.1:45055_
> ] o.a.s.c.c.ZkStateReader A cluster state change: [WatchedEvent 
> state:SyncConnected type:NodeDataChanged 
> path:/collections/solrj_collection2/state.json] for collection 
> [solrj_collection2] has occurred - updating... (live nodes size: [1])
>[junit4]   2> 191554 INFO  (coreCloseExecutor-172-thread-6) 
> [n:127.0.0.1:45055_ c:solrj_collection4 s:shard5 r:core_node4 
> x:solrj_collection4_shard5_replica1] o.a.s.s.h.HdfsDirectory Closing hdfs 
> directory 
> hdfs://localhost:34043/solr_hdfs_home/solrj_collection4/core_node4/data/index
>[junit4]   2> 191555 ERROR 
> (zkCallback-7-thread-7-processing-n:127.0.0.1:45055_) [n:127.0.0.1:45055_ 
> c:solrj_collection2 s:shard2 r:core_node3 
> x:solrj_collection2_shard2_replica1] o.a.s.c.ShardLeaderElectionContext There 
> was a problem trying to register as the leader:java.lang.NullPointerException
>[junit4]   2>  at 
> org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:426)
>[junit4]   2>  at 
> org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
>[junit4]   2>  at 
> org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
>[junit4]   2>  at 
> org.apache.solr.cloud.LeaderElector.access$200(LeaderElector.java:56)
>[junit4]   2>  at 
> org.apache.solr.cloud.LeaderElector$ElectionWatcher.process(LeaderElector.java:348)
>[junit4]   2>  at 
> org.apache.solr.common.cloud.SolrZkClient$3.lambda$process$0(SolrZkClient.java:268)
>[junit4]   2>  at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>[junit4]   2>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>[junit4]   2>  at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>[junit4]   2>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>[junit4]   2>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>[junit4]   2>  at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: 

[jira] [Commented] (SOLR-10207) Harden CleanupOldIndexTest

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10207:


Commit ed0f0f45ce17e2218ec2e97aab2fcb1a0d4defa6 in lucene-solr's branch 
refs/heads/master from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ed0f0f4 ]

SOLR-10207: Harden CleanupOldIndexTest.


> Harden CleanupOldIndexTest
> --
>
> Key: SOLR-10207
> URL: https://issues.apache.org/jira/browse/SOLR-10207
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_121) - Build # 2960 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2960/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseG1GC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=19134, name=jetty-launcher-4191-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)   
 2) Thread[id=19144, name=jetty-launcher-4191-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=19134, name=jetty-launcher-4191-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

[jira] [Updated] (SOLR-8045) Deploy Solr in ROOT (/) path

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-8045:
---
Attachment: SOLR-8045.patch

Updated patch, adding test for redirection in smoker.

> Deploy Solr in ROOT (/) path 
> -
>
> Key: SOLR-8045
> URL: https://issues.apache.org/jira/browse/SOLR-8045
> Project: Solr
>  Issue Type: Wish
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.0
>
> Attachments: SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch, 
> SOLR-8045.patch, SOLR-8045.patch
>
>
> This does not mean that the path to access Solr will be changed. All paths 
> will remain as is and would behave exactly the same



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9401:
--

The test should retry if no principal is returned. 

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-8045) Deploy Solr in ROOT (/) path

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-8045:
---
Attachment: SOLR-8045.patch

Because our goal for this ticket is make v2 API available at "/v2" instead of 
"/solr/v2". 

We also have a discussion with [~hossman], and he have an great idea to this 
problem. So here are the latest patch.

In this patch :
- "/solr/v2" is changed into "/solr/v2" so users won't attempt to use this 
path
- jetty will internally redirect (very fast) "/v2" to "/solr/v2"

> Deploy Solr in ROOT (/) path 
> -
>
> Key: SOLR-8045
> URL: https://issues.apache.org/jira/browse/SOLR-8045
> Project: Solr
>  Issue Type: Wish
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.0
>
> Attachments: SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch, 
> SOLR-8045.patch
>
>
> This does not mean that the path to access Solr will be changed. All paths 
> will remain as is and would behave exactly the same



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1160 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1160/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
Didn't see all replicas for shard shard1 in c8n_1x2 come up within 9 ms! 
ClusterState: {   "collMinRf_1x3":{ "replicationFactor":"3", 
"shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"collMinRf_1x3_shard1_replica1", 
"base_url":"http://127.0.0.1:65154;, 
"node_name":"127.0.0.1:65154_", "state":"active"},   
"core_node2":{ "core":"collMinRf_1x3_shard1_replica3", 
"base_url":"http://127.0.0.1:43541;, 
"node_name":"127.0.0.1:43541_", "state":"active"},   
"core_node3":{ "core":"collMinRf_1x3_shard1_replica2", 
"base_url":"http://127.0.0.1:41386;, 
"node_name":"127.0.0.1:41386_", "state":"active", 
"leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false"},   "collection1":{ 
"replicationFactor":"1", "shards":{   "shard1":{ 
"range":"8000-", "state":"active", 
"replicas":{"core_node2":{ "core":"collection1", 
"base_url":"http://127.0.0.1:41386;, 
"node_name":"127.0.0.1:41386_", "state":"active", 
"leader":"true"}}},   "shard2":{ "range":"0-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"collection1", "base_url":"http://127.0.0.1:43541;,  
   "node_name":"127.0.0.1:43541_", "state":"active", 
"leader":"true"},   "core_node3":{ "core":"collection1",
 "base_url":"http://127.0.0.1:65154;, 
"node_name":"127.0.0.1:65154_", "state":"active", 
"router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false", "autoCreated":"true"},   "control_collection":{  
   "replicationFactor":"1", "shards":{"shard1":{ 
"range":"8000-7fff", "state":"active", 
"replicas":{"core_node1":{ "core":"collection1", 
"base_url":"http://127.0.0.1:37482;, 
"node_name":"127.0.0.1:37482_", "state":"active", 
"leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false", 
"autoCreated":"true"},   "c8n_1x2":{ "replicationFactor":"2", 
"shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"c8n_1x2_shard1_replica2", 
"base_url":"http://127.0.0.1:65154;, 
"node_name":"127.0.0.1:65154_", "state":"active", 
"leader":"true"},   "core_node2":{ "state":"down",  
   "base_url":"http://127.0.0.1:37482;, 
"core":"c8n_1x2_shard1_replica1", 
"node_name":"127.0.0.1:37482_", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false"}}

Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in c8n_1x2 
come up within 9 ms! ClusterState: {
  "collMinRf_1x3":{
"replicationFactor":"3",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"core":"collMinRf_1x3_shard1_replica1",
"base_url":"http://127.0.0.1:65154;,
"node_name":"127.0.0.1:65154_",
"state":"active"},
  "core_node2":{
"core":"collMinRf_1x3_shard1_replica3",
"base_url":"http://127.0.0.1:43541;,
"node_name":"127.0.0.1:43541_",
"state":"active"},
  "core_node3":{
"core":"collMinRf_1x3_shard1_replica2",
"base_url":"http://127.0.0.1:41386;,
"node_name":"127.0.0.1:41386_",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false"},
  "collection1":{
"replicationFactor":"1",
"shards":{
  "shard1":{
"range":"8000-",
"state":"active",
"replicas":{"core_node2":{
"core":"collection1",
"base_url":"http://127.0.0.1:41386;,
"node_name":"127.0.0.1:41386_",
"state":"active",
"leader":"true"}}},
  "shard2":{
"range":"0-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:43541;,

[jira] [Resolved] (SOLR-608) scripts using curl should support authentication params

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-608.

Resolution: Fixed

Marking this as resolved since SOLR-7453 is committed. If the scope was to do 
more cleanup we can reopen this.

> scripts using curl should support authentication params
> ---
>
> Key: SOLR-608
> URL: https://issues.apache.org/jira/browse/SOLR-608
> Project: Solr
>  Issue Type: Improvement
>  Components: replication (scripts)
>Reporter: Hoss Man
>
> All scripts that utilize "curl" should be enhanced such that user 
> authentication based params can be specified and used by curl.  This would 
> make it possible for people to "secure" their Solr servers using Servlet 
> Container authentication features, but still interact with those Solr 
> instances using the scripts out of the box.
> The most straight forward approach would probably be to add a new "curl_args" 
> option in scripts.conf that could could contain any legal curl command line 
> options and would be prepended to the args for all usages of curl in the Solr 
> scripts.
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-7453) Cleanup replication & backup scripts in the solr/scripts directory of the checkout

[Varun Thacker (JIRA)]

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

Varun Thacker reassigned SOLR-7453:
---

Assignee: Varun Thacker

> Cleanup replication & backup scripts in the solr/scripts directory of the 
> checkout
> --
>
> Key: SOLR-7453
> URL: https://issues.apache.org/jira/browse/SOLR-7453
> Project: Solr
>  Issue Type: Task
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Fix For: 6.5, master (7.0)
>
>
> We have a bunch of scripts in the {{solr/scripts}} directory of the checkout. 
>  
> Are they required or being used? If not can we remove them?
> If there has been a discussion on this in the past or a relevant Jira then 
> please link it here. I couldn't find any.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-7453) Cleanup replication & backup scripts in the solr/scripts directory of the checkout

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-7453:
---

Commit c79f670e9f1b7e42f1cef541ac62e8dbeb80c7c7 in lucene-solr's branch 
refs/heads/branch_6x from [~varunthacker]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c79f670 ]

SOLR-7453: Remove replication & backup scripts in the solr/scripts directory of 
the checkout


> Cleanup replication & backup scripts in the solr/scripts directory of the 
> checkout
> --
>
> Key: SOLR-7453
> URL: https://issues.apache.org/jira/browse/SOLR-7453
> Project: Solr
>  Issue Type: Task
>Reporter: Varun Thacker
>Priority: Minor
> Fix For: 6.5, master (7.0)
>
>
> We have a bunch of scripts in the {{solr/scripts}} directory of the checkout. 
>  
> Are they required or being used? If not can we remove them?
> If there has been a discussion on this in the past or a relevant Jira then 
> please link it here. I couldn't find any.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-7453) Cleanup replication & backup scripts in the solr/scripts directory of the checkout

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-7453.
-
Resolution: Fixed

> Cleanup replication & backup scripts in the solr/scripts directory of the 
> checkout
> --
>
> Key: SOLR-7453
> URL: https://issues.apache.org/jira/browse/SOLR-7453
> Project: Solr
>  Issue Type: Task
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Fix For: 6.5, master (7.0)
>
>
> We have a bunch of scripts in the {{solr/scripts}} directory of the checkout. 
>  
> Are they required or being used? If not can we remove them?
> If there has been a discussion on this in the past or a relevant Jira then 
> please link it here. I couldn't find any.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-7453) Cleanup replication & backup scripts in the solr/scripts directory of the checkout

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-7453:

Fix Version/s: (was: 6.0)
   (was: 5.2)
   master (7.0)
   6.5

> Cleanup replication & backup scripts in the solr/scripts directory of the 
> checkout
> --
>
> Key: SOLR-7453
> URL: https://issues.apache.org/jira/browse/SOLR-7453
> Project: Solr
>  Issue Type: Task
>Reporter: Varun Thacker
>Priority: Minor
> Fix For: 6.5, master (7.0)
>
>
> We have a bunch of scripts in the {{solr/scripts}} directory of the checkout. 
>  
> Are they required or being used? If not can we remove them?
> If there has been a discussion on this in the past or a relevant Jira then 
> please link it here. I couldn't find any.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-7453) Cleanup replication & backup scripts in the solr/scripts directory of the checkout

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-7453:
---

Commit 0f5875b735d889ad41f22315b00ba5451ac9ad1a in lucene-solr's branch 
refs/heads/master from [~varunthacker]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0f5875b ]

SOLR-7453: Remove replication & backup scripts in the solr/scripts directory of 
the checkout


> Cleanup replication & backup scripts in the solr/scripts directory of the 
> checkout
> --
>
> Key: SOLR-7453
> URL: https://issues.apache.org/jira/browse/SOLR-7453
> Project: Solr
>  Issue Type: Task
>Reporter: Varun Thacker
>Priority: Minor
> Fix For: 6.5, master (7.0)
>
>
> We have a bunch of scripts in the {{solr/scripts}} directory of the checkout. 
>  
> Are they required or being used? If not can we remove them?
> If there has been a discussion on this in the past or a relevant Jira then 
> please link it here. I couldn't find any.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9516) New UI doesn't work when Kerberos is enabled

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-9516:
-

It would be a blocker if it worked in old UI and we had it replicated on the 
latest Solr. At the moment, we don't have either fact confirmed, nor do we have 
the replication instructions.

I am not familiar with Kerberos setup, but if somebody provides replication 
instructions, I'll be happy to dig into it.

> New UI doesn't work when Kerberos is enabled
> 
>
> Key: SOLR-9516
> URL: https://issues.apache.org/jira/browse/SOLR-9516
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Ishan Chattopadhyaya
>  Labels: javascript, newdev, security
> Attachments: QQ20161012-0.png, Screenshot from 2016-09-15 07-36-29.png
>
>
> It seems resources like http://solr1:8983/solr/libs/chosen.jquery.js 
> encounter 403 error:
> {code}
> 2016-09-15 02:01:45.272 WARN  (qtp611437735-18) [   ] 
> o.a.h.s.a.s.AuthenticationFilter Authentication exception: GSSException: 
> Failure unspecified at GSS-API level (Mechanism level: Request is a replay 
> (34))
> {code}
> The old UI is fine.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 1699 - Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery

Error Message:
Expected a collection with one shard and two replicas null Last available 
state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/6)={
   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"MissingSegmentRecoveryTest_shard1_replica2",   
"base_url":"https://127.0.0.1:41308/solr;,   
"node_name":"127.0.0.1:41308_solr",   "state":"down"}, 
"core_node2":{   "core":"MissingSegmentRecoveryTest_shard1_replica1",   
"base_url":"https://127.0.0.1:60247/solr;,   
"node_name":"127.0.0.1:60247_solr",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
null
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/6)={
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"MissingSegmentRecoveryTest_shard1_replica2",
  "base_url":"https://127.0.0.1:41308/solr;,
  "node_name":"127.0.0.1:41308_solr",
  "state":"down"},
"core_node2":{
  "core":"MissingSegmentRecoveryTest_shard1_replica1",
  "base_url":"https://127.0.0.1:60247/solr;,
  "node_name":"127.0.0.1:60247_solr",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([B800C15EC6F11C02:E855595D9FD0AA1F]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:265)
at 
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[jira] [Updated] (SOLR-8876) Morphlines tests fail with Java 9 due to morphline "importCommands" attempting to resolve classname globs in config files

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-8876:
---
Description: 
morphline configs we use in our contrib tests  have {{importCommands}} that 
look like this...

{noformat}
importCommands : ["org.kitesdk.**", "org.apache.solr.**"]
{noformat}

...but under java9 these tests fail with errors like...

{noformat}
No command builder registered for COMMAND_NAME
{noformat}

...because of how morphlines attempts to locate classes matching those globs -- 
this type of classpath scanning does not work in java9.

workaround is to only use fully qualified command class names in 
{{importCommands}} declaration.  No other (obviuos) java9 problems seem to 
exist with solr's use of morphlines (based on current test coverage)

  was:
They fail with: "No command builder registered for name".

I added an assume through SOLR-8874.

Component/s: contrib - morphlines-core
 contrib - morphlines-cell
Summary: Morphlines tests fail with Java 9 due to morphline 
"importCommands" attempting to resolve classname globs in config files  (was: 
Morphlines tests fail with Java 9 (Jigsaw))

tweaked summary/description to reflect current state of situation.

(should be updated/refined more -- if/when we commit patch -- to be more user 
centric)

> Morphlines tests fail with Java 9 due to morphline "importCommands" 
> attempting to resolve classname globs in config files
> -
>
> Key: SOLR-8876
> URL: https://issues.apache.org/jira/browse/SOLR-8876
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, contrib - morphlines-cell, contrib 
> - morphlines-core
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: SOLR-8876.patch
>
>
> morphline configs we use in our contrib tests  have {{importCommands}} that 
> look like this...
> {noformat}
> importCommands : ["org.kitesdk.**", "org.apache.solr.**"]
> {noformat}
> ...but under java9 these tests fail with errors like...
> {noformat}
> No command builder registered for COMMAND_NAME
> {noformat}
> ...because of how morphlines attempts to locate classes matching those globs 
> -- this type of classpath scanning does not work in java9.
> workaround is to only use fully qualified command class names in 
> {{importCommands}} declaration.  No other (obviuos) java9 problems seem to 
> exist with solr's use of morphlines (based on current test coverage)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-8876) Morphlines tests fail with Java 9 (Jigsaw)

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-8876:
---
Attachment: SOLR-8876.patch


Root issue appears to be a (non-test) bug in how morphlines parses it's config 
file.

Syntax like this...

{noformat}
importCommands : ["org.kitesdk.**", "org.apache.solr.**"]
{noformat}

...is intended to trigger classpath scanning of those package (prefixes) 
looking for classes that implement morphline's  {{CommandBuilder}} interface, 
which can then be refered to by name later in the config.

This classpath scanning doesn't work in java9 (likely due to the way the 
ClassLoader specifics have changed)

It appears that this limitation can be worked arround by having a config which 
explicitly identifies all of the \*Builder classes needed for the config, e.g. 
...

{noformat}
# using globs (foo.bar.* or foo.bar.**) will not work in Java9 due to 
classpath scanning limitations
# so we enumarate every command (builder) we know this config uses below. 
(see SOLR-8876)
importCommands : ["org.kitesdk.morphline.stdlib.LogDebugBuilder",
  
"org.apache.solr.morphlines.solr.SanitizeUnknownSolrFieldsBuilder",
  "org.apache.solr.morphlines.solr.LoadSolrBuilder"]
{noformat}

I opened an upstream issue: https://github.com/kite-sdk/kite/issues/469



The attached patch removes these problematic globs from all the test configs in 
solr, and removes all "SOLR-8876" + {{Constants.JRE_IS_MINIMUM_JAVA9}} related 
"assumes".  With this patch, running morphline-core, morphline-cell, & 
map-reduce tests under java9 seem to pass/skip reliably (and failures found 
when using {{\-Dtests.awaitsfix=true}} seem to match the existing test failures 
using  {{\-Dtests.awaitsfix=true}} with java8)

I suggest we commit & backport this patch, but leave this jira open with a 
modified summary/description drawing attention to the morphlines config 
limitation in java9 and the workaround.




> Morphlines tests fail with Java 9 (Jigsaw)
> --
>
> Key: SOLR-8876
> URL: https://issues.apache.org/jira/browse/SOLR-8876
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: SOLR-8876.patch
>
>
> They fail with: "No command builder registered for name".
> I added an assume through SOLR-8874.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_121) - Build # 2958 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2958/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=12961, name=jetty-launcher-2264-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)   
 2) Thread[id=12963, name=jetty-launcher-2264-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=12961, name=jetty-launcher-2264-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

[jira] [Resolved] (SOLR-7086) Suggester dictionary empty if payload field does not exist

[JIRA]

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

Jan Høydahl resolved SOLR-7086.
---
Resolution: Duplicate

> Suggester dictionary empty if payload field does not exist
> --
>
> Key: SOLR-7086
> URL: https://issues.apache.org/jira/browse/SOLR-7086
> Project: Solr
>  Issue Type: Bug
>  Components: Suggester
>Affects Versions: 4.10.3
>Reporter: Jan Høydahl
> Fix For: 6.0, 5.2
>
>
> Setting up a suggester for authors using {{DocumentDictionaryFactory}} and 
> {{payloadField}}. If no documents have data in the payload field, the 
> dictionary will be empty.
> {code:xml}
>
>   authors
>   BlendedInfixLookupFactory 
>   text_folded
>   DocumentDictionaryFactory 
>   authors_s
>   not_exist_s
>
> {code}
> It should use an empty payload instead.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3860 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3860/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI

Error Message:
Could not find collection : implicitcoll

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : implicitcoll
at 
__randomizedtesting.SeedInfo.seed([8E883E4A97B15A2B:E469B021AA2BEC53]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:245)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 
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.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12338 lines...]
   [junit4] Suite: org.apache.solr.cloud.CustomCollectionTest
   [junit4]   2> Creating dataDir: 

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_121) - Build # 755 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/755/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseG1GC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.search.MergeStrategyTest

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\tempDir-001\shard1\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\tempDir-001\shard1\collection1

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\tempDir-001\shard1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\tempDir-001\shard1

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\tempDir-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\tempDir-001\shard1\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\tempDir-001\shard1\collection1
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\tempDir-001\shard1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\tempDir-001\shard1
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\tempDir-001

at __randomizedtesting.SeedInfo.seed([5F947E1F84CBBD7E]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:323)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12986 lines...]
   [junit4] Suite: org.apache.solr.search.MergeStrategyTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.search.MergeStrategyTest_5F947E1F84CBBD7E-001\init-core-data-001
   [junit4]   2> 2672570 INFO  
(SUITE-MergeStrategyTest-seed#[5F947E1F84CBBD7E]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields
   [junit4]   2> 2672577 INFO  
(SUITE-MergeStrategyTest-seed#[5F947E1F84CBBD7E]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 2672579 INFO  
(SUITE-MergeStrategyTest-seed#[5F947E1F84CBBD7E]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 2672579 INFO  
(SUITE-MergeStrategyTest-seed#[5F947E1F84CBBD7E]-worker) [] 
o.a.s.SolrTestCaseJ4 initCore
   [junit4]   2> 2672580 INFO  
(SUITE-MergeStrategyTest-seed#[5F947E1F84CBBD7E]-worker) [] 
o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths: 

[jira] [Commented] (SOLR-9516) New UI doesn't work when Kerberos is enabled

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-9516:
-

If the plan is to remove the old Admin UI for Solr 7, then this needs to be 
considered a blocker for that.

> New UI doesn't work when Kerberos is enabled
> 
>
> Key: SOLR-9516
> URL: https://issues.apache.org/jira/browse/SOLR-9516
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Ishan Chattopadhyaya
>  Labels: javascript, newdev, security
> Attachments: QQ20161012-0.png, Screenshot from 2016-09-15 07-36-29.png
>
>
> It seems resources like http://solr1:8983/solr/libs/chosen.jquery.js 
> encounter 403 error:
> {code}
> 2016-09-15 02:01:45.272 WARN  (qtp611437735-18) [   ] 
> o.a.h.s.a.s.AuthenticationFilter Authentication exception: GSSException: 
> Failure unspecified at GSS-API level (Mechanism level: Request is a replay 
> (34))
> {code}
> The old UI is fine.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7715) Simplify NearSpansUnordered

[Paul Elschot (JIRA)]

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

Paul Elschot updated LUCENE-7715:
-
Summary: Simplify NearSpansUnordered  (was: SImplify NearSpansUnordered)

> Simplify NearSpansUnordered
> ---
>
> Key: LUCENE-7715
> URL: https://issues.apache.org/jira/browse/LUCENE-7715
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-7715.patch
>
>
> {code}
> git diff --stat master...
>  .../spans/NearSpansUnordered.java   | 211 -
>  1 file changed, 59 insertions(+), 152 deletions(-)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7715) SImplify NearSpansUnordered

[Paul Elschot (JIRA)]

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

Paul Elschot updated LUCENE-7715:
-
Attachment: LUCENE-7715.patch

> SImplify NearSpansUnordered
> ---
>
> Key: LUCENE-7715
> URL: https://issues.apache.org/jira/browse/LUCENE-7715
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-7715.patch
>
>
> {code}
> git diff --stat master...
>  .../spans/NearSpansUnordered.java   | 211 -
>  1 file changed, 59 insertions(+), 152 deletions(-)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7715) SImplify NearSpansUnordered

[Paul Elschot (JIRA)]

Paul Elschot created LUCENE-7715:


 Summary: SImplify NearSpansUnordered
 Key: LUCENE-7715
 URL: https://issues.apache.org/jira/browse/LUCENE-7715
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: master (7.0)
Reporter: Paul Elschot
Priority: Minor


{code}
git diff --stat master...
 .../spans/NearSpansUnordered.java   | 211 -
 1 file changed, 59 insertions(+), 152 deletions(-)
{code}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8593 at 2/27/17 7:19 PM:
---

Ok great, I will add this assumption to the SQL tests.


was (Author: joel.bernstein):
Ok, great I will add this assumption to the SQL tests.

> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8593 at 2/27/17 7:19 PM:
---

Ok, great I will add this assumption to the SQL tests.


was (Author: joel.bernstein):
Ok, great I will this assumption to the SQL tests.

> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8593:
--

Ok, great I will this assumption to the SQL tests.

> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10155) Clarify logic for term filters on numeric types

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-10155:
---
Attachment: SOLR-10155.patch

Revised patch to include {{facet.prefix}} rejection for numerics.

> Clarify logic for term filters on numeric types
> ---
>
> Key: SOLR-10155
> URL: https://issues.apache.org/jira/browse/SOLR-10155
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Affects Versions: 6.4.1
>Reporter: Gus Heck
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10155.patch, SOLR-10155.patch
>
>
> The following code has been found to be confusing to multiple folks working 
> in SimpleFacets.java (see SOLR-10132)
> {code}
> if (termFilter != null) {
>   // TODO: understand this logic... what is the case for 
> supporting an empty string
>   // for contains on numeric facets? What does that achieve?
>   // The exception message is misleading in the case of an 
> excludeTerms filter in any case...
>   // Also maybe vulnerable to NPE on isEmpty test?
>   final boolean supportedOperation = (termFilter instanceof 
> SubstringBytesRefFilter) && ((SubstringBytesRefFilter) 
> termFilter).substring().isEmpty();
>   if (!supportedOperation) {
> throw new SolrException(ErrorCode.BAD_REQUEST, 
> FacetParams.FACET_CONTAINS + " is not supported on numeric types");
>   }
> }
> {code}
> This is found around line 482 or so. The comment in the code above is mine, 
> and won't be found in the codebase. This ticket can be resolved by 
> eliminating the complex check and just denying all termFilters with a better 
> exception message not specific to contains filters (and perhaps consolidated 
> with the proceeding check for about prefix filters?), or adding a comment to 
> the code base explaining why we need to allow a term filter with an empty, 
> non-null string to be processed, and why this isn't an NPE waiting to happen.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8593:
--

bq. In the meantime is there a way to suppress the Turkish locale in the tests?

Yes, see for example:

{code:java|title=solr/contrib/map-reduce/src/test/org/apache/solr/hadoop/MRUnitBase.java}
  @BeforeClass
  public static void setupClass() throws Exception {
[...]
assumeFalse("This test fails on UNIX with Turkish default locale 
(https://issues.apache.org/jira/browse/SOLR-6387)",
new 
Locale("tr").getLanguage().equals(Locale.getDefault().getLanguage()));
{code}

> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10132) Support facet.matches to cull facets returned with a regex

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-10132:


re: {{null}} vs. {{SimpleFacets.MATCH_ALL_TERMS}} - SOLR-9914 refactored the 
"contains" check which was a null or non-null String into a null or non-null 
SubstringBytesRefFilter object _and_ that change isn't yet part of an official 
release. On that basis, yes, I think MATCH_ALL_TERMS instead of null would make 
sense. And for clarity, could I suggest making that change separately from the 
{{facet.matches}} feature addition here - what do you think?

> Support facet.matches to cull facets returned with a regex
> --
>
> Key: SOLR-10132
> URL: https://issues.apache.org/jira/browse/SOLR-10132
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Affects Versions: 6.4.1
>Reporter: Gus Heck
>Assignee: Christine Poerschke
> Attachments: SOLR-10132.patch, SOLR-10132.patch, SOLR-10132.patch
>
>
> I recently ran into a case where I really wanted to only return the next 
> level of a hierarchical facet, and while I was able to do that with a 
> coordinated set of dynamic fields, it occurred to me that this would have 
> been much much easier if I could have simply used PathHierarchyTokenizer and 
> written
> ="/my/current/prefix/[^/]+$"
> thereby limiting the returned facets to the next level down and not return 
> the  additional  N levels I didn't (yet) want to display (numbering in the 
> thousands near the top of the tree). I suspect there are other good use 
> cases, and the patch seemed relatively tractable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8593:


[~joel.bernstein] - I had the same suspicion about the turkish locale. I know 
that Lucene uses Forbidden APIs to prevent some of the Java constructs that 
allow for bad locale handling. 

> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Julian Hyde (JIRA)]

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

Julian Hyde commented on SOLR-8593:
---

Oh wow. I18n never fails to surprise. Please log a Calcite issue. We should 
ensure that Calcite runs correctly if {{user.locale=tr}}.

> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_121) - Build # 6423 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6423/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestSolrConfigHandler

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\tempDir-012\cores\core:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\tempDir-012\cores\core

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\tempDir-012\cores:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\tempDir-012\cores

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\tempDir-012:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\tempDir-012
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\tempDir-012\cores\core:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\tempDir-012\cores\core
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\tempDir-012\cores:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\tempDir-012\cores
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\tempDir-012:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\tempDir-012

at __randomizedtesting.SeedInfo.seed([EED3937E6203D900]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:323)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12671 lines...]
   [junit4] Suite: org.apache.solr.core.TestSolrConfigHandler
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler_EED3937E6203D900-001\init-core-data-001
   [junit4]   2> 2572335 INFO  
(SUITE-TestSolrConfigHandler-seed#[EED3937E6203D900]-worker) [] 
o.a.s.SolrTestCaseJ4 Using TrieFields
   [junit4]   2> 2572351 INFO  
(SUITE-TestSolrConfigHandler-seed#[EED3937E6203D900]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 2572354 INFO  
(TEST-TestSolrConfigHandler.testProperty-seed#[EED3937E6203D900]) [] 
o.a.s.SolrTestCaseJ4 ###Starting testProperty
   [junit4]   2> 2573215 INFO  
(TEST-TestSolrConfigHandler.testProperty-seed#[EED3937E6203D900]) [] 
o.a.s.SolrTestCaseJ4 initCore
   [junit4]   2> 2573215 INFO  
(TEST-TestSolrConfigHandler.testProperty-seed#[EED3937E6203D900]) [] 
o.a.s.SolrTestCaseJ4 initCore end
   

[jira] [Commented] (SOLR-10046) Create UninvertDocValuesMergePolicy

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-10046:


Thanks Keith! Just sent you a small fix [pull 
request|https://github.com/kelaban/lucene-solr/pull/3] to do with the new 
{{skipIntegrityChecks}} property ...

... other than that I have no further comments or observations here except that 
I'd appreciate extra pair(s) of eyes before proceeding to commit the change 
towards the end of this or the beginning of this week.

> Create UninvertDocValuesMergePolicy
> ---
>
> Key: SOLR-10046
> URL: https://issues.apache.org/jira/browse/SOLR-10046
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Keith Laban
>Assignee: Christine Poerschke
>
> Create a merge policy that can detect schema changes and use 
> UninvertingReader to uninvert fields and write docvalues into merged segments 
> when a field has docvalues enabled.
> The current behavior is to write null values in the merged segment which can 
> lead to data integrity problems when sorting or faceting pending a full 
> reindex. 
> With this patch it would still be recommended to reindex when adding 
> docvalues for performance reasons, as it not guarenteed all segments will be 
> merged with docvalues turned on.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: [JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_121) - Build # 750 - Still Unstable!

[Steve Rowe]

Hi Jan, 

See the notes I wrote up on .

--
Steve
www.lucidworks.com

> On Feb 25, 2017, at 4:16 PM, Jan Høydahl  wrote:
> 
> Tried to reproduce this locally on Mac, but did not succeed. Windows 
> specific? Race condition?
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
>> 25. feb. 2017 kl. 15.42 skrev Policeman Jenkins Server :
>> 
>> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/750/
>> Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseG1GC
>> 
>> 1 tests failed.
>> FAILED:  org.apache.solr.security.TestPKIAuthenticationPlugin.test
>> 
>> Error Message:
>> 
>> 
>> Stack Trace:
>> java.lang.NullPointerException
>>  at 
>> __randomizedtesting.SeedInfo.seed([D2BF175262C5311:857FCEAF88D03EE9]:0)
>>  at 
>> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:100)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>  at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>  at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>  at java.lang.reflect.Method.invoke(Method.java:498)
>>  at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
>>  at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
>>  at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
>>  at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
>>  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:916)
>>  at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
>>  at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
>>  at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>>  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 
>> 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)
>> 

[jira] [Commented] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9401:
--

This has been showing up on Jenkins-s, including mine, every once in a while.  
I beasted it a few hundred times and it happens on my box about 5% of the time.

Looking at the beasting failures, I noticed that the following is always 
present in the logs just before the NPE triggers a test failure (below is from 
[https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/750/consoleText]):

{noformat}
   [junit4]   2> 403449 ERROR 
(TEST-TestPKIAuthenticationPlugin.test-seed#[D2BF175262C5311]) [] 
o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 1488029294206 , 
received timestamp: 1488029300727 , TTL: 5000
{noformat}

In short, the NPEs are triggered because the 5 second TTL has expired (which is 
itself weird - what the hell is taking so long???), causing 
{{PKIAuthenticationPlugin.doAuthenticate()}} to skip the code path that would 
pull the user principal from the headers and populate it on the request (line 
#134 below).  As a result, when test code attempts to verify that the user 
principal on the request has the appropriate value, the NPE is triggered.

{code:java|title=PKIAuthenticationPlugin.java}
 92:   public boolean doAuthenticate(ServletRequest request, ServletResponse 
response, FilterChain filterChain) throws Exception {
[...]
 99: long receivedTime = System.currentTimeMillis();
100: String header = ((HttpServletRequest) request).getHeader(HEADER);
[...]
108: List authInfo = StrUtils.splitWS(header, false);
[...]
115: String nodeName = authInfo.get(0);
116: String cipher = authInfo.get(1);
117: 
118: PKIHeaderData decipher = decipherHeader(nodeName, cipher);
[...]
124: if ((receivedTime - decipher.timestamp) > MAX_VALIDITY) {
125:   log.error("Invalid key request timestamp: {} , received timestamp: 
{} , TTL: {}", decipher.timestamp, receivedTime, MAX_VALIDITY);
126: filterChain.doFilter(request, response);
127: return true;
128: }
129: 
130: final Principal principal = "$".equals(decipher.userName) ?
131: SU :
132: new BasicUserPrincipal(decipher.userName);
133: 
134: filterChain.doFilter(getWrapper((HttpServletRequest) request, 
principal), response);
135: return true;
136:   }
{code}

Why doesn't the overridden {{doAuthenticate()}} follow the contract laid out in 
its superclass's javadocs, i.e. throw an exception on error?:

{code:java|title:AuthenticationPlugin.java}
  /**
   * This method attempts to authenticate the request. Upon a successful 
authentication, this
   * must call the next filter in the filter chain and set the user principal 
of the request,
   * or else, upon an error or an authentication failure, throw an exception.
[...]
   * @throws Exception any exception thrown during the authentication, e.g. 
PrivilegedActionException
  public abstract boolean doAuthenticate(ServletRequest request, 
ServletResponse response,
  FilterChain filterChain) throws Exception;
{code}

MAX_VALIDITY could maybe be modified by the test class (via sysprop 
{{pikiauth.ttl}}) to wait around longer:

{code:java|title=PKIAuthenticationPlugin.java}
63:  private final int MAX_VALIDITY = 
Integer.parseInt(System.getProperty("pkiauth.ttl", "5000"));
{code}

But that ^^ feels hackish.  Seems like client code should react to timeouts 
like this by retrying at least once?

I'm not sure which path is correct.  Ping [~noble.paul] , who AFAICT wrote most 
of this code, and [~janhoy], who was asking on the dev list about one of these 
failures the other day.

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> 

[jira] [Comment Edited] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8593 at 2/27/17 6:20 PM:
---

It appears that this issue is due to the Turkish locale.

https://garygregory.wordpress.com/2015/11/03/java-lowercase-conversion-turkey/


I believe this is due to how Calcite is handling locales. [~risdenk], curious 
if you see the same thing, which is that this in the Calcite code.

[~steve_rowe], if it does turn out this is a Calcite issue I'll log an issue on 
the Calcite site and submit a patch. In the meantime is there a way to suppress 
the Turkish locale in the tests?





was (Author: joel.bernstein):
It appears that this issue is due to the Turkish locale.

https://garygregory.wordpress.com/2015/11/03/java-lowercase-conversion-turkey/


I believe this is due to how Calcite is handling locales. [~risdenk], curious 
is you see the same thing, which is that this in the Calcite code.

[~steve_rowe], if it does turn out this is a Calcite issue I'll log an issue on 
the Calcite site and submit a patch. In the meantime is there a way to suppress 
the Turkish locale in the tests?




> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8593:
--

It appears that this issue is due to the Turkish locale.

https://garygregory.wordpress.com/2015/11/03/java-lowercase-conversion-turkey/


I believe this is due to how Calcite is handling locales. [~risdenk], curious 
is you see the same thing, which is that this in the Calcite code.

[~steve_rowe], if it does turn out this is a Calcite issue I'll log an issue on 
the Calcite site and submit a patch. In the meantime is there a way to suppress 
the Turkish locale in the tests?




> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-10190) Potential NPE in CloudSolrClient when reading stale alias

[JIRA]

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

Tomás Fernández Löbbe resolved SOLR-10190.
--
   Resolution: Fixed
Fix Version/s: 6.4.2
   master (7.0)
   6.5

Resolving. Thanks Janosch!

> Potential NPE in CloudSolrClient when reading stale alias
> -
>
> Key: SOLR-10190
> URL: https://issues.apache.org/jira/browse/SOLR-10190
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java, SolrJ
>Affects Versions: 5.5, 6.x, master (7.0)
>Reporter: Janosch Woschitz
>Assignee: Tomás Fernández Löbbe
> Fix For: 6.5, master (7.0), 6.4.2
>
>
> The CloudSolrClient raises a NullPointerException when CloudSolrClient::add 
> is invoked and pointed to an alias which references a collection which does 
> not exist anymore.
> {code}
> java.lang.NullPointerException
> at __randomizedtesting.SeedInfo.seed([1D00539A964E5C5D:D7D145363AD5CCA]:0)
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1078)
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1042)
> at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
> {code}
> This is a rather unexpected since the CloudSolrClient usually raises a 
> SolrException containing a descriptive error message (e.g. "Collection not 
> found: xyz") when a collection cannot be resolved.
> In general this error condition could be triggered also by other edge cases 
> since CloudSolrClient::getDocCollection might return null but the code 
> following that invocation is not guarded against null values.
> {code}
> // track the version of state we're using on the client side using 
> the _stateVer_ param
> DocCollection coll = getDocCollection(requestedCollection, null);
> int collVer = coll.getZNodeVersion();
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10208) Adjust scoring formula for the scoreNodes function

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10208:


Commit c752dc096f64c097c5f0b8bbb84152afb4749f27 in lucene-solr's branch 
refs/heads/branch_6x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c752dc0 ]

SOLR-10208: Adjust scoring formula for the scoreNodes function


> Adjust scoring formula for the scoreNodes function
> --
>
> Key: SOLR-10208
> URL: https://issues.apache.org/jira/browse/SOLR-10208
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10208.patch
>
>
> While working on SOLR-10156 I experimented with different scoring formula's 
> for scoring terms. I found that the scoring formula used by the scoreNodes 
> functions overweights the raw term counts. Through experimentation I found a 
> formula that does not overweight the raw term counts and provides a much 
> better significance score. This ticket applies the new formula.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8593:
--

OK, I'll take a look.

> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10208) Adjust scoring formula for the scoreNodes function

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10208:


Commit 0c1fde664fb1c9456b3fdc2abd08e80dc8f86eb8 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0c1fde6 ]

SOLR-10208: Adjust scoring formula for the scoreNodes function


> Adjust scoring formula for the scoreNodes function
> --
>
> Key: SOLR-10208
> URL: https://issues.apache.org/jira/browse/SOLR-10208
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10208.patch
>
>
> While working on SOLR-10156 I experimented with different scoring formula's 
> for scoring terms. I found that the scoring formula used by the scoreNodes 
> functions overweights the raw term counts. Through experimentation I found a 
> formula that does not overweight the raw term counts and provides a much 
> better significance score. This ticket applies the new formula.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10199) Solr's Kerberos functionaliy does not work in Java9 due to dependency on hadoop's AuthenticationFilter which attempt access to JVM protected classes

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10199:
-

bq. Should we open a bug with Hadoop, ...

hadoop community has known (at a broad level) about these underlying issues, 
and has existing issues tracking them (see HADOOP-11123 and it's sub-tasks)

I've opened SOLR-10210 as a central place for us to link/track our issues that 
are blocked by HADOOP-11123 (unless/until we remove the dependencies in those 
code paths)

> Solr's Kerberos functionaliy does not work in Java9 due to dependency on 
> hadoop's AuthenticationFilter which attempt access to JVM protected classes
> 
>
> Key: SOLR-10199
> URL: https://issues.apache.org/jira/browse/SOLR-10199
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: Java9
>
> (discovered this while working on test improvements for SOLR-8052)
> Our Kerberos based authn/authz features are all built on top of Hadoop's 
> {{AuthenticationFilter}} which in turn uses Hadoop's {{KerberosUtil}} -- but 
> this does not work on Java9/jigsaw JVMs because that class in turn attempts 
> to access {{sun.security.jgss.GSSUtil}} which is not exported by {{module 
> java.security.jgss}}
> This means that Solr users who depend on Kerberos will not be able to upgrade 
> to Java9, even if they do not use any Hadoop specific features of Solr.
> 
> Example log messages...
> {noformat}
>[junit4]   2> 6833 WARN  (qtp442059499-30) [] 
> o.a.h.s.a.s.AuthenticationFilter Authentication exception: 
> java.lang.IllegalAccessException: class 
> org.apache.hadoop.security.authentication.util.KerberosUtil cannot access 
> class sun.security.jgss.GSSUtil (in module java.security.jgss) because module 
> java.security.jgss does not export sun.security.jgss to unnamed module 
> @4b38fe8b
>[junit4]   2> 6841 WARN  
> (TEST-TestSolrCloudWithKerberosAlt.testBasics-seed#[95A583AF82D1EBBE]) [] 
> o.a.h.c.p.ResponseProcessCookies Invalid cookie header: "Set-Cookie: 
> hadoop.auth=; Path=/; Domain=127.0.0.1; Expires=Ara, 01-Sa-1970 00:00:00 GMT; 
> HttpOnly". Invalid 'expires' attribute: Ara, 01-Sa-1970 00:00:00 GMT
> {noformat}
> (NOTE: HADOOP-14115 is cause of malformed cookie expiration)
> ultimately the client gets a 403 error (as seen in a testcase with patch from 
> SOLR-8052 applied and java9 assume commented out)...
> {noformat}
>[junit4] ERROR   7.10s | TestSolrCloudWithKerberosAlt.testBasics <<<
>[junit4]> Throwable #1: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://127.0.0.1:34687/solr: Expected mime type 
> application/octet-stream but got text/html. 
>[junit4]> 
>[junit4]>  content="text/html;charset=ISO-8859-1"/>
>[junit4]> Error 403 
>[junit4]> 
>[junit4]> 
>[junit4]> HTTP ERROR: 403
>[junit4]> Problem accessing /solr/admin/collections. Reason:
>[junit4]> java.lang.IllegalAccessException: class 
> org.apache.hadoop.security.authentication.util.KerberosUtil cannot access 
> class sun.security.jgss.GSSUtil (in module java.security.jgss) because module 
> java.security.jgss does not export sun.security.jgss to unnamed module 
> @4b38fe8b
>[junit4]> http://eclipse.org/jetty;>Powered by Jetty:// 
> 9.3.14.v20161028
>[junit4]> 
>[junit4]> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8593:
--

Policeman Jenkins found a reproducing seed for a {{TestSQLHandler}} failure 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19059/]:

{noformat}
  [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
-Dtests.method=doTest -Dtests.seed=F875A6E80D435C44 -Dtests.multiplier=3 
-Dtests.slow=true -Dtests.locale=tr -Dtests.timezone=Africa/Lagos 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
  [junit4] ERROR   26.3s J0 | TestSQLHandler.doTest <<<
  [junit4]> Throwable #1: java.io.IOException: --> 
https://127.0.0.1:37214/collection1:Failed to execute sqlQuery 'select str_s, 
count(*), sum(field_i), min(field_i), max(field_i), cast(avg(1.0 * field_i) as 
float) from collection1 where text='' group by str_s order by sum(field_i) 
asc limit 2' against JDBC connection 'jdbc:calcitesolr:'.
  [junit4]> Error while executing SQL "select str_s, count(*), 
sum(field_i), min(field_i), max(field_i), cast(avg(1.0 * field_i) as float) 
from collection1 where text='' group by str_s order by sum(field_i) asc 
limit 2": From line 1, column 39 to line 1, column 50: No match found for 
function signature min()
  [junit4]> at 
__randomizedtesting.SeedInfo.seed([F875A6E80D435C44:5F311E4C60F84FFD]:0)
  [junit4]> at 
org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:235)
  [junit4]> at 
org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2325)
  [junit4]> at 
org.apache.solr.handler.TestSQLHandler.testBasicGrouping(TestSQLHandler.java:651)
  [junit4]> at 
org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:77)
  [junit4]> at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
  [junit4]> at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
[...]
  [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{n_l1=PostingsFormat(name=LuceneFixedGap), 
multiDefault=BlockTreeOrds(blocksize=128), 
Field_i=BlockTreeOrds(blocksize=128), 
intDefault=PostingsFormat(name=LuceneFixedGap), 
n_dt1=BlockTreeOrds(blocksize=128), n_td1=BlockTreeOrds(blocksize=128), 
Str_s=Lucene50(blocksize=128), n_d1=PostingsFormat(name=LuceneFixedGap), 
field_i=BlockTreeOrds(blocksize=128), str_s=Lucene50(blocksize=128), 
n_f1=BlockTreeOrds(blocksize=128), n_ti1=FST50, rnd_b=FST50, 
n_tl1=BlockTreeOrds(blocksize=128), 
_version_=PostingsFormat(name=LuceneFixedGap), 
n_tf1=PostingsFormat(name=LuceneFixedGap), 
n_tdt1=PostingsFormat(name=LuceneFixedGap), id=FST50, 
text=Lucene50(blocksize=128), Text_t=PostingsFormat(name=LuceneFixedGap), 
timestamp=PostingsFormat(name=LuceneFixedGap)}, 
docValues:{_version_=DocValuesFormat(name=Lucene70), 
multiDefault=DocValuesFormat(name=Asserting), 
Field_i=DocValuesFormat(name=Asserting), 
intDefault=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Memory), 
Str_s=DocValuesFormat(name=Direct), field_i=DocValuesFormat(name=Asserting), 
str_s=DocValuesFormat(name=Direct), n_f1=DocValuesFormat(name=Asserting)}, 
maxPointsInLeafNode=197, maxMBSortInHeap=6.686785692870154, 
sim=RandomSimilarity(queryNorm=false): {}, locale=tr, timezone=Africa/Lagos
  [junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 1.8.0_121 
(32-bit)/cpus=12,threads=1,free=50683592,total=254599168
{noformat}

> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-

[jira] [Commented] (SOLR-10210) Solr features based on Hadoop that do not work on Java9

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10210:
-

Linking SOLR-8052 & SOLR-10199 - two issues that are currently caused by 
hadoop+java9 problems (but we might be able to solve by removing the dependency 
on hadoop in those code paths)

> Solr features based on Hadoop that do not work on Java9
> ---
>
> Key: SOLR-10210
> URL: https://issues.apache.org/jira/browse/SOLR-10210
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: Java9
>
> This issue will serve as a central tracking point / "blocker" for Solr issues 
> leveraging Hadoop code that does not work properly on java9.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10210) Solr features based on Hadoop that do not work on Java9

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10210:
-

Hadoop's primary tracking issue related to java9 support is HADOOP-11123

> Solr features based on Hadoop that do not work on Java9
> ---
>
> Key: SOLR-10210
> URL: https://issues.apache.org/jira/browse/SOLR-10210
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: Java9
>
> This issue will serve as a central tracking point / "blocker" for Solr issues 
> leveraging Hadoop code that does not work properly on java9.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10210) Solr features based on Hadoop that do not work on Java9

[Hoss Man (JIRA)]

Hoss Man created SOLR-10210:
---

 Summary: Solr features based on Hadoop that do not work on Java9
 Key: SOLR-10210
 URL: https://issues.apache.org/jira/browse/SOLR-10210
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


This issue will serve as a central tracking point / "blocker" for Solr issues 
leveraging Hadoop code that does not work properly on java9.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7449) Add CROSSES query support to RangeField

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7449:


My Jenkins found a reproducing branch_6x seed for a 
{{TestLongRangeFieldQueries.testBasics()}} failure:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestLongRangeFieldQueries -Dtests.method=testBasics 
-Dtests.seed=470D5069FEB53A50 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=es-PE -Dtests.timezone=PST8PDT -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.01s J0 | TestLongRangeFieldQueries.testBasics <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<4> but 
was:<5>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([470D5069FEB53A50:7AD5FE45C65B6420]:0)
   [junit4]>at 
org.apache.lucene.search.TestLongRangeFieldQueries.testBasics(TestLongRangeFieldQueries.java:135)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): 
{id=FSTOrd50}, docValues:{id=DocValuesFormat(name=Direct), 
longRangeField=DocValuesFormat(name=Lucene54)}, maxPointsInLeafNode=1625, 
maxMBSortInHeap=5.649688217301301, 
sim=RandomSimilarity(queryNorm=false,coord=no): {}, locale=es-PE, 
timezone=PST8PDT
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=313754016,total=499646464
{noformat}

This is due to this issue's addition of CROSSES query support - here's the 
source code line pointed to by the stack trace:

{code:java|title=TestLongRangeFieldQueries.java}
135:assertEquals(4, 
searcher.count(LongRangeField.newCrossesQuery(FIELD_NAME,
136:new long[] {-11, -15}, new long[] {15, 20})));
{code}

> Add CROSSES query support to RangeField
> ---
>
> Key: LUCENE-7449
> URL: https://issues.apache.org/jira/browse/LUCENE-7449
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7449.patch, LUCENE-7449.patch, LUCENE-7449.patch
>
>
> {{RangeField}} currently supports {{INTERSECTS}}, {{WITHIN}}, and 
> {{CONTAINS}} query behavior. This feature adds support for an explicit 
> {{CROSSES}} query. Unlike {{INTERSECT}} and {{OVERLAP}} queries the 
> {{CROSSES}} query finds any indexed ranges whose interior (within range) 
> intersect the interior AND exterior (outside range) of the query range.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9818) Solr admin UI rapidly retries any request(s) if it loses connection with the server

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-9818:


Created new jira: SOLR-10209 to track the developments, suggestions and 
feedbacks. Thank you.

> Solr admin UI rapidly retries any request(s) if it loses connection with the 
> server
> ---
>
> Key: SOLR-9818
> URL: https://issues.apache.org/jira/browse/SOLR-9818
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.3
>Reporter: Ere Maijala
>
> It seems that whenever the Solr admin UI loses connection with the server, be 
> the reason that the server is too slow to answer or that it's gone away 
> completely, it starts hammering the server with the previous request until it 
> gets a success response, it seems. That can be especially bad if the last 
> attempted action was something like collection reload with a SolrCloud 
> instance. The admin UI will quickly add hundreds of reload commands to 
> overseer/collection-queue-work, which may essentially cause the replicas to 
> get overloaded when they're trying to handle all the reload commands.
> I believe the UI should never retry the previous command blindly when the 
> connection is lost, but instead just ping the server until it responds again.
> Steps to reproduce:
> 1.) Fire up Solr
> 2.) Open the admin UI in browser
> 3.) Open a web console in the browser to see the requests it sends
> 4.) Stop solr
> 5.) Try an action in the admin UI
> 6.) Observe the web console in browser quickly fill up with repeats of the 
> originally attempted request



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10146) Admin UI: Button to delete a shard

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-10146:
-

Created new jira: SOLR-10209 to track the developments, suggestions and 
feedbacks. Thank you.

> Admin UI: Button to delete a shard
> --
>
> Key: SOLR-10146
> URL: https://issues.apache.org/jira/browse/SOLR-10146
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: Screenshot-1.png, Screenshot-2.png, SOLR-10146.patch
>
>
> Currently you can delete a replica through a small red X in the Admin UI 
> Collections tab. So you can delete all the replicas inside a shard, but you 
> cannot delete the whole shard, i.e. call the DELETESHARD Collection API.
> Add a button for this. This is useful for cleaning up e.g. after calling 
> SPLITSHARD.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10201) Admin UI: Add Collection "creates collection", "Connection to Solr lost", when replicationFactor>1

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-10201:
-

Created new jira: SOLR-10209 to track the developments, suggestions and 
feedbacks. Thank you.

> Admin UI: Add Collection "creates collection", "Connection to Solr lost", 
> when replicationFactor>1
> --
>
> Key: SOLR-10201
> URL: https://issues.apache.org/jira/browse/SOLR-10201
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.2
>Reporter: Amrit Sarkar
> Attachments: screenshot-1.png, SOLR-10201.patch
>
>
> "Add Collection" fails miserably when replicationFactor >1.
> There must be a better way to handle the request we are making through JS.
> PF screenshot.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10209) UI: Convert all Collections api calls to async requests, add new features/buttons

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10209:

Attachment: SOLR-10209-v1.patch

Phase 1: 

SOLR-10209-v1.patch uploaded introducing collections.js::asyncRequestStatus, 
incorporated to collections.js::addCollection.
In this patch:
{code}
modified:   solr/webapp/web/js/angular/controllers/collections.js
modified:   solr/webapp/web/js/angular/services.js
{code}
Handled success for addCollection async call, need to check where to display 
fails, unresponsiveness etc.
Performance hit: taking more time than sync call (approx 1-3 sec on local 
machine) to display the new collection added.

Working on progress bar and improvements.

> UI: Convert all Collections api calls to async requests, add new 
> features/buttons
> -
>
> Key: SOLR-10209
> URL: https://issues.apache.org/jira/browse/SOLR-10209
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Amrit Sarkar
> Attachments: SOLR-10209-v1.patch
>
>
> We are having discussion on multiple jiras for requests for Collections apis 
> from UI and how to improve them:
> SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses 
> connection with the server
> SOLR-10146: Admin UI: Button to delete a shard
> SOLR-10201: Add Collection "creates collection", "Connection to Solr lost", 
> when replicationFactor>1
> Proposal =>
> *Phase 1:*
> Convert all Collections api calls to async requests and utilise REQUESTSTATUS 
> to fetch the information. There will be performance hit, but the requests 
> will be safe and sound. A progress bar will be added for request status.
> {noformat}
> > submit the async request
> if (the initial call failed or there was no status to be found)
> { report an error and suggest the user look check their system before 
> resubmitting the request. Bail out in this case, no retries, no attempt to 
> drive on. }
> else
> { put up a progress indicator while periodically checking the status, 
> Continue spinning until we can report the final status. }
> {noformat}
> *Phase 2:*
> Add new buttons/features to collections.html
> a) "Split" shard
> b) "Delete" shard
> c) "Backup" collection
> d) "Restore" collection
> Open to suggestions and feedbacks on this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10209) UI: Convert all Collections api calls to async requests, add new features/buttons

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10209:

Description: 
We are having discussion on multiple jiras for requests for Collections apis 
from UI and how to improve them:

SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses connection 
with the server
SOLR-10146: Admin UI: Button to delete a shard
SOLR-10201: Add Collection "creates collection", "Connection to Solr lost", 
when replicationFactor>1

Proposal =>

*Phase 1:*

Convert all Collections api calls to async requests and utilise REQUESTSTATUS 
to fetch the information. There will be performance hit, but the requests will 
be safe and sound. A progress bar will be added for request status.
{noformat}
> submit the async request
if (the initial call failed or there was no status to be found)
{ report an error and suggest the user look check their system before 
resubmitting the request. Bail out in this case, no retries, no attempt to 
drive on. }
else
{ put up a progress indicator while periodically checking the status, Continue 
spinning until we can report the final status. }
{noformat}

*Phase 2:*

Add new buttons/features to collections.html

a) "Split" shard
b) "Delete" shard
c) "Backup" collection
d) "Restore" collection

Open to suggestions and feedbacks on this.

  was:
We are having discussion on multiple jiras for requests for Collections apis 
from UI and how to improve them:

SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses connection 
with the server
SOLR-10146: Admin UI: Button to delete a shard
SOLR-10201: Add Collection "creates collection", "Connection to Solr lost", 
when replicationFactor>1

Proposal =>

*Phase 1:*

Convert all Collections api calls to async requests and utilise REQUESTSTATUS 
to fetch the information. There will be performance hit, but the requests will 
be safe and sound.
{noformat}
> submit the async request
if (the initial call failed or there was no status to be found)
{ report an error and suggest the user look check their system before 
resubmitting the request. Bail out in this case, no retries, no attempt to 
drive on. }
else
{ put up a progress indicator while periodically checking the status, Continue 
spinning until we can report the final status. }
{noformat}

*Phase 2:*

Add new buttons/features to collections.html

a) "Split" shard
b) "Delete" shard
c) "Backup" collection
d) "Restore" collection

Open to suggestions and feedbacks on this.


> UI: Convert all Collections api calls to async requests, add new 
> features/buttons
> -
>
> Key: SOLR-10209
> URL: https://issues.apache.org/jira/browse/SOLR-10209
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Amrit Sarkar
>
> We are having discussion on multiple jiras for requests for Collections apis 
> from UI and how to improve them:
> SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses 
> connection with the server
> SOLR-10146: Admin UI: Button to delete a shard
> SOLR-10201: Add Collection "creates collection", "Connection to Solr lost", 
> when replicationFactor>1
> Proposal =>
> *Phase 1:*
> Convert all Collections api calls to async requests and utilise REQUESTSTATUS 
> to fetch the information. There will be performance hit, but the requests 
> will be safe and sound. A progress bar will be added for request status.
> {noformat}
> > submit the async request
> if (the initial call failed or there was no status to be found)
> { report an error and suggest the user look check their system before 
> resubmitting the request. Bail out in this case, no retries, no attempt to 
> drive on. }
> else
> { put up a progress indicator while periodically checking the status, 
> Continue spinning until we can report the final status. }
> {noformat}
> *Phase 2:*
> Add new buttons/features to collections.html
> a) "Split" shard
> b) "Delete" shard
> c) "Backup" collection
> d) "Restore" collection
> Open to suggestions and feedbacks on this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10209) UI: Convert all Collections api calls to async requests, add new features/buttons

[Amrit Sarkar (JIRA)]

Amrit Sarkar created SOLR-10209:
---

 Summary: UI: Convert all Collections api calls to async requests, 
add new features/buttons
 Key: SOLR-10209
 URL: https://issues.apache.org/jira/browse/SOLR-10209
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Admin UI
Reporter: Amrit Sarkar


We are having discussion on multiple jiras for requests for Collections apis 
from UI and how to improve them:

SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses connection 
with the server
SOLR-10146: Admin UI: Button to delete a shard
SOLR-10201: Add Collection "creates collection", "Connection to Solr lost", 
when replicationFactor>1

Proposal =>

*Phase 1:*

Convert all Collections api calls to async requests and utilise REQUESTSTATUS 
to fetch the information. There will be performance hit, but the requests will 
be safe and sound.
{noformat}
> submit the async request
if (the initial call failed or there was no status to be found)
{ report an error and suggest the user look check their system before 
resubmitting the request. Bail out in this case, no retries, no attempt to 
drive on. }
else
{ put up a progress indicator while periodically checking the status, Continue 
spinning until we can report the final status. }
{noformat}

*Phase 2:*

Add new buttons/features to collections.html

a) "Split" shard
b) "Delete" shard
c) "Backup" collection
d) "Restore" collection

Open to suggestions and feedbacks on this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 296 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/296/

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
ObjectTracker found 5 object(s) that were not released!!! [MMapDirectory, 
MMapDirectory, MDCAwareThreadPoolExecutor, MMapDirectory, SolrCore] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MMapDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.MetricsDirectoryFactory.get(MetricsDirectoryFactory.java:214)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:479)  
at org.apache.solr.core.SolrCore.(SolrCore.java:888)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:811)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:917)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:552)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MMapDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.MetricsDirectoryFactory.get(MetricsDirectoryFactory.java:214)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:348)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:677)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:894)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:811)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:917)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:552)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:834)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:811)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:917)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:552)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MMapDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.MetricsDirectoryFactory.get(MetricsDirectoryFactory.java:214)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:98)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:709)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:894)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:811)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:917)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:552)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 

[jira] [Updated] (SOLR-10182) Backout directory metrics collection that caused performance degradation

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-10182:
-
Fix Version/s: master (7.0)
   6.5

> Backout directory metrics collection that caused performance degradation
> 
>
> Key: SOLR-10182
> URL: https://issues.apache.org/jira/browse/SOLR-10182
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1, 6.4.0
>Reporter: Ishan Chattopadhyaya
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 6.5, master (7.0), 6.4.2
>
> Attachments: SOLR-10182.patch
>
>
> The performance degradation we observed as per SOLR-10130 will go away if 
> directory factory level metrics collection is disabled by default. However, 
> since they will cause the same degradation when enabled, we should back out 
> those changes until we find a performant way of implementing such metrics 
> collection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-9530) Add an Atomic Update Processor

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar edited comment on SOLR-9530 at 2/27/17 3:44 PM:
-

As discussed, the system will handle race conditions gracefully. The URP will 
fetch the _version_ before sending the appropriate atomic operation using 
optimistic concurrency. if the request fails , it with retry with updated 
_version_.

Working on the latest developments.


was (Author: sarkaramr...@gmail.com):
As discussed, the system will handle race conditions gracefully. The URP will 
fetch the _version_ before sending the appropriate atomic operation using 
optimistic concurrency. if the request fails , it with retry with updated 
{code}_version_ {code}.

Working on the latest developments.

> Add an Atomic Update Processor 
> ---
>
> Key: SOLR-9530
> URL: https://issues.apache.org/jira/browse/SOLR-9530
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
> Attachments: SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch
>
>
> I'd like to explore the idea of adding a new update processor to help ingest 
> partial updates.
> Example use-case - There are two datasets with a common id field. How can I 
> merge both of them at index time?
> Proposed Solution: 
> {code}
> 
>   
> add
>   
>   
>   
> 
> {code}
> So the first JSON dump could be ingested against 
> {{http://localhost:8983/solr/gettingstarted/update/json}}
> And then the second JSON could be ingested against
> {{http://localhost:8983/solr/gettingstarted/update/json?processor=atomic}}
> The Atomic Update Processor could support all the atomic update operations 
> currently supported.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9530) Add an Atomic Update Processor

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-9530:


As discussed, the system will handle race conditions gracefully. The URP will 
fetch the _version_ before sending the appropriate atomic operation using 
optimistic concurrency. if the request fails , it with retry with updated 
{code}_version_ {code}.

Working on the latest developments.

> Add an Atomic Update Processor 
> ---
>
> Key: SOLR-9530
> URL: https://issues.apache.org/jira/browse/SOLR-9530
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
> Attachments: SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch
>
>
> I'd like to explore the idea of adding a new update processor to help ingest 
> partial updates.
> Example use-case - There are two datasets with a common id field. How can I 
> merge both of them at index time?
> Proposed Solution: 
> {code}
> 
>   
> add
>   
>   
>   
> 
> {code}
> So the first JSON dump could be ingested against 
> {{http://localhost:8983/solr/gettingstarted/update/json}}
> And then the second JSON could be ingested against
> {{http://localhost:8983/solr/gettingstarted/update/json?processor=atomic}}
> The Atomic Update Processor could support all the atomic update operations 
> currently supported.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-10182) Backout directory metrics collection that caused performance degradation

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-10182.
--
Resolution: Fixed

> Backout directory metrics collection that caused performance degradation
> 
>
> Key: SOLR-10182
> URL: https://issues.apache.org/jira/browse/SOLR-10182
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1, 6.4.0
>Reporter: Ishan Chattopadhyaya
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 6.5, master (7.0), 6.4.2
>
> Attachments: SOLR-10182.patch
>
>
> The performance degradation we observed as per SOLR-10130 will go away if 
> directory factory level metrics collection is disabled by default. However, 
> since they will cause the same degradation when enabled, we should back out 
> those changes until we find a performant way of implementing such metrics 
> collection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10182) Backout directory metrics collection that caused performance degradation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10182:


Commit a248e6e3c080cfe6deb873d1ef114e4b9c1c043d in lucene-solr's branch 
refs/heads/master from [~ab]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a248e6e ]

SOLR-10182 Remove metrics collection at Directory level.


> Backout directory metrics collection that caused performance degradation
> 
>
> Key: SOLR-10182
> URL: https://issues.apache.org/jira/browse/SOLR-10182
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1, 6.4.0
>Reporter: Ishan Chattopadhyaya
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 6.4.2
>
> Attachments: SOLR-10182.patch
>
>
> The performance degradation we observed as per SOLR-10130 will go away if 
> directory factory level metrics collection is disabled by default. However, 
> since they will cause the same degradation when enabled, we should back out 
> those changes until we find a performant way of implementing such metrics 
> collection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: 6.4.2 release?

[Christine Poerschke (BLOOMBERG/ LONDON)]

https://issues.apache.org/jira/browse/SOLR-10192 copy/paste fix just backported 
to branch_6_4 but happy to revert if there were to be any concerns about it.

Thanks,
Christine

From: ichattopadhy...@gmail.com At: 02/21/17 18:05:35
To: dev@lucene.apache.org
Cc: Christine Poerschke (BLOOMBERG/ LONDON)
Subject: Re: 6.4.2 release?

I would like to volunteer for this 6.4.2 release. Planning to cut a RC as soon 
as blockers are resolved.
One of the unresolved blocker issues seems to be LUCENE-7698 (I'll take a look 
to see if there are more). If there are more issues that should be part of the 
release, please let me know or mark as blockers in jira.

Thanks,
Ishan


On Thu, Feb 16, 2017 at 3:48 AM, Adrien Grand  wrote:

I had initially planned on releasing tomorrow but the mirrors replicated faster 
than I had thought they would so I finished the release today, including the 
addition of the new 5.5.4 indices for backward testing so I am good with 
proceeding with a new release now.

Le mer. 15 févr. 2017 à 16:13, Adrien Grand  a écrit :

+1

One ask I have is to wait for the 5.5.4 release process to be complete so that 
branch_6_4 has the 5.5.4 backward indices when we cut the first RC. I will let 
you know when I am done.

Le mer. 15 févr. 2017 à 15:53, Christine Poerschke (BLOOMBERG/ LONDON) 
 a écrit :

Hi,

These two could be minor candidates for inclusion:

* https://issues.apache.org/jira/browse/SOLR-10083
  Fix instanceof check in ConstDoubleSource.equals

* https://issues.apache.org/jira/browse/LUCENE-7676
  FilterCodecReader to override more super-class methods

The former had narrowly missed the 6.4.1 release.

Regards,

Christine

From: dev@lucene.apache.org At: 02/15/17 14:27:52
To: dev@lucene.apache.org
Subject: Re:6.4.2 release?

Hi devs,

These two issues seem serious enough to warrant a new release from branch_6_4:
* SOLR-10130: Serious performance degradation in Solr 6.4.1 due to the new 
metrics collection
* SOLR-10138: Transaction log replay can hit an NPE due to new Metrics code.

What do you think? Anything else that should go there?

---
Best regards,

Andrzej Bialecki 

[jira] [Resolved] (SOLR-10192) fix copy/paste in solr/contrib/ltr/pom.xml.template

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-10192.

   Resolution: Fixed
Fix Version/s: 6.4.2
   master (7.0)
   6.x

> fix copy/paste in solr/contrib/ltr/pom.xml.template
> ---
>
> Key: SOLR-10192
> URL: https://issues.apache.org/jira/browse/SOLR-10192
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.4.1, master (7.0), 6.4.0
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Blocker
> Fix For: 6.x, master (7.0), 6.4.2
>
> Attachments: SOLR-10192.patch
>
>
> In 
> [dev-tools/maven/solr/contrib/ltr/pom.xml.template|https://github.com/apache/lucene-solr/blob/master/dev-tools/maven/solr/contrib/ltr/pom.xml.template]
>  turn a few analytics bits into ltr essentially.
> Randomly noticed on 
> http://mvnrepository.com/artifact/org.apache.solr/solr-ltr entry.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10192) fix copy/paste in solr/contrib/ltr/pom.xml.template

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10192:


Commit 1791164d8c234da64248462746e7c20bacdaeee5 in lucene-solr's branch 
refs/heads/branch_6_4 from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1791164 ]

SOLR-10192: Fix copy/paste in solr-ltr pom.xml template.


> fix copy/paste in solr/contrib/ltr/pom.xml.template
> ---
>
> Key: SOLR-10192
> URL: https://issues.apache.org/jira/browse/SOLR-10192
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.4.1, master (7.0), 6.4.0
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Blocker
> Attachments: SOLR-10192.patch
>
>
> In 
> [dev-tools/maven/solr/contrib/ltr/pom.xml.template|https://github.com/apache/lucene-solr/blob/master/dev-tools/maven/solr/contrib/ltr/pom.xml.template]
>  turn a few analytics bits into ltr essentially.
> Randomly noticed on 
> http://mvnrepository.com/artifact/org.apache.solr/solr-ltr entry.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10192) fix copy/paste in solr/contrib/ltr/pom.xml.template

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10192:


Commit 4b8223b77f58da852fea0f6961ede6ddfd80929a in lucene-solr's branch 
refs/heads/branch_6x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4b8223b ]

SOLR-10192: Fix copy/paste in solr-ltr pom.xml template.


> fix copy/paste in solr/contrib/ltr/pom.xml.template
> ---
>
> Key: SOLR-10192
> URL: https://issues.apache.org/jira/browse/SOLR-10192
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.4.1, master (7.0), 6.4.0
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Blocker
> Attachments: SOLR-10192.patch
>
>
> In 
> [dev-tools/maven/solr/contrib/ltr/pom.xml.template|https://github.com/apache/lucene-solr/blob/master/dev-tools/maven/solr/contrib/ltr/pom.xml.template]
>  turn a few analytics bits into ltr essentially.
> Randomly noticed on 
> http://mvnrepository.com/artifact/org.apache.solr/solr-ltr entry.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10192) fix copy/paste in solr/contrib/ltr/pom.xml.template

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10192:


Commit 048b24c64a9b1a41e2f7c2bd3ca1c818ddd916df in lucene-solr's branch 
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=048b24c ]

SOLR-10192: Fix copy/paste in solr-ltr pom.xml template.


> fix copy/paste in solr/contrib/ltr/pom.xml.template
> ---
>
> Key: SOLR-10192
> URL: https://issues.apache.org/jira/browse/SOLR-10192
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.4.1, master (7.0), 6.4.0
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Blocker
> Attachments: SOLR-10192.patch
>
>
> In 
> [dev-tools/maven/solr/contrib/ltr/pom.xml.template|https://github.com/apache/lucene-solr/blob/master/dev-tools/maven/solr/contrib/ltr/pom.xml.template]
>  turn a few analytics bits into ltr essentially.
> Randomly noticed on 
> http://mvnrepository.com/artifact/org.apache.solr/solr-ltr entry.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1159 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1159/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.TestDistributedSearch.test

Error Message:
Expected to find shardAddress in the up shard info: 
{error=org.apache.solr.client.solrj.SolrServerException: No live SolrServers 
available to handle this 
request,trace=org.apache.solr.client.solrj.SolrServerException: No live 
SolrServers available to handle this request  at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:416)
  at 
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:259)
  at 
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:166)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745) ,time=1}

Stack Trace:
java.lang.AssertionError: Expected to find shardAddress in the up shard info: 
{error=org.apache.solr.client.solrj.SolrServerException: No live SolrServers 
available to handle this 
request,trace=org.apache.solr.client.solrj.SolrServerException: No live 
SolrServers available to handle this request
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:416)
at 
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:259)
at 
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:166)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
,time=1}
at 
__randomizedtesting.SeedInfo.seed([2BBA129E318CD928:A3EE2D449F70B4D0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.TestDistributedSearch.comparePartialResponses(TestDistributedSearch.java:1186)
at 
org.apache.solr.TestDistributedSearch.queryPartialResults(TestDistributedSearch.java:1127)
at 
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:987)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1011)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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 

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+158) - Build # 2955 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2955/
Java: 64bit/jdk-9-ea+158 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([D5E9E36D7ABF3F16:5ECE30BC3BB99492]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:865)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437)
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:547)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[jira] [Commented] (SOLR-10182) Backout directory metrics collection that caused performance degradation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10182:


Commit f78e1c6866eb7707d5a802851a85bcfffcaa904e in lucene-solr's branch 
refs/heads/branch_6x from [~ab]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f78e1c6 ]

SOLR-10182 Remove metrics collection at Directory level.


> Backout directory metrics collection that caused performance degradation
> 
>
> Key: SOLR-10182
> URL: https://issues.apache.org/jira/browse/SOLR-10182
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1, 6.4.0
>Reporter: Ishan Chattopadhyaya
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 6.4.2
>
> Attachments: SOLR-10182.patch
>
>
> The performance degradation we observed as per SOLR-10130 will go away if 
> directory factory level metrics collection is disabled by default. However, 
> since they will cause the same degradation when enabled, we should back out 
> those changes until we find a performant way of implementing such metrics 
> collection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 724 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/724/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.cloud.TestCloudPivotFacet.test

Error Message:
pivot_z_s1,pivot_d1,pivot_tdt: count query failed: 
{main(rows=0=*:*=true={!key%3Dsk1+tag%3Dst1,st2}pivot_d={!key%3Dsk2+tag%3Dst2,st3}pivot_tdt={!key%3Dsk3+tag%3Dst3,st4}pivot_f&_test_distrib_min=true),extra(fq={!term+f%3Dpivot_z_s1}u)}:
 No live SolrServers available to handle this 
request:[http://127.0.0.1:49518/wbs/collection1, 
http://127.0.0.1:49501/wbs/collection1]

Stack Trace:
java.lang.RuntimeException: pivot_z_s1,pivot_d1,pivot_tdt: count query failed: 
{main(rows=0=*:*=true={!key%3Dsk1+tag%3Dst1,st2}pivot_d={!key%3Dsk2+tag%3Dst2,st3}pivot_tdt={!key%3Dsk3+tag%3Dst3,st4}pivot_f&_test_distrib_min=true),extra(fq={!term+f%3Dpivot_z_s1}u)}:
 No live SolrServers available to handle this 
request:[http://127.0.0.1:49518/wbs/collection1, 
http://127.0.0.1:49501/wbs/collection1]
at 
__randomizedtesting.SeedInfo.seed([4EFC9AB8E5863CC0:C6A8A5624B7A5138]:0)
at 
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:322)
at 
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:287)
at 
org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:244)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[JENKINS] Lucene-Solr-Tests-6.x - Build # 756 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/756/

2 tests failed.
FAILED:  org.apache.solr.cloud.TestLeaderElectionWithEmptyReplica.test

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([FCD3C46C1855682A:7487FBB6B6A905D2]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1251)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:702)
at 
org.apache.solr.cloud.TestLeaderElectionWithEmptyReplica.test(TestLeaderElectionWithEmptyReplica.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 
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.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest.test

Error Message:
Mismatch in counts between replicas

Stack Trace:
java.lang.AssertionError: Mismatch in counts between replicas
at 
__randomizedtesting.SeedInfo.seed([FCD3C46C1855682A:7487FBB6B6A905D2]:0)
at 

[jira] [Commented] (SOLR-10182) Backout directory metrics collection that caused performance degradation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10182:


Commit f622d0ef2bf66245cdf11f3abc67851d9ed73a44 in lucene-solr's branch 
refs/heads/branch_6_4 from [~ab]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f622d0e ]

SOLR-10182 Remove metrics collection at Directory level.


> Backout directory metrics collection that caused performance degradation
> 
>
> Key: SOLR-10182
> URL: https://issues.apache.org/jira/browse/SOLR-10182
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1, 6.4.0
>Reporter: Ishan Chattopadhyaya
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 6.4.2
>
> Attachments: SOLR-10182.patch
>
>
> The performance degradation we observed as per SOLR-10130 will go away if 
> directory factory level metrics collection is disabled by default. However, 
> since they will cause the same degradation when enabled, we should back out 
> those changes until we find a performant way of implementing such metrics 
> collection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7714) Optimize range queries for the sorted case

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-7714:


 Summary: Optimize range queries for the sorted case
 Key: LUCENE-7714
 URL: https://issues.apache.org/jira/browse/LUCENE-7714
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Priority: Minor


It feels like we could make range queries faster when the index is sorted, 
maybe by running on doc values, figuring ou the first and last matching 
documents with a binary search and returning a doc id set iterator that 
iterates through this range of documents?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7713) Optimize TopFieldDocCollector for the sorted case

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-7713:


 Summary: Optimize TopFieldDocCollector for the sorted case
 Key: LUCENE-7713
 URL: https://issues.apache.org/jira/browse/LUCENE-7713
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor


When the sort order is a prefix of the index sort order, 
{{TopFieldDocCollector}} could skip reading doc values and comparing them 
against the bottom value after {{numHits}} documents have been collected, and 
just count matches.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10182) Backout directory metrics collection that caused performance degradation

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-10182:
--

Yes, i applied both patches to our 6.4.1 and deployed it. Solr is running fast 
once again.

> Backout directory metrics collection that caused performance degradation
> 
>
> Key: SOLR-10182
> URL: https://issues.apache.org/jira/browse/SOLR-10182
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1, 6.4.0
>Reporter: Ishan Chattopadhyaya
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 6.4.2
>
> Attachments: SOLR-10182.patch
>
>
> The performance degradation we observed as per SOLR-10130 will go away if 
> directory factory level metrics collection is disabled by default. However, 
> since they will cause the same degradation when enabled, we should back out 
> those changes until we find a performant way of implementing such metrics 
> collection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10182) Backout directory metrics collection that caused performance degradation

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10182:
-

+1, LGTM.

> Backout directory metrics collection that caused performance degradation
> 
>
> Key: SOLR-10182
> URL: https://issues.apache.org/jira/browse/SOLR-10182
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1, 6.4.0
>Reporter: Ishan Chattopadhyaya
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 6.4.2
>
> Attachments: SOLR-10182.patch
>
>
> The performance degradation we observed as per SOLR-10130 will go away if 
> directory factory level metrics collection is disabled by default. However, 
> since they will cause the same degradation when enabled, we should back out 
> those changes until we find a performant way of implementing such metrics 
> collection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 1249 - Failure

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test

Error Message:
Error from server at http://127.0.0.1:53607/h_nz/as/collection1: this 
IndexWriter is closed

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:53607/h_nz/as/collection1: this IndexWriter is 
closed
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:627)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1538)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:664)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+158) - Build # 2954 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2954/
Java: 32bit/jdk-9-ea+158 -client -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew

Error Message:
expected:<200> but was:<403>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<403>
at 
__randomizedtesting.SeedInfo.seed([A96F8CD68E8CF8E4:9EF478C8B6402540]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.renewDelegationToken(TestSolrCloudWithDelegationTokens.java:131)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.verifyDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:317)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:334)
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:547)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[jira] [Commented] (SOLR-9835) Create another replication mode for SolrCloud

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9835:
-

# Dat, can you please add javadocs for all the new methods in UpdateLog?
# I was looking into SOLR-9706 and it applies to this patch too. However, the 
fix is easy because most of the corruption checks added by SOLR-6640 aren't 
necessary in this new replication mode so we can safely skip them.

> Create another replication mode for SolrCloud
> -
>
> Key: SOLR-9835
> URL: https://issues.apache.org/jira/browse/SOLR-9835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch
>
>
> The current replication mechanism of SolrCloud is called state machine, which 
> replicas start in same initial state and for each input, the input is 
> distributed across replicas so all replicas will end up with same next state. 
> But this type of replication have some drawbacks
> - The commit (which costly) have to run on all replicas
> - Slow recovery, because if replica miss more than N updates on its down 
> time, the replica have to download entire index from its leader.
> So we create create another replication mode for SolrCloud called state 
> transfer, which acts like master/slave replication. In basically
> - Leader distribute the update to other replicas, but the leader only apply 
> the update to IW, other replicas just store the update to UpdateLog (act like 
> replication).
> - Replicas frequently polling the latest segments from leader.
> Pros:
> - Lightweight for indexing, because only leader are running the commit, 
> updates.
> - Very fast recovery, replicas just have to download the missing segments.
> On CAP point of view, this ticket will trying to promise to end users a 
> distributed systems :
> - Partition tolerance
> - Weak Consistency for normal query : clusters can serve stale data. This 
> happen when leader finish a commit and slave is fetching for latest segment. 
> This period can at most {{pollInterval + time to fetch latest segment}}.
> - Consistency for RTG : if we *do not use DQBs*, replicas will consistence 
> with master just like original SolrCloud mode
> - Weak Availability : just like original SolrCloud mode. If a leader down, 
> client must wait until new leader being elected.
> To use this new replication mode, a new collection must be created with an 
> additional parameter {{liveReplicas=1}}
> {code}
> http://localhost:8983/solr/admin/collections?action=CREATE=newCollection=2=1=1
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10182) Backout directory metrics collection that caused performance degradation

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-10182:
-
Attachment: SOLR-10182.patch

This patch completely removes Directory-level metrics collection.

> Backout directory metrics collection that caused performance degradation
> 
>
> Key: SOLR-10182
> URL: https://issues.apache.org/jira/browse/SOLR-10182
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1, 6.4.0
>Reporter: Ishan Chattopadhyaya
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 6.4.2
>
> Attachments: SOLR-10182.patch
>
>
> The performance degradation we observed as per SOLR-10130 will go away if 
> directory factory level metrics collection is disabled by default. However, 
> since they will cause the same degradation when enabled, we should back out 
> those changes until we find a performant way of implementing such metrics 
> collection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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