date:20171024

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20729/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 38280 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.5
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.LeaderElectionContextKeyTest 
(LeaderElectionContextKeyTest.java:81)
[forbidden-apis] Scanned 3878 class file(s) for forbidden API invocations (in 
1.84s), 1 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:826: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build.xml:376: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/common-build.xml:534: 
Check for forbidden API calls failed, see log.

Total time: 79 minutes 21 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Commented] (LUCENE-8009) Support disabling Locale randomization as part of Lucene test framework

2017-10-24 Thread Dawid Weiss (JIRA)


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

Dawid Weiss commented on LUCENE-8009:
-

Thank you Hrishikesh. I will review and commit your patch once you submit it. 
Please take a look at the existing Suppress... annotations and how they work in 
LuceneTestCase -- follow the examples.

> Support disabling Locale randomization as part of Lucene test framework
> ---
>
> Key: LUCENE-8009
> URL: https://issues.apache.org/jira/browse/LUCENE-8009
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/test-framework
>Affects Versions: 7.1
>Reporter: Hrishikesh Gadre
>Priority: Minor
>
> The Lucene test framework randomizes the Locale configuration to test the 
> software in different locale settings.
> https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/lucene/test-framework/src/java/org/apache/lucene/util/TestRuleSetupAndRestoreClassEnv.java#L206-L209
> While this is a very good practice from engineering perspective, it causes 
> issues when the Lucene/Solr test framework is used with third-party 
> components which may have issues working with a subset of locale settings. 
> e.g. for Solr/Sentry integration (SENTRY-1475), we are using Solr test 
> framework to test the sentry authorization plugin for Solr. For unit-testing, 
> it uses Apache Derby. We have found multiple cases when derby fail to 
> initialize for a locale configured by Solr test framework. This causes tests 
> to fail and create a confusion with respect to the quality of the integration 
> source-code. Since the Derby failures are not related to Solr/Sentry 
> integration, we would like to avoid such nasty surprises by suppressing the 
> locale randomization. This is similar to the way we suppress Solr SSL 
> configuration (@SolrTestCaseJ4.SuppressSSL).
> Please refer to discussion on dev mailing list for more context,
> http://lucene.472066.n3.nabble.com/Solr-test-framework-Locale-randomization-td4359671.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11326) CDCR bootstrap should not download tlog's from source

2017-10-24 Thread Amrit Sarkar (JIRA)


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

Amrit Sarkar updated SOLR-11326:

Attachment: SOLR-11326.patch

Varun, there was a small test bug in the patch. Fixed it, ran beasts of 
hundreds of rounds. This is ready to ship.

> CDCR bootstrap should not download tlog's from source
> -
>
> Key: SOLR-11326
> URL: https://issues.apache.org/jira/browse/SOLR-11326
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-11326.patch, SOLR-11326.patch, SOLR-11326.patch, 
> SOLR-11326.patch, SOLR-11326.patch, SOLR-11326.patch, WITHOUT-FIX.patch
>
>
> While analyzing two separate fails on SOLR-11278 I see that during bootstrap 
> the tlog's from the source is getting download
> snippet1:
> {code}
>[junit4]   2> 42931 INFO  (qtp1525032019-69) [n:127.0.0.1:53178_solr 
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1] 
> o.a.s.h.CdcrReplicatorManager Submitting bootstrap task to executor
>[junit4]   2> 42934 INFO  
> (cdcr-bootstrap-status-32-thread-1-processing-n:127.0.0.1:53178_solr 
> x:cdcr-source_shard1_replica1 s:shard1 c:cdcr-source r:core_node1) 
> [n:127.0.0.1:53178_solr c:cdcr-source s:shard1 r:core_node1 
> x:cdcr-source_shard1_replica1] o.a.s.h.CdcrReplicatorManager Attempting to 
> bootstrap target collection: cdcr-target shard: shard1 leader: 
> http://127.0.0.1:53170/solr/cdcr-target_shard1_replica1/
>[junit4]   2> 43003 INFO  (qtp1525032019-69) [n:127.0.0.1:53178_solr 
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1] 
> o.a.s.c.S.Request [cdcr-source_shard1_replica1]  webapp=/solr 
> path=/replication 
> params={qt=/replication=javabin=2=indexversion} status=0 
> QTime=0
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Master's generation: 12
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Master's version: 
> 1503514968639
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Slave's generation: 1
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Slave's version: 0
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Starting replication 
> process
>[junit4]   2> 43041 INFO  (qtp1525032019-71) [n:127.0.0.1:53178_solr 
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1] 
> o.a.s.h.ReplicationHandler Adding tlog files to list: [{size=4649, 
> name=tlog.000.1576549701811961856}, {size=4770, 
> name=tlog.001.1576549702515556352}, {size=4770, 
> name=tlog.002.1576549702628802560}, {size=4770, 
> name=tlog.003.1576549702720028672}, {size=4770, 
> name=tlog.004.1576549702799720448}, {size=4770, 
> name=tlog.005.1576549702894092288}, {size=4770, 
> name=tlog.006.1576549703029358592}, {size=4770, 
> name=tlog.007.1576549703126876160}, {size=4770, 
> name=tlog.008.1576549703208665088}, {size=4770, 
> name=tlog.009.1576549703295696896}
> {code}
> snippet2:
> {code}
>  17070[junit4]   2> 677606 INFO  (qtp22544544-5725) [] 
> o.a.s.h.CdcrReplicatorManager Attempting to bootstrap target collection: 
> cdcr-target, shard: shard1^M
>  17071[junit4]   2> 677608 INFO  (qtp22544544-5725) [] 
> o.a.s.h.CdcrReplicatorManager Submitting bootstrap task to executor^M
> 17091[junit4]   2> 677627 INFO  (qtp22544544-5724) [] 
> o.a.s.c.S.Request [cdcr-source_shard1_replica_n1]  webapp=/solr 
> path=/replication 
>

[jira] [Updated] (SOLR-11532) Solr hits NPE when fl only contains DV fields and any of them is a spatial field


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

Cao Manh Dat updated SOLR-11532:

Description: 
Right now, Solr does not know how to decode DV value of 
LatLonPointSpatialField. Therefore, Solr will hit NPE when trying to do that, 
for example: 
- when fl contains a spatial field and it is DV + not stored
- when fl only contains DV fields and any of them is a spatial field ( stored + 
DV ). Because SOLR-8344 will always use values from DV fields. This seems a 
common case.

Stacktrace (from Solr 7.1)
{code}
2017-10-23 10:28:52,528 [qtp1649011739-67] ERROR HttpSolrCall  - 
null:java.lang.NullPointerException
at 
org.apache.solr.search.SolrDocumentFetcher.decorateDocValueFields(SolrDocumentFetcher.java:525)
at org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:108)
at org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:57)
at 
org.apache.solr.response.BinaryResponseWriter$Resolver.writeResultsBody(BinaryResponseWriter.java:126)
at 
org.apache.solr.response.BinaryResponseWriter$Resolver.writeResults(BinaryResponseWriter.java:145)
at 
org.apache.solr.response.BinaryResponseWriter$Resolver.resolve(BinaryResponseWriter.java:89)
at org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:239)
at 
org.apache.solr.common.util.JavaBinCodec.writeNamedList(JavaBinCodec.java:223)
at 
org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:330)
at org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:228)
at org.apache.solr.common.util.JavaBinCodec.marshal(JavaBinCodec.java:155)
{code}

This bug found by [~kiranch]. 

The only solution for this problem is adding a stored field only in fl.

  was:
Right now, Solr does not know how to decode DV value of 
LatLonPointSpatialField. Therefore, Solr will hit NPE when trying to do that, 
for example: 
- when fl contains a spatial field and it is DV + not stored
- when fl only contains DV fields and any of them is a spatial field ( stored + 
DV ). Because SOLR-8344 will always use values from DV fields. This seems a 
common case.

Stacktrace (from Solr 7.1)
{code}
2017-10-23 10:28:52,528 [qtp1649011739-67] ERROR HttpSolrCall  - 
null:java.lang.NullPointerException
at 
org.apache.solr.search.SolrDocumentFetcher.decorateDocValueFields(SolrDocumentFetcher.java:525)
at org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:108)
at org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:57)
at 
org.apache.solr.response.BinaryResponseWriter$Resolver.writeResultsBody(BinaryResponseWriter.java:126)
at 
org.apache.solr.response.BinaryResponseWriter$Resolver.writeResults(BinaryResponseWriter.java:145)
at 
org.apache.solr.response.BinaryResponseWriter$Resolver.resolve(BinaryResponseWriter.java:89)
at org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:239)
at 
org.apache.solr.common.util.JavaBinCodec.writeNamedList(JavaBinCodec.java:223)
at 
org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:330)
at org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:228)
at org.apache.solr.common.util.JavaBinCodec.marshal(JavaBinCodec.java:155)
{code}

This bug found by [~kiranch]


> Solr hits NPE when fl only contains DV fields and any of them is a spatial 
> field
> 
>
> Key: SOLR-11532
> URL: https://issues.apache.org/jira/browse/SOLR-11532
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Affects Versions: 7.1
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
> Attachments: SOLR-11532-test.patch, SOLR-11532.patch
>
>
> Right now, Solr does not know how to decode DV value of 
> LatLonPointSpatialField. Therefore, Solr will hit NPE when trying to do that, 
> for example: 
> - when fl contains a spatial field and it is DV + not stored
> - when fl only contains DV fields and any of them is a spatial field ( stored 
> + DV ). Because SOLR-8344 will always use values from DV fields. This seems a 
> common case.
> Stacktrace (from Solr 7.1)
> {code}
> 2017-10-23 10:28:52,528 [qtp1649011739-67] ERROR HttpSolrCall  - 
> null:java.lang.NullPointerException
> at 
> org.apache.solr.search.SolrDocumentFetcher.decorateDocValueFields(SolrDocumentFetcher.java:525)
> at org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:108)
> at org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:57)
> at 
> org.apache.solr.response.BinaryResponseWriter$Resolver.writeResultsBody(BinaryResponseWriter.java:126)
> at 
> org.apache.solr.response.BinaryResponseWriter$Resolver.writeResults(BinaryResponseWriter.java:145)
>

[jira] [Updated] (SOLR-11532) Solr hits NPE when fl only contains DV fields and any of them is a spatial field


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

Cao Manh Dat updated SOLR-11532:

Attachment: SOLR-11532.patch

Here is my patch for this ticket. Aiming to handle not decodable fields 
carefully. 
- {{RetrieveFieldsOptimizer}} will only use DV for fields that are decodable.
- {{SolrDocumentFetcher}} will handle decoding DV more carefully. If there are 
an Exception in decode a DV, it will fall-back on using stored value instead.

> Solr hits NPE when fl only contains DV fields and any of them is a spatial 
> field
> 
>
> Key: SOLR-11532
> URL: https://issues.apache.org/jira/browse/SOLR-11532
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Affects Versions: 7.1
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
> Attachments: SOLR-11532-test.patch, SOLR-11532.patch
>
>
> Right now, Solr does not know how to decode DV value of 
> LatLonPointSpatialField. Therefore, Solr will hit NPE when trying to do that, 
> for example: 
> - when fl contains a spatial field and it is DV + not stored
> - when fl only contains DV fields and any of them is a spatial field ( stored 
> + DV ). Because SOLR-8344 will always use values from DV fields. This seems a 
> common case.
> Stacktrace (from Solr 7.1)
> {code}
> 2017-10-23 10:28:52,528 [qtp1649011739-67] ERROR HttpSolrCall  - 
> null:java.lang.NullPointerException
> at 
> org.apache.solr.search.SolrDocumentFetcher.decorateDocValueFields(SolrDocumentFetcher.java:525)
> at org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:108)
> at org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:57)
> at 
> org.apache.solr.response.BinaryResponseWriter$Resolver.writeResultsBody(BinaryResponseWriter.java:126)
> at 
> org.apache.solr.response.BinaryResponseWriter$Resolver.writeResults(BinaryResponseWriter.java:145)
> at 
> org.apache.solr.response.BinaryResponseWriter$Resolver.resolve(BinaryResponseWriter.java:89)
> at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:239)
> at 
> org.apache.solr.common.util.JavaBinCodec.writeNamedList(JavaBinCodec.java:223)
> at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:330)
> at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:228)
> at org.apache.solr.common.util.JavaBinCodec.marshal(JavaBinCodec.java:155)
> {code}
> This bug found by [~kiranch]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11532) Solr hits NPE when fl only contains DV fields and any of them is a spatial field


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

Cao Manh Dat edited comment on SOLR-11532 at 10/25/17 4:35 AM:
---

Here is my patch for this ticket. Aiming to handle not decodable fields 
carefully. 
- {{RetrieveFieldsOptimizer}} will only use DV for fields that are decodable.
- {{SolrDocumentFetcher}} will handle decoding DV more carefully. If there are 
an Exception in decode a DV, it will fall-back on using stored value instead.

[~dsmiley] [~steve_rowe] What do your guys think?


was (Author: caomanhdat):
Here is my patch for this ticket. Aiming to handle not decodable fields 
carefully. 
- {{RetrieveFieldsOptimizer}} will only use DV for fields that are decodable.
- {{SolrDocumentFetcher}} will handle decoding DV more carefully. If there are 
an Exception in decode a DV, it will fall-back on using stored value instead.

> Solr hits NPE when fl only contains DV fields and any of them is a spatial 
> field
> 
>
> Key: SOLR-11532
> URL: https://issues.apache.org/jira/browse/SOLR-11532
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Affects Versions: 7.1
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
> Attachments: SOLR-11532-test.patch, SOLR-11532.patch
>
>
> Right now, Solr does not know how to decode DV value of 
> LatLonPointSpatialField. Therefore, Solr will hit NPE when trying to do that, 
> for example: 
> - when fl contains a spatial field and it is DV + not stored
> - when fl only contains DV fields and any of them is a spatial field ( stored 
> + DV ). Because SOLR-8344 will always use values from DV fields. This seems a 
> common case.
> Stacktrace (from Solr 7.1)
> {code}
> 2017-10-23 10:28:52,528 [qtp1649011739-67] ERROR HttpSolrCall  - 
> null:java.lang.NullPointerException
> at 
> org.apache.solr.search.SolrDocumentFetcher.decorateDocValueFields(SolrDocumentFetcher.java:525)
> at org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:108)
> at org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:57)
> at 
> org.apache.solr.response.BinaryResponseWriter$Resolver.writeResultsBody(BinaryResponseWriter.java:126)
> at 
> org.apache.solr.response.BinaryResponseWriter$Resolver.writeResults(BinaryResponseWriter.java:145)
> at 
> org.apache.solr.response.BinaryResponseWriter$Resolver.resolve(BinaryResponseWriter.java:89)
> at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:239)
> at 
> org.apache.solr.common.util.JavaBinCodec.writeNamedList(JavaBinCodec.java:223)
> at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:330)
> at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:228)
> at org.apache.solr.common.util.JavaBinCodec.marshal(JavaBinCodec.java:155)
> {code}
> This bug found by [~kiranch]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 663 - Failure!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/663/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseConcMarkSweepGC

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

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:42723

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:42723
at 
__randomizedtesting.SeedInfo.seed([1B771AC640AC5D20:9323251CEE5030D8]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.ShardSplitTest.splitShard(ShardSplitTest.java:936)
at 
org.apache.solr.cloud.ShardSplitTest.splitByRouteKeyTest(ShardSplitTest.java:805)
at org.apache.solr.cloud.ShardSplitTest.test(ShardSplitTest.java:102)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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

[jira] [Commented] (SOLR-11542) Add feature to DistributedURP to route time partitioned collections


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

David Smiley commented on SOLR-11542:
-

I've started on some tests... which will also be useful to debug/understand the 
code path through DistributedURP.

What to do when a document's timestamp precedes the earliest collection?  
Probably fail -- but could be parameterized later to ignore/drop.

> Add feature to DistributedURP to route time partitioned collections
> ---
>
> Key: SOLR-11542
> URL: https://issues.apache.org/jira/browse/SOLR-11542
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
> Fix For: 7.2
>
>
> Assuming we have some time partitioning metadata on an alias (see SOLR-11487 
> for the metadata facility), we'll then need to route documents to the right 
> collection.  I tentatively propose a helper class to DistributedURP to do 
> this.  Perhaps a separate URP is plausible, though it will take some 
> modifications to DistributedURP.
> The scope of this issue is:
> * decide on some alias metadata names & semantics
> * decide the collection suffix pattern.  Read/write code (needed to route).
> * the routing code
> No new partition creation nor deletion happens is this issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 1492 - Failure!

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 1) 
Thread[id=41174, name=jetty-launcher-8209-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth] 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:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)   
 2) Thread[id=41184, name=jetty-launcher-8209-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth] 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:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 
   1) Thread[id=41174, name=jetty-launcher-8209-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth]
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] [Commented] (SOLR-11526) CollectionAdminResponse.isSuccess() incorrect for most admin collections APIs

2017-10-24 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski commented on SOLR-11526:


For CreateShard (and the other collection APIs I classified in the 
description), I was judging them based on their example output for each API in 
the ref-guide.  (Example: 
[CreateShard|https://lucene.apache.org/solr/guide/6_6/collections-api.html#CollectionsAPI-createshard]
 has no "success" tag).  So I guess maybe some of these doc snippets are just 
outdated?  I should have double checked, sorry for the confusion. I'll check 
the APIs and correct the list tomorrow.

So to summarize some of the outstanding questions/concerns mentioned so far:
1. Many but not all error cases set the "status" field with an HTTP status 
code.  It's unclear whether this is intentional.
2. Some but not all collection-APIs include a "success" field flag.  It's 
unclear whether all of them should, or there's some rationale behind having 
some APIs use the flag but not others.
3. The implementation of {{CollectionAdminResponse.isSuccess()}} currently has 
issues because of (2).
4. Some of the API output examples for the Collections API don't match what 
those APIs currently return.

(Just trying to keep track of things)

Looking forward to seeing if Mark can shed any light on things!

> CollectionAdminResponse.isSuccess() incorrect for most admin collections APIs
> -
>
> Key: SOLR-11526
> URL: https://issues.apache.org/jira/browse/SOLR-11526
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Minor
>
> {{CollectionAdminResponse}} has a boolean {{isSuccess}} method which reports 
> whether the API was called successfully.  It returns true if it finds a 
> non-null NamedList element called "success".  It returns false otherwise.
> Unfortunately, only a handful of the Collection-Admin APIs have this element. 
>  APIs that don't contain this element in their response will always appear to 
> have failed (according to {{isSuccess()}}).
> The current implementation is correct for:
> - CREATECOLLECTION
> - RELOAD
> - SPLITSHARD
> - DELETESHARD
> - DELETECOLLECTION
> - ADDREPLICA
> - MIGRATE
> The current implementation is incorrect for:
> - CREATESHARD
> - CREATEALIAS
> - DELETEALIAS
> - LISTALIASES
> - CLUSTERPROP
> - ADDROLE
> - REMOVEROLE
> - OVERSEERSTATUS
> - CLUSTERSTATUS
> - REQUESTSTATUS
> - DELETESTATUS
> - LIST
> - ADDREPLICAPROP
> - DELETEREPLICAPROP
> - BALANCESHARDUNIQUE
> - REBALANCELEADERS
> (these lists are incomplete)
> A trivial fix for this would be to change the implementation to check the 
> "status" NamedList element (which is present in all Collection-Admin APIs).  
> My understanding is that the "status' field is set to 0 always on success.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-MAVEN] Lucene-Solr-Maven-7.x #67: POMs out of sync

Build: https://builds.apache.org/job/Lucene-Solr-Maven-7.x/67/

No tests ran.

Build Log:
[...truncated 20136 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:851: The 
following error occurred while executing this line:
: Java returned: 1

Total time: 29 minutes 19 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Resolved] (LUCENE-7997) More sanity testing of similarities

2017-10-24 Thread ASF subversion and git services (JIRA)


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

Robert Muir resolved LUCENE-7997.
-
   Resolution: Fixed
Fix Version/s: master (8.0)

I beasted the new tests 200 times (found/fixed a small hazard in DFR 
normalization 1), also did relevance smoke test to ensure i didn't mess 
something up.

Lets see how it does in jenkins...

> More sanity testing of similarities
> ---
>
> Key: LUCENE-7997
> URL: https://issues.apache.org/jira/browse/LUCENE-7997
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: LUCENE-7997.patch, LUCENE-7997_wip.patch, 
> LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, 
> LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, 
> LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, 
> LUCENE-7997_wip.patch, LUCENE-7997_wip.patch
>
>
> LUCENE-7993 is a potential optimization that we could only apply if the 
> similarity is an increasing functions of {{freq}} (all other things like DF 
> and length being equal). This sounds like a very reasonable requirement for a 
> similarity, so we should test it in the base similarity test case and maybe 
> move broken similarities to sandbox?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7997) More sanity testing of similarities


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

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

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

LUCENE-7997: More sanity testing of similarities


> More sanity testing of similarities
> ---
>
> Key: LUCENE-7997
> URL: https://issues.apache.org/jira/browse/LUCENE-7997
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7997.patch, LUCENE-7997_wip.patch, 
> LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, 
> LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, 
> LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, 
> LUCENE-7997_wip.patch, LUCENE-7997_wip.patch
>
>
> LUCENE-7993 is a potential optimization that we could only apply if the 
> similarity is an increasing functions of {{freq}} (all other things like DF 
> and length being equal). This sounds like a very reasonable requirement for a 
> similarity, so we should test it in the base similarity test case and maybe 
> move broken similarities to sandbox?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11511) Use existing private field in DistributedUpdateProcessor


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

David Smiley commented on SOLR-11511:
-

+1 thanks Gus; I'll merge

> Use existing private field in DistributedUpdateProcessor
> 
>
> Key: SOLR-11511
> URL: https://issues.apache.org/jira/browse/SOLR-11511
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (8.0)
>Reporter: Gus Heck
> Attachments: SOLR-11511.patch
>
>
> The DistributedUpdateProcessor has a private instance field called cloudDesc. 
> It is used in a few places, but most code navigates to CloudDescriptor from 
> the request object instead. 
> The fundamental question of this ticket, is this: is there any reason to 
> distrust this field and do the navigation directly (in which case maybe we 
> get rid of the field instead?) or can we trust it and thus should use it 
> where we can. Since it is a private field only ever updated in the 
> constructor, it's not likely to be changing out from under us. The request 
> from which it is derived is also held in a private final field, so it very 
> much looks to me like this field should have been final and should be used.
> This might or might not be a performance gain (depending on whether or not 
> the compiler can optimize away something like this already), but it will be a 
> readability and consistency gain for sure.
> Attaching patch to tidy this up shortly...
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9) - Build # 20728 - Still Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20728/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

4 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testGammaDistribution

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([C9297CF0C9D9EE16:F453575EEAA14401]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testGammaDistribution(StreamExpressionTest.java:6883)
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:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.cloud.ForceLeaderTest.testLastPublishedStateIsActive

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:41975

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured

Re: [jira] [Commented] (SOLR-11528) ltr unit tests failed

2017-10-24 Thread 380382...@qq.com

Hello Christine Poerschke
My steps are as follows：
1.ant eclipse
2.import the project
3.clean and build project
4.run the test method as junit under solr\contrib\ltr\src\test-files
It will have the following error {... unknown field 'description' ...}.  I 
think the reason is that the scheam wich the test method load does not have the 
'description' field. the reason is solr/core/src/test-files was also compile to 
the same floader. so the scheam was not true yet.
i think we should rename the solr.collection1.conf under 
solr/contrib/ltr/src/test-files .beacuse other solr/contrib also Named with 
their module name infort of solr.collection1.conf sunch as 
langid.solr.collection1.conf  and  extraction.solr.collection1.conf





380382...@qq.com
 
From: Christine Poerschke (JIRA)
Date: 2017-10-25 04:02
To: dev
Subject: [jira] [Commented] (SOLR-11528) ltr unit tests failed
 
[ 
https://issues.apache.org/jira/browse/SOLR-11528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217578#comment-16217578
 ] 
 
Christine Poerschke commented on SOLR-11528:

 
Hello [~jj380382856] - thanks for opening this ticket and attaching a patch!
 
bq. If we build the lucene project first and then run the ltr unit test, it 
will have the following error: ...
 
Could you share more details on how you build and run the tests, possibly with 
seeds that reproduce the issue, e.g. in the output you might see something like
{code}
NOTE: reproduce with: ant test  -Dtestcase=... -Dtests.seed=... ...
{code}
 
Personally I haven't come across the {{... unknown field 'description' ...}} 
error locally and it would be great to reproduce the exact issue before making 
changes.
 
> ltr  unit tests failed
> --
>
> Key: SOLR-11528
> URL: https://issues.apache.org/jira/browse/SOLR-11528
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Affects Versions: master (8.0)
> Environment: eclipse oxygen
>Reporter: jin jing
> Fix For: master (8.0)
>
> Attachments: SOLR-11528.patch
>
>
> If we build the lucene project first and then run the ltr unit test, it will 
> have the following error:
> ERROR: [doc=1] unknown field 'description'
> i found this is beacuse of the under the floader  
> solr\contrib\ltr\src\test-files  we shoud modify solr\collection1\conf  to  
> ltr\solr\collection1\conf. and we shoud Specify solrhome in TestRerankBase.
> If you do not modify the path schema may be overwritten
 
 
 
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
 
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-8012) Improve Explanation class

Robert Muir created LUCENE-8012:
---

 Summary: Improve Explanation class
 Key: LUCENE-8012
 URL: https://issues.apache.org/jira/browse/LUCENE-8012
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir


Explanation class is currently nice and simple, and float matches the scoring 
api, but this does not work well for debugging numerical errors of internal 
calculations (it usually makes practical sense to use 64-bit double to avoid 
issues).

Also it makes for nasty formatting of integral values such as number of tokens 
in the collection or even document's length, its just noise to see {{10.0}} 
there instead of {{10}}, and scientific notation for e.g. number of documents 
is just annoying. 

One idea is to take Number instead of float? Then you could pass in the correct 
numeric type (int,long,double,float) for internal calculations, parameters, 
statistics, etc, and output would look nice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

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

5 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at 
https://127.0.0.1:56728/solr/awhollynewcollection_0_shard3_replica_n4: 
ClusterState says we are the leader 
(https://127.0.0.1:56728/solr/awhollynewcollection_0_shard3_replica_n4), but 
locally we don't think so. Request came from null

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at 
https://127.0.0.1:56728/solr/awhollynewcollection_0_shard3_replica_n4: 
ClusterState says we are the leader 
(https://127.0.0.1:56728/solr/awhollynewcollection_0_shard3_replica_n4), but 
locally we don't think so. Request came from null
at 
__randomizedtesting.SeedInfo.seed([E67CF81157131F4A:AE098CA5512030DF]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:541)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:867)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:459)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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

[jira] [Resolved] (SOLR-11469) LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the wrong shard's elections

2017-10-24 Thread ASF subversion and git services (JIRA)


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

Cao Manh Dat resolved SOLR-11469.
-
Resolution: Fixed

> LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the 
> wrong shard's elections
> 
>
> Key: SOLR-11469
> URL: https://issues.apache.org/jira/browse/SOLR-11469
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11469.patch, SOLR-11469.patch, 
> SOLR-11469_incomplete_and_broken.patch
>
>
> LeaderElectionContextKeyTest is very flaky -- and on millers beastit reports 
> it shows a suspiciously close to "50%" failure rate.
> Digging into the test i realized that it creates a 2 shard index, then picks 
> "a leader" to kill (arbitrarily) and then asserts that the leader election 
> nodes for *shard1* are affected ... so ~50% of the time it kills the shard2 
> leader and then fails because it doesn't see an election in shard1.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11469) LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the wrong shard's elections


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

ASF subversion and git services commented on SOLR-11469:


Commit 0994d3d31081edab4a7db9f20dfcd0315d4aa299 in lucene-solr's branch 
refs/heads/branch_7x from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0994d3d ]

SOLR-11469: Sanity check assertions about coreNodeNames are identical in 2 
collections


> LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the 
> wrong shard's elections
> 
>
> Key: SOLR-11469
> URL: https://issues.apache.org/jira/browse/SOLR-11469
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11469.patch, SOLR-11469.patch, 
> SOLR-11469_incomplete_and_broken.patch
>
>
> LeaderElectionContextKeyTest is very flaky -- and on millers beastit reports 
> it shows a suspiciously close to "50%" failure rate.
> Digging into the test i realized that it creates a 2 shard index, then picks 
> "a leader" to kill (arbitrarily) and then asserts that the leader election 
> nodes for *shard1* are affected ... so ~50% of the time it kills the shard2 
> leader and then fails because it doesn't see an election in shard1.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11469) LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the wrong shard's elections

2017-10-24 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-11469:


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

SOLR-11469: Sanity check assertions about coreNodeNames are identical in 2 
collections


> LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the 
> wrong shard's elections
> 
>
> Key: SOLR-11469
> URL: https://issues.apache.org/jira/browse/SOLR-11469
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11469.patch, SOLR-11469.patch, 
> SOLR-11469_incomplete_and_broken.patch
>
>
> LeaderElectionContextKeyTest is very flaky -- and on millers beastit reports 
> it shows a suspiciously close to "50%" failure rate.
> Digging into the test i realized that it creates a 2 shard index, then picks 
> "a leader" to kill (arbitrarily) and then asserts that the leader election 
> nodes for *shard1* are affected ... so ~50% of the time it kills the shard2 
> leader and then fails because it doesn't see an election in shard1.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11469) LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the wrong shard's elections


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

Cao Manh Dat commented on SOLR-11469:
-

[~hossman] Yeah, It seems a good idea. If someone changes low-level 
implementation that causes test's assumption invalid, the test must be failed 
100%

> LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the 
> wrong shard's elections
> 
>
> Key: SOLR-11469
> URL: https://issues.apache.org/jira/browse/SOLR-11469
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11469.patch, SOLR-11469.patch, 
> SOLR-11469_incomplete_and_broken.patch
>
>
> LeaderElectionContextKeyTest is very flaky -- and on millers beastit reports 
> it shows a suspiciously close to "50%" failure rate.
> Digging into the test i realized that it creates a 2 shard index, then picks 
> "a leader" to kill (arbitrarily) and then asserts that the leader election 
> nodes for *shard1* are affected ... so ~50% of the time it kills the shard2 
> leader and then fails because it doesn't see an election in shard1.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (LUCENE-8011) Improve similarity explanations

Robert Muir created LUCENE-8011:
---

 Summary: Improve similarity explanations
 Key: LUCENE-8011
 URL: https://issues.apache.org/jira/browse/LUCENE-8011
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir


LUCENE-7997 improves BM25 and Classic explains to better explain:

{noformat}
product of:
  2.2 = scaling factor, k1 + 1
  9.388654 = idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:
1.0 = n, number of documents containing term
17927.0 = N, total number of documents with field
  0.9987758 = tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) 
from:
979.0 = freq, occurrences of term within document
1.2 = k1, term saturation parameter
0.75 = b, length normalization parameter
1.0 = dl, length of field
1.0 = avgdl, average length of field
{noformat}

Previously it was pretty cryptic and used confusing terminology like 
docCount/docFreq without explanation: 
{noformat}
product of:
  0.016547536 = idf, computed as log(1 + (docCount - docFreq + 0.5) / (docFreq 
+ 0.5)) from:
449.0 = docFreq
456.0 = docCount
  2.1920826 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * 
fieldLength / avgFieldLength)) from:
113659.0 = freq=113658
1.2 = parameter k1
0.75 = parameter b
2300.5593 = avgFieldLength
1048600.0 = fieldLength
{noformat}

We should fix other similarities too in the same way, they should be more 
practical.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_144) - Build # 662 - Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/662/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.response.transform.TestSubQueryTransformerDistrib

Error Message:
Error from server at https://127.0.0.1:46357/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:46357/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([D7CA8611EAB239F5]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:867)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.response.transform.TestSubQueryTransformerDistrib.setupCluster(TestSubQueryTransformerDistrib.java:74)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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:748)


FAILED:  org.apache.solr.cloud.ShardSplitTest.test

Error Message:
SPLITSHARD was not successful even after three tries

Stack Trace:
java.lang.AssertionError: SPLITSHARD was not successful even after three tries
at 
__randomizedtesting.SeedInfo.seed([D7CA8611EAB239F5:5F9EB9CB444E540D]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.ShardSplitTest.splitByRouteFieldTest(ShardSplitTest.java:731)
at org.apache.solr.cloud.ShardSplitTest.test(ShardSplitTest.java:101)
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)

[jira] [Updated] (LUCENE-7997) More sanity testing of similarities


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

Robert Muir updated LUCENE-7997:

Attachment: LUCENE-7997.patch

Updated patch. I hooked in CheckHits for more explains testing, and test nearby 
norm and nearby slightly rarer term to ensure relevance doesn't go backwards in 
those cases too.

I updated the AwaitsFix url to a separate issue to fix sims with bugs / move to 
sandbox: LUCENE-8010

Finally i optimized the tests to have more reasonable runtime. I think its 
ready for now.


> More sanity testing of similarities
> ---
>
> Key: LUCENE-7997
> URL: https://issues.apache.org/jira/browse/LUCENE-7997
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7997.patch, LUCENE-7997_wip.patch, 
> LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, 
> LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, 
> LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, LUCENE-7997_wip.patch, 
> LUCENE-7997_wip.patch, LUCENE-7997_wip.patch
>
>
> LUCENE-7993 is a potential optimization that we could only apply if the 
> similarity is an increasing functions of {{freq}} (all other things like DF 
> and length being equal). This sounds like a very reasonable requirement for a 
> similarity, so we should test it in the base similarity test case and maybe 
> move broken similarities to sandbox?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11546) Improve error response from collection api calls

2017-10-24 Thread Varun Thacker (JIRA)

Varun Thacker created SOLR-11546:


 Summary: Improve error response from collection api calls
 Key: SOLR-11546
 URL: https://issues.apache.org/jira/browse/SOLR-11546
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker


I ran this API call : 
{{http://localhost:8983/solr/admin/collections?action=CREATE=test_tlog=2=2}}
 and forgot to add maxShardsPerNode . The response looks overly verbose and 
repetitive 


{code}
{
  "responseHeader":{
"status":400,
"QTime":242},
  "Operation create caused 
exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
 Cannot create collection test_tlog. Value of maxShardsPerNode is 1, and the 
number of nodes currently live or live and part of your createNodeSet is 2. 
This allows a maximum of 2 to be created. Value of numShards is 2, value of 
nrtReplicas is 0, value of tlogReplicas is 2 and value of pullReplicas is 0. 
This requires 4 shards to be created (higher than the allowed number)",
  "exception":{
"msg":"Cannot create collection test_tlog. Value of maxShardsPerNode is 1, 
and the number of nodes currently live or live and part of your createNodeSet 
is 2. This allows a maximum of 2 to be created. Value of numShards is 2, value 
of nrtReplicas is 0, value of tlogReplicas is 2 and value of pullReplicas is 0. 
This requires 4 shards to be created (higher than the allowed number)",
"rspCode":400},
  "error":{
"metadata":[
  "error-class","org.apache.solr.common.SolrException",
  "root-error-class","org.apache.solr.common.SolrException"],
"msg":"Cannot create collection test_tlog. Value of maxShardsPerNode is 1, 
and the number of nodes currently live or live and part of your createNodeSet 
is 2. This allows a maximum of 2 to be created. Value of numShards is 2, value 
of nrtReplicas is 0, value of tlogReplicas is 2 and value of pullReplicas is 0. 
This requires 4 shards to be created (higher than the allowed number)",
"code":400}}
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11545) Core name suffixes can be the same number as core node name suffixes

2017-10-24 Thread Varun Thacker (JIRA)

Varun Thacker created SOLR-11545:


 Summary: Core name suffixes can be the same number as core node 
name suffixes
 Key: SOLR-11545
 URL: https://issues.apache.org/jira/browse/SOLR-11545
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker
Priority: Trivial


{code}
{"gettingstarted":{
"pullReplicas":"0",
"replicationFactor":"2",
"router":{"name":"compositeId"},
"maxShardsPerNode":"-1",
"autoAddReplicas":"false",
"nrtReplicas":"1",
"tlogReplicas":"0",
"shards":{
  "shard1":{
"range":"8000-",
"state":"active",
"replicas":{
  "core_node3":{
"core":"gettingstarted_shard1_replica_n1",
"base_url":"http://172.16.0.83:8983/solr;,
"node_name":"172.16.0.83:8983_solr",
"state":"active",
"type":"NRT",
"leader":"true"},
  "core_node6":{
"core":"gettingstarted_shard1_replica_n2",
"base_url":"http://172.16.0.83:7574/solr;,
"node_name":"172.16.0.83:7574_solr",
"state":"active",
"type":"NRT"}}},
  "shard2":{
"range":"0-7fff",
"state":"active",
"replicas":{
  "core_node7":{
"core":"gettingstarted_shard2_replica_n4",
"base_url":"http://172.16.0.83:8983/solr;,
"node_name":"172.16.0.83:8983_solr",
"state":"active",
"type":"NRT",
"leader":"true"},
  "core_node8":{
"core":"gettingstarted_shard2_replica_n5",
"base_url":"http://172.16.0.83:7574/solr;,
"node_name":"172.16.0.83:7574_solr",
"state":"active",
"type":"NRT"}}
{code}

Here if the X integer was same in both `core_nodeX` and 
`gettingstarted_shard1_replica_nX` it would make it easier to read I guess. 
Also the solr admin ui has the core name displayed . Now that i now the value 
of X I know the replica name as well . 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (LUCENE-8010) fix or sandbox similarities in core with problems

Robert Muir created LUCENE-8010:
---

 Summary: fix or sandbox similarities in core with problems
 Key: LUCENE-8010
 URL: https://issues.apache.org/jira/browse/LUCENE-8010
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


We want to support scoring optimizations such as LUCENE-4100 and LUCENE-7993, 
which put very minimal requirements on the similarity impl. Today similarities 
of various quality are in core and tests. 

The ones with problems currently have warnings in the javadocs about their 
bugs, and if the problems are severe enough, then they are also disabled in 
randomized testing too.

IMO lucene core should only have practical functions that won't return {{NaN}} 
scores at times or cause relevance to go backwards if the user's stopfilter 
isn't configured perfectly. Also it is important for unit tests to not deal 
with broken or semi-broken sims, and the ones in core should pass all unit 
tests.

I propose we move the buggy ones to sandbox and deprecate them. If they can be 
fixed we can put them back in core, otherwise bye-bye.

FWIW tests developed in LUCENE-7997 document the following requirements:
   * scores are non-negative and finite.
   * score matches the explanation exactly.
   * internal explanations calculations are sane (e.g. sum of: and so on 
actually compute sums)
   * scores don't decrease as term frequencies increase: e.g. score(freq=N + 1) 
>= score(freq=N)
   * scores don't decrease as documents get shorter, e.g. score(len=M) >= 
score(len=M+1)
   * scores don't decrease as terms get rarer, e.g. score(term=N) >= 
score(term=N+1)
   * scoring works for floating point frequencies (e.g. sloppy phrase and span 
queries will work)
   * scoring works for reasonably large 64-bit statistic values (e.g. 
distributed search will work)
   * scoring works for reasonably large boost values (0 .. Integer.MAX_VALUE, 
e.g. query boosts will work)
   * scoring works for parameters randomized within valid ranges




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_144) - Build # 20727 - Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20727/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseG1GC

4 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=23458, name=jetty-launcher-3622-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:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)   
 2) Thread[id=23448, name=jetty-launcher-3622-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:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=23458, name=jetty-launcher-3622-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

[JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_144) - Build # 265 - Still Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/265/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseParallelGC

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

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.ZkCLITest_1A69291321C57291-001\tempDir-020\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.ZkCLITest_1A69291321C57291-001\tempDir-020\collection1

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.ZkCLITest_1A69291321C57291-001\tempDir-020:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.ZkCLITest_1A69291321C57291-001\tempDir-020
 

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

at __randomizedtesting.SeedInfo.seed([1A69291321C57291]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
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:748)


FAILED:  org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue

Error Message:
action wasn't interrupted

Stack Trace:
java.lang.AssertionError: action wasn't interrupted
at 
__randomizedtesting.SeedInfo.seed([1A69291321C57291:D3DC6BBD28A2B464]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue(TriggerIntegrationTest.java:684)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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)

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 66 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/66/

No tests ran.

Build Log:
[...truncated 28018 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.05 sec (4.6 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.2.0-src.tgz...
   [smoker] 31.1 MB in 0.05 sec (582.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.2.0.tgz...
   [smoker] 69.6 MB in 0.20 sec (349.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.2.0.zip...
   [smoker] 80.0 MB in 0.10 sec (776.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.2.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6221 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.2.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6221 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.2.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   6.6.2
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/dev-tools/scripts/smokeTestRelease.py",
 line 1484, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/dev-tools/scripts/smokeTestRelease.py",
 line 1428, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/dev-tools/scripts/smokeTestRelease.py",
 line 1466, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, gitRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/dev-tools/scripts/smokeTestRelease.py",
 line 622, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
gitRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/dev-tools/scripts/smokeTestRelease.py",
 line 774, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/dev-tools/scripts/smokeTestRelease.py",
 line 1404, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/build.xml:622: 
exec returned: 1

Total time: 192 minutes 27 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
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 # 2131 - Still unstable

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

5 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test

Error Message:
Could not load collection from ZK: collection1

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
collection1
at 
__randomizedtesting.SeedInfo.seed([9853E72070FAFBBA:1007D8FADE069642]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1172)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:692)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:130)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.getTotalReplicas(AbstractFullDistribZkTestBase.java:488)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:441)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:334)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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:748)
Caused by: org.apache.zookeeper.KeeperException$SessionExpiredException: 
KeeperErrorCode = Session expired for /collections/collection1/state.json
at org.apache.zookeeper.KeeperException.create(KeeperException.java:127)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)

[jira] [Commented] (SOLR-11526) CollectionAdminResponse.isSuccess() incorrect for most admin collections APIs

2017-10-24 Thread Varun Thacker (JIRA)


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

Varun Thacker commented on SOLR-11526:
--

This is bad. Thanks Jason for brining it up. 

I think as a first step if someone could shed some light as to whether we 
should look at the status code or the "success" key. I always used to believe 
that status!=0 is how users determined if an API call failed but you've shown 
an example where a failure still returns status=0 . 

[~markrmil...@gmail.com] You have worked on two related Jiras : SOLR-5392 and 
SOLR-4576 .  Do you have some thoughts on this?

If I was to propose a change I would change the {{isSuccess}} method to check 
the status code and return true / false accordingly. And make sure 
TestCollectionAdminRequest / TestCollectionAPI actually test it 

This might require a lot of changes though. For example DeleteShardCmd does 
this check today and now we should look at status code and not the "success" 
key we should first assert that the status code is 0

{code}
NamedList deleteResult = new NamedList();
try {
  
((DeleteReplicaCmd)ocmh.commandMap.get(DELETEREPLICA)).deleteReplica(clusterState,
 replica, deleteResult, () -> {
cleanupLatch.countDown();
if (deleteResult.get("failure") != null) {
  synchronized (results) {
results.add("failure", String.format(Locale.ROOT, "Failed to 
delete replica for collection=%s shard=%s" +
" on node=%s", replica.getStr(COLLECTION_PROP), 
replica.getStr(SHARD_ID_PROP), replica.getStr(NODE_NAME_PROP)));
  }
}
SimpleOrderedMap success = (SimpleOrderedMap) 
deleteResult.get("success");
if (success != null) {
  synchronized (results)  {
results.add("success", success);
  }
}
  });
{code}

You mentioned in the description of the jira that createshard does not set a 
"success" key but I see this is CreateShardCmd.java. I don't think most of the 
others are still buggy like you mentioned.

{code}
  } else {
SimpleOrderedMap success = (SimpleOrderedMap) 
results.get("success");
if (success == null) {
  success = new SimpleOrderedMap();
  results.add("success", success);
}
success.addAll((NamedList) addResult.get("success"));
  }
});
{code}

A SolrJ user is calling {{CollectionAdminRequest#listCollections}} . This 
throws an exception so that's how today users are building success/failure 
logic ?  Users using the HTTP API directly would run into all of the issues you 
are mentioning though

> CollectionAdminResponse.isSuccess() incorrect for most admin collections APIs
> -
>
> Key: SOLR-11526
> URL: https://issues.apache.org/jira/browse/SOLR-11526
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Minor
>
> {{CollectionAdminResponse}} has a boolean {{isSuccess}} method which reports 
> whether the API was called successfully.  It returns true if it finds a 
> non-null NamedList element called "success".  It returns false otherwise.
> Unfortunately, only a handful of the Collection-Admin APIs have this element. 
>  APIs that don't contain this element in their response will always appear to 
> have failed (according to {{isSuccess()}}).
> The current implementation is correct for:
> - CREATECOLLECTION
> - RELOAD
> - SPLITSHARD
> - DELETESHARD
> - DELETECOLLECTION
> - ADDREPLICA
> - MIGRATE
> The current implementation is incorrect for:
> - CREATESHARD
> - CREATEALIAS
> - DELETEALIAS
> - LISTALIASES
> - CLUSTERPROP
> - ADDROLE
> - REMOVEROLE
> - OVERSEERSTATUS
> - CLUSTERSTATUS
> - REQUESTSTATUS
> - DELETESTATUS
> - LIST
> - ADDREPLICAPROP
> - DELETEREPLICAPROP
> - BALANCESHARDUNIQUE
> - REBALANCELEADERS
> (these lists are incomplete)
> A trivial fix for this would be to change the implementation to check the 
> "status" NamedList element (which is present in all Collection-Admin APIs).  
> My understanding is that the "status' field is set to 0 always on success.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11544) spell-check does not return collations when using search query with filter

2017-10-24 Thread jIraiya (JIRA)

jIraiya created SOLR-11544:
--

 Summary: spell-check does not return collations when using search 
query with filter
 Key: SOLR-11544
 URL: https://issues.apache.org/jira/browse/SOLR-11544
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.3
Reporter: jIraiya
Priority: Trivial


Please refer to this thread for more information:

http://lucene.472066.n3.nabble.com/spell-check-does-not-return-collations-when-using-search-query-with-filter-td4357739.html




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: 7.1 Ref Guide plans

2017-10-24 Thread Jason Gerlowski

Hi Cassandra,

I'd like to put in a tentative vote for getting SOLR-11032 in for the
next ref-guide release.  It has a much-needed refresh of the "Using
SolrJ" page, which has fallen a few releases behind.

I say "tentative" above because I don't think anyone has taken a look
at reviewing the patch there yet.  It might be far from where it needs
to be.  If so, I don't want it to hold up the release.  But if it's
reasonably close, it'd be nice to get in IMO.

Best,

Jason

On Tue, Oct 24, 2017 at 11:23 AM, Cassandra Targett
 wrote:
> Hi -
>
> 7.1 happened so fast we're a little late getting out the Ref Guide for
> it, but I think it's close to ready to go. There are a couple things
> I'm waiting on:
>
> - Autoscaling docs - Shalin is working on a substantial set of edits
> here and promised these in the next couple of days.
> - Analytics Component - it needs a bit more review, but it's getting
> close. If it's not ready by the time the Autoscaling docs are ready,
> I'll push this into 7.2.
>
> I did a review of CHANGES.txt at the end of last week to see what doc
> updates still needed to be done, and was incredibly heartened and glad
> to see that besides the things I already knew about nearly all of the
> other changes that needed doc updates were done at the time of the
> commits. This is fantastic progress, and I'm personally thankful to
> everyone for making the effort.
>
> My current plan is to get an RC of the Ref Guide out by Friday this
> week, hopefully by Thursday if things are ready. If anyone has
> anything they wanted to get in that's not on the above list, please
> let me know.
>
> Cassandra
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Updated] (SOLR-11486) CVE-2016-6809: Upgrade TIKA

2017-10-24 Thread Uwe Schindler (JIRA)


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

Uwe Schindler updated SOLR-11486:
-
Security: Public  (was: Private (Security Issue))

> CVE-2016-6809: Upgrade TIKA
> ---
>
> Key: SOLR-11486
> URL: https://issues.apache.org/jira/browse/SOLR-11486
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: Uwe Schindler
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: 5.5.5, 7.1, master (8.0), 6.6.2
>
> Attachments: SOLR-11486-5.5securityfix.patch
>
>
> See SOLR-10335.
> We should upgrade ASAP because of CVE-2016-6809



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11238) Solr authorization plugin is not able to pass additional params downstream


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

Hrishikesh Gadre resolved SOLR-11238.
-
Resolution: Won't Fix

> Solr authorization plugin is not able to pass additional params downstream
> --
>
> Key: SOLR-11238
> URL: https://issues.apache.org/jira/browse/SOLR-11238
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Hrishikesh Gadre
> Attachments: SOLR-11238.patch
>
>
> Authorization checks in Solr are implemented by invoking configured 
> authorization plugin with AuthorizationContext object. The plugin is expected 
> to return an AuthorizationResponse object which provides the result (which 
> can be OK/FORBIDDEN/PROMPT).
> In some cases (e.g. document level security implemented in Apache Sentry), it 
> is useful for the authorization plugin to add (or override) the request 
> parameters sent by the user (which are represented as SolrParams in 
> [AuthorizationContext| 
> https://github.com/apache/lucene-solr/blob/3cbbecca026eb2a9491fa4a24ecc2c43c26e58bd/solr/core/src/java/org/apache/solr/security/AuthorizationContext.java#L38]).
>  This jira is to introduce an ability to customize the parameters by the 
> authorization plugin.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11238) Solr authorization plugin is not able to pass additional params downstream


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

Hrishikesh Gadre commented on SOLR-11238:
-

Update - 2 months after posting this patch, I found an alternative to extract 
username and associated roles in the search component without requiring this 
fix.

https://github.com/hgadre/sentry/blob/a4ecc83d3e92c81e61aa5441102a9bcd6e90d421/sentry-solr/solr-sentry-handlers/src/main/java/org/apache/solr/handler/component/QueryDocAuthorizationComponent.java

I think we should close this jira as "Won't fix" since currently there is no 
use-case which requires this functionality. 

> Solr authorization plugin is not able to pass additional params downstream
> --
>
> Key: SOLR-11238
> URL: https://issues.apache.org/jira/browse/SOLR-11238
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Hrishikesh Gadre
> Attachments: SOLR-11238.patch
>
>
> Authorization checks in Solr are implemented by invoking configured 
> authorization plugin with AuthorizationContext object. The plugin is expected 
> to return an AuthorizationResponse object which provides the result (which 
> can be OK/FORBIDDEN/PROMPT).
> In some cases (e.g. document level security implemented in Apache Sentry), it 
> is useful for the authorization plugin to add (or override) the request 
> parameters sent by the user (which are represented as SolrParams in 
> [AuthorizationContext| 
> https://github.com/apache/lucene-solr/blob/3cbbecca026eb2a9491fa4a24ecc2c43c26e58bd/solr/core/src/java/org/apache/solr/security/AuthorizationContext.java#L38]).
>  This jira is to introduce an ability to customize the parameters by the 
> authorization plugin.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Solr test framework - Locale randomization

2017-10-24 Thread Hrishikesh Gadre

I filed LUCENE-8009  to
track this work. I will submit a patch soon.

Thanks
Hrishikesh


On Mon, Oct 23, 2017 at 9:46 AM, Chris Hostetter 
wrote:

>
> : SuppressLocaleRandomization(locale="en-US", reason="Derby doesn't work
> : with complex locales, see issue ...")?
>
> that would be cool ... with 'reason' & 'locale' as optional, both
> defaulting to "" (whch for Locale should result in Locale.ROOT IIUC?)
>
> For consistency with existing annotations a non-optional bugUrl would be
> good.
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Created] (LUCENE-8009) Support disabling Locale randomization as part of Lucene test framework

Hrishikesh Gadre created LUCENE-8009:


 Summary: Support disabling Locale randomization as part of Lucene 
test framework
 Key: LUCENE-8009
 URL: https://issues.apache.org/jira/browse/LUCENE-8009
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/test-framework
Affects Versions: 7.1
Reporter: Hrishikesh Gadre
Priority: Minor


The Lucene test framework randomizes the Locale configuration to test the 
software in different locale settings.
https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/lucene/test-framework/src/java/org/apache/lucene/util/TestRuleSetupAndRestoreClassEnv.java#L206-L209

While this is a very good practice from engineering perspective, it causes 
issues when the Lucene/Solr test framework is used with third-party components 
which may have issues working with a subset of locale settings. e.g. for 
Solr/Sentry integration (SENTRY-1475), we are using Solr test framework to test 
the sentry authorization plugin for Solr. For unit-testing, it uses Apache 
Derby. We have found multiple cases when derby fail to initialize for a locale 
configured by Solr test framework. This causes tests to fail and create a 
confusion with respect to the quality of the integration source-code. Since the 
Derby failures are not related to Solr/Sentry integration, we would like to 
avoid such nasty surprises by suppressing the locale randomization. This is 
similar to the way we suppress Solr SSL configuration 
(@SolrTestCaseJ4.SuppressSSL).

Please refer to discussion on dev mailing list for more context,
http://lucene.472066.n3.nabble.com/Solr-test-framework-Locale-randomization-td4359671.html




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11543) Support fine grained authorization for multi-tenancy usecases


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

Hrishikesh Gadre commented on SOLR-11543:
-

[~ichattopadhyaya] [~noble.paul] let me know your thoughts on this. As part of 
Sentry integration, I have added logic to parse the parameters passed as part 
of the admin operation and implement necessary permissions check. But this is 
brittle to maintain as we upgrade solr versions. Also other authorization 
plugins may have similar requirements. So it would be better to implement this 
logic cleanly as part of solr authorization framework.

https://github.com/hgadre/sentry/blob/a4ecc83d3e92c81e61aa5441102a9bcd6e90d421/sentry-binding/sentry-binding-solr/src/main/java/org/apache/sentry/binding/solr/authz/SolrAuthzUtil.java#L101
https://github.com/hgadre/sentry/blob/a4ecc83d3e92c81e61aa5441102a9bcd6e90d421/sentry-binding/sentry-binding-solr/src/main/java/org/apache/sentry/binding/solr/authz/SentrySolrPluginImpl.java#L188

> Support fine grained authorization for multi-tenancy usecases
> -
>
> Key: SOLR-11543
> URL: https://issues.apache.org/jira/browse/SOLR-11543
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.2
>Reporter: Hrishikesh Gadre
>
> As part of SOLR-7275, we implemented a pluggable authorization framework for 
> Solr. But the current design (specifically wrt to admin apis) is not quite 
> suitable to support multi-tenant Solr cloud  in a secure environment. In such 
> environment, there are two types of system admins (a) admins belonging to the 
> service provider and (b) admins belonging to an individual tenant. 
> Type (a) admins are responsible to setup solr cluster e.g. setting up solr 
> servers, managing security etc.
> Type (b) admins on the other hand are responsible to perform collection-level 
> admin operations e.g. creating/deleting/configuring/reloading collections 
> belonging to the tenant. From security perspective it is important to ensure 
> that such admin is able to operate only on the collections belonging to the 
> respective tenant. 
> The current design of authorization framework has following limitations
> (a) it does not provide the resource names associated with the operation as 
> part of the authorization context (Ref: 
> https://github.com/apache/lucene-solr/blob/ef7b525123fc32b0703f1579c2422957d1b0a2ab/solr/core/src/java/org/apache/solr/security/PermissionNameProvider.java).
>  Here the collection names are hard-coded to either null or "*" value in the 
> parameter for Name instance. This results in providing global admin 
> privileges to the user. In a multi-tenant environment, this is not acceptable.
> (b) The authorization framework assumes that only a single permission is 
> necessary for any given operation (Ref: 
> https://github.com/apache/lucene-solr/blob/ef7b525123fc32b0703f1579c2422957d1b0a2ab/solr/core/src/java/org/apache/solr/security/PermissionNameProvider.java#L77).
>  For some of the admin operations (e.g. MIGRATE collections admin API) we 
> need to check additional permissions for multi-tenancy. Specifically in case 
> of MIGRATE API we need to check following permissions
>  - collections admin privilege (Update)
>  - collection privilege for the source collection (Read)
>  - collection privilege for the destination collection (Update)
> Hence ideally PermissionNameProvider needs to return a list of permission 
> names instead of a single permission (in most cases the list will contain a 
> single element). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11543) Support fine grained authorization for multi-tenancy usecases

Hrishikesh Gadre created SOLR-11543:
---

Summary: Support fine grained authorization for multi-tenancy
usecases
Key: SOLR-11543
URL: https://issues.apache.org/jira/browse/SOLR-11543
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 5.2
Reporter: Hrishikesh Gadre

As part of SOLR-7275, we implemented a pluggable authorization framework for
Solr. But the current design (specifically wrt to admin apis) is not quite
suitable to support multi-tenant Solr cloud in a secure environment. In such
environment, there are two types of system admins (a) admins belonging to the
service provider and (b) admins belonging to an individual tenant.

Type (a) admins are responsible to setup solr cluster e.g. setting up solr
servers, managing security etc.
Type (b) admins on the other hand are responsible to perform collection-level
admin operations e.g. creating/deleting/configuring/reloading collections
belonging to the tenant. From security perspective it is important to ensure
that such admin is able to operate only on the collections belonging to the
respective tenant.

The current design of authorization framework has following limitations
(a) it does not provide the resource names associated with the operation as
part of the authorization context (Ref:
https://github.com/apache/lucene-solr/blob/ef7b525123fc32b0703f1579c2422957d1b0a2ab/solr/core/src/java/org/apache/solr/security/PermissionNameProvider.java).
Here the collection names are hard-coded to either null or "*" value in the
parameter for Name instance. This results in providing global admin privileges
to the user. In a multi-tenant environment, this is not acceptable.

(b) The authorization framework assumes that only a single permission is
necessary for any given operation (Ref:
https://github.com/apache/lucene-solr/blob/ef7b525123fc32b0703f1579c2422957d1b0a2ab/solr/core/src/java/org/apache/solr/security/PermissionNameProvider.java#L77).
For some of the admin operations (e.g. MIGRATE collections admin API) we need
to check additional permissions for multi-tenancy. Specifically in case of
MIGRATE API we need to check following permissions
- collections admin privilege (Update)
- collection privilege for the source collection (Read)
- collection privilege for the destination collection (Update)

Hence ideally PermissionNameProvider needs to return a list of permission names
instead of a single permission (in most cases the list will contain a single
element).

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11144) Analytics Component Documentation


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

Cassandra Targett commented on SOLR-11144:
--

Sounds good Houston, thanks.

> Analytics Component Documentation
> -
>
> Key: SOLR-11144
> URL: https://issues.apache.org/jira/browse/SOLR-11144
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1
>Reporter: Houston Putman
>Assignee: Cassandra Targett
>Priority: Critical
>
> Adding a Solr Reference Guide page for the Analytics Component.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11540) eliminate the need for page-shortname and/or page-permalink attributes in our asciidoc source files


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

Hoss Man updated SOLR-11540:

Attachment: SOLR-11540.patch

Here's a patch with all the useful jekyll template changes from the older patch 
in the parent issue -- but w/o any of the "make shortname from title" changes 
(leverage the new improvements in SOLR-11540)

comparing the generated {{html-site}} output between the current output and the 
new output with the patch, the only (non-whitespace) changes are to the 
{{html-site/meta-docs}} -- which already have lots of rendering problems 
because the layouts aren't really designed to work with the files in that 
subdirectory, these changes just "fix" some of those problems (because the meta 
docs don't currently have the {{page-shortname}} attributes defined, but with 
the patch they don't need them -- they get implicitly derived from the filename)



I think this is good to go?

> eliminate the need for page-shortname and/or page-permalink attributes in our 
> asciidoc source files
> ---
>
> Key: SOLR-11540
> URL: https://issues.apache.org/jira/browse/SOLR-11540
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-11540.patch
>
>
> From parent issue...
> bq. Furthermore: the entire {{page-shortname}} and {{page-permalink}} 
> variables in all of our {{*.adoc}} files arn't really neccessary – they are a 
> convention I introduced early on in the process of building our the sidebar & 
> next/pre link generation logic, but are error prone if/when people rename 
> files.
> Assuming SOLR-11539 works out, we can implicitly (in BuildNavAndPDFBody and 
> our jekyll templates) use the basename of the {{file.adoc}} as the 
> {{shortname}}, and use {{shortname + ".html"}} as the {{permalink}} and be 
> done with it.
> If SOLR-11539 doesn't work out, we can still generate those variables in the 
> same way -- but we also have to validate that the generated values match the 
> title (see existing patch in parent issue)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11144) Analytics Component Documentation

2017-10-24 Thread Houston Putman (JIRA)


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

Houston Putman commented on SOLR-11144:
---

Hey [~ctargett]. Sorry I'm a bit busy right now, but I should be able to get 
around to this next week. I believe the Analytics bug fix patch is going into 
7.2, so I'm ok with waiting for 7.2 for this.

> Analytics Component Documentation
> -
>
> Key: SOLR-11144
> URL: https://issues.apache.org/jira/browse/SOLR-11144
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1
>Reporter: Houston Putman
>Assignee: Cassandra Targett
>Priority: Critical
>
> Adding a Solr Reference Guide page for the Analytics Component.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11542) Add feature to DistributedURP to route time partitioned collections


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

David Smiley commented on SOLR-11542:
-

*Proposed collection alias metadata:*
* The document field containing the timestamp to route on.  What to call this?  
I'm not sure.  Perhaps it should contain "router.field" as a suffix, which is 
the existing collection parameter for designating the field to route on within 
the collection.  It could be given the same name but maybe that would be 
confusing?  FWIW ElasticSearch has a "Rollover Index" API call with some 
similarities to this feature... so maybe "rollover" might be the prefix?  or 
"partitioned"?  I'm not sure I like these much; perhaps just "router.field" is 
fine as-is.  It's scoped to the alias.

That's it so far.  Perhaps no {{TZ}} param needed at this juncture if the dates 
are UTC... TZ will nonetheless be useful later in interpreting a "gap" to 
create new partitions.  It's also risky to have a TZ param that changes the 
interpretation of the collection names since what if the TZ param is changed.

*Proposed collection naming convention:*
{{aliasname_-MM-dd_HH_mm_ss}}.  Collection names have limitations (no 
colons) so can't just use ISO8601.  Because it's not IS08601, I figure don't 
try to look too close to it -- thus no T separator.  Furthermore it may be 
abbreviated so that it does not have trailing zeros or symbols.  Perhaps it 
should nonetheless always end in a 'Z' so that there is no user 
misunderstanding with the eventual addition of a {{TZ}} alias metadata?

> Add feature to DistributedURP to route time partitioned collections
> ---
>
> Key: SOLR-11542
> URL: https://issues.apache.org/jira/browse/SOLR-11542
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
> Fix For: 7.2
>
>
> Assuming we have some time partitioning metadata on an alias (see SOLR-11487 
> for the metadata facility), we'll then need to route documents to the right 
> collection.  I tentatively propose a helper class to DistributedURP to do 
> this.  Perhaps a separate URP is plausible, though it will take some 
> modifications to DistributedURP.
> The scope of this issue is:
> * decide on some alias metadata names & semantics
> * decide the collection suffix pattern.  Read/write code (needed to route).
> * the routing code
> No new partition creation nor deletion happens is this issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-9690) Date/Time DocRouter


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

David Smiley resolved SOLR-9690.

Resolution: Won't Fix

closing as "Won't Fix" but can be reopened if someone wants to tackle it.  I'm 
going about time partitioning differently in SOLR-11299.

> Date/Time DocRouter
> ---
>
> Key: SOLR-9690
> URL: https://issues.apache.org/jira/browse/SOLR-9690
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
> Attachments: DirectHashRouter.java
>
>
> This issue is for a custom Solr DocRouter that works with dates/times (or 
> perhaps any field providing an int).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11530) Update ref-guide output snippets to match new default wt


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

Cassandra Targett commented on SOLR-11530:
--

I've resolved this even though we didn't update the examples to JSON. We could 
just as easily reopen and leave it open until that's done, but that's up to you 
[~gerlowskija] if you think you will have time to work on it (personally, I'll 
probably only have time on an ad-hoc basis so might mix those into other 
commits).

> Update ref-guide output snippets to match new default wt
> 
>
> Key: SOLR-11530
> URL: https://issues.apache.org/jira/browse/SOLR-11530
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Cassandra Targett
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-11530.patch
>
>
> Solr 7.0 changed the default wt format from XML to JSON.  Many of the 
> API-output snippets from our documentation were never updated to accommodate 
> this change.  So as-is, the output won't match what users following along at 
> home would get from running the commands.  This could throw some newer Solr 
> users.
> This JIRA is created to resolve this inconsistency.  Either by adding the 
> "wt=xml" param to the API command corresponding to any XML snippets, or by 
> switching the snippets over to all use JSON.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11530) Update ref-guide output snippets to match new default wt


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

Cassandra Targett resolved SOLR-11530.
--
   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)

> Update ref-guide output snippets to match new default wt
> 
>
> Key: SOLR-11530
> URL: https://issues.apache.org/jira/browse/SOLR-11530
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Cassandra Targett
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11530.patch
>
>
> Solr 7.0 changed the default wt format from XML to JSON.  Many of the 
> API-output snippets from our documentation were never updated to accommodate 
> this change.  So as-is, the output won't match what users following along at 
> home would get from running the commands.  This could throw some newer Solr 
> users.
> This JIRA is created to resolve this inconsistency.  Either by adding the 
> "wt=xml" param to the API command corresponding to any XML snippets, or by 
> switching the snippets over to all use JSON.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10005) solr/contrib/ltr : add missing class-level javadocs

2017-10-24 Thread ASF subversion and git services (JIRA)


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

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

Attaching patch with missing class level javadocs. SOLR-11534 needs to be 
committed first though or else the javadocs are inaccurate.

> solr/contrib/ltr : add missing class-level javadocs
> ---
>
> Key: SOLR-10005
> URL: https://issues.apache.org/jira/browse/SOLR-10005
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10005.patch
>
>
> extract from extract attached to the parent task:
> {code}
> /tmp/smoke_lucene_6.4.0_bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124_1/unpack/solr-6.4.0/solr/build/docs/solr-ltr/org/apache/solr/ltr/package-summary.html
>   missing: DocInfo
>   missing: SolrQueryRequestContextUtils
>   missing: FeatureLogger.FeatureFormat
> /tmp/smoke_lucene_6.4.0_bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124_1/unpack/solr-6.4.0/solr/build/docs/solr-ltr/org/apache/solr/ltr/norm/package-summary.html
>   missing: NormalizerException
> /tmp/smoke_lucene_6.4.0_bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124_1/unpack/solr-6.4.0/solr/build/docs/solr-ltr/org/apache/solr/ltr/model/package-summary.html
>   missing: ModelException
> /tmp/smoke_lucene_6.4.0_bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124_1/unpack/solr-6.4.0/solr/build/docs/solr-ltr/org/apache/solr/ltr/feature/package-summary.html
>   missing: FeatureException
> /tmp/smoke_lucene_6.4.0_bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124_1/unpack/solr-6.4.0/solr/build/docs/solr-ltr/org/apache/solr/ltr/store/package-summary.html
>   missing: FeatureStore
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11530) Update ref-guide output snippets to match new default wt


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

ASF subversion and git services commented on SOLR-11530:


Commit a1014d68013fb6ee6439962fb01d97030ec342fd in lucene-solr's branch 
refs/heads/branch_7_1 from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a1014d6 ]

SOLR-11530: add wt=xml to XML output examples until they can be changed to JSON


> Update ref-guide output snippets to match new default wt
> 
>
> Key: SOLR-11530
> URL: https://issues.apache.org/jira/browse/SOLR-11530
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Cassandra Targett
> Attachments: SOLR-11530.patch
>
>
> Solr 7.0 changed the default wt format from XML to JSON.  Many of the 
> API-output snippets from our documentation were never updated to accommodate 
> this change.  So as-is, the output won't match what users following along at 
> home would get from running the commands.  This could throw some newer Solr 
> users.
> This JIRA is created to resolve this inconsistency.  Either by adding the 
> "wt=xml" param to the API command corresponding to any XML snippets, or by 
> switching the snippets over to all use JSON.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11530) Update ref-guide output snippets to match new default wt

2017-10-24 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-11530:


Commit 24aa0bf6a9198aac47b200eb12916cbd7ca9507c in lucene-solr's branch 
refs/heads/branch_7x from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=24aa0bf ]

SOLR-11530: add wt=xml to XML output examples until they can be changed to JSON


> Update ref-guide output snippets to match new default wt
> 
>
> Key: SOLR-11530
> URL: https://issues.apache.org/jira/browse/SOLR-11530
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Cassandra Targett
> Attachments: SOLR-11530.patch
>
>
> Solr 7.0 changed the default wt format from XML to JSON.  Many of the 
> API-output snippets from our documentation were never updated to accommodate 
> this change.  So as-is, the output won't match what users following along at 
> home would get from running the commands.  This could throw some newer Solr 
> users.
> This JIRA is created to resolve this inconsistency.  Either by adding the 
> "wt=xml" param to the API command corresponding to any XML snippets, or by 
> switching the snippets over to all use JSON.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11530) Update ref-guide output snippets to match new default wt

2017-10-24 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-11530:


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

SOLR-11530: add wt=xml to XML output examples until they can be changed to JSON


> Update ref-guide output snippets to match new default wt
> 
>
> Key: SOLR-11530
> URL: https://issues.apache.org/jira/browse/SOLR-11530
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Cassandra Targett
> Attachments: SOLR-11530.patch
>
>
> Solr 7.0 changed the default wt format from XML to JSON.  Many of the 
> API-output snippets from our documentation were never updated to accommodate 
> this change.  So as-is, the output won't match what users following along at 
> home would get from running the commands.  This could throw some newer Solr 
> users.
> This JIRA is created to resolve this inconsistency.  Either by adding the 
> "wt=xml" param to the API command corresponding to any XML snippets, or by 
> switching the snippets over to all use JSON.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11528) ltr unit tests failed


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

Christine Poerschke commented on SOLR-11528:


Hello [~jj380382856] - thanks for opening this ticket and attaching a patch!

bq. If we build the lucene project first and then run the ltr unit test, it 
will have the following error: ...

Could you share more details on how you build and run the tests, possibly with 
seeds that reproduce the issue, e.g. in the output you might see something like
{code}
NOTE: reproduce with: ant test  -Dtestcase=... -Dtests.seed=... ...
{code}

Personally I haven't come across the {{... unknown field 'description' ...}} 
error locally and it would be great to reproduce the exact issue before making 
changes.

> ltr  unit tests failed
> --
>
> Key: SOLR-11528
> URL: https://issues.apache.org/jira/browse/SOLR-11528
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Affects Versions: master (8.0)
> Environment: eclipse oxygen
>Reporter: jin jing
> Fix For: master (8.0)
>
> Attachments: SOLR-11528.patch
>
>
> If we build the lucene project first and then run the ltr unit test, it will 
> have the following error:
> ERROR: [doc=1] unknown field 'description'
> i found this is beacuse of the under the floader  
> solr\contrib\ltr\src\test-files  we shoud modify solr\collection1\conf  to  
> ltr\solr\collection1\conf. and we shoud Specify solrhome in TestRerankBase.
> If you do not modify the path schema may be overwritten



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] lucene-solr pull request #266: Lucene 7804

2017-10-24 Thread shawnfeldman

GitHub user shawnfeldman opened a pull request:

https://github.com/apache/lucene-solr/pull/266

Lucene 7804



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shawnfeldman/lucene-solr LUCENE-7804-me

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/266.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #266


commit 9b29338f18e4af911791773048577a515b98e669
Author: Shawn Feldman 
Date:   2017-10-24T19:57:44Z

LUCENE-7804




---

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

[GitHub] lucene-solr pull request #265: Lucene 7804

2017-10-24 Thread shawnfeldman

Github user shawnfeldman closed the pull request at:

https://github.com/apache/lucene-solr/pull/265


---

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

[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 260 - Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/260/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at 
http://127.0.0.1:52498/solr/awhollynewcollection_0_shard4_replica_n6: 
ClusterState says we are the leader 
(http://127.0.0.1:52498/solr/awhollynewcollection_0_shard4_replica_n6), but 
locally we don't think so. Request came from null

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:52498/solr/awhollynewcollection_0_shard4_replica_n6: 
ClusterState says we are the leader 
(http://127.0.0.1:52498/solr/awhollynewcollection_0_shard4_replica_n6), but 
locally we don't think so. Request came from null
at 
__randomizedtesting.SeedInfo.seed([BF98B59FEE3C0E1:438CFFEDF8D0EF74]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:541)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:867)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:459)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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

[jira] [Commented] (SOLR-11530) Update ref-guide output snippets to match new default wt

2017-10-24 Thread ASF subversion and git services (JIRA)


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

Cassandra Targett commented on SOLR-11530:
--

This looks good [~gerlowskija]. I did a search for any others and found a 
couple of examples in working-with-dates that could to be done too so I'll add 
those to your patch and commit it in a little bit.

> Update ref-guide output snippets to match new default wt
> 
>
> Key: SOLR-11530
> URL: https://issues.apache.org/jira/browse/SOLR-11530
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Cassandra Targett
> Attachments: SOLR-11530.patch
>
>
> Solr 7.0 changed the default wt format from XML to JSON.  Many of the 
> API-output snippets from our documentation were never updated to accommodate 
> this change.  So as-is, the output won't match what users following along at 
> home would get from running the commands.  This could throw some newer Solr 
> users.
> This JIRA is created to resolve this inconsistency.  Either by adding the 
> "wt=xml" param to the API command corresponding to any XML snippets, or by 
> switching the snippets over to all use JSON.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-7990) Geo3dRptTest failure, GeoExactCircle and GeoComplexPolygon

2017-10-24 Thread Karl Wright (JIRA)


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

Karl Wright resolved LUCENE-7990.
-
   Resolution: Fixed
Fix Version/s: 7.2
   master (8.0)
   6.7

> Geo3dRptTest failure, GeoExactCircle and GeoComplexPolygon
> --
>
> Key: LUCENE-7990
> URL: https://issues.apache.org/jira/browse/LUCENE-7990
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: 7.1
>Reporter: David Smiley
>Assignee: Karl Wright
> Fix For: 6.7, master (8.0), 7.2
>
> Attachments: LUCENE-7990.patch, LUCENE-7990.patch
>
>
> To reproduce:
> {{ant test  -Dtestcase=Geo3dRptTest -Dtests.method=testOperations 
> -Dtests.seed=35F19948C8D0B296 -Dtests.multiplier=3 -Dtests.slow=true}}
> {noformat}
>   [junit4] FAILURE 1.60s | Geo3dRptTest.testOperations 
> {seed=[35F19948C8D0B296:4C8BC51BAD80E140]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: [Intersects] qIdx:46 
> Shouldn't match I#1:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-0.9559804772783842, 
> lon=2.3746400238746745([X=-0.41485128662362136, Y=0.3998224895518887, 
> Z=-0.8159609316679225])], radius=0.2927546208674785(16.773604208659055), 
> accuracy=1.9835991319951308E-4} Q:Geo3D:GeoComplexPolygon: 
> {planetmodel=PlanetModel.WGS84, number of shapes=1, address=48a56db9, 
> testPoint=[lat=-0.6911309532123969, 
> lon=-1.825801910033474([X=-0.19431732451263006, Y=-0.7454226529152223, 
> Z=-0.6372503253316519])], testPointInSet=true, shapes={ 
> {[lat=-1.387818122744865, lon=-2.7792398669224005([X=-0.16978152317325065, 
> Y=-0.06436270935780461, Z=-0.9812145381630729])], [lat=0.3097381417459196, 
> lon=-1.2840888403614732([X=0.2695553433310933, Y=-0.9142719953894461, 
> Z=0.30505479536297536])], [lat=-0.0480217407750678, 
> lon=-1.8503085663094863([X=-0.2758749814522231, Y=-0.9611487663811242, 
> Z=-0.04805662135798377])], [lat=-0.562588503679275, 
> lon=0.1031827231215822([X=0.841513436598657, Y=0.08713911491133425, 
> Z=-0.533463142870229])], [lat=-1.2344672208544873, 
> lon=-0.4462630141292253([X=0.29714578386731183, Y=-0.14217069789173978, 
> Z=-0.9422037262649413])], [lat=0.3278373341365327, 
> lon=-1.4874282088599309([X=0.07889725918747778, Y=-0.9441785582346046, 
> Z=0.3222439993016786])], [lat=1.084105292601162, 
> lon=2.757011421605791([X=-0.4328875155449605, Y=0.17520454460023893, 
> Z=0.8825538642625743])], [lat=0.9435002493553667, 
> lon=2.474535178256974([X=-0.4606403525400187, Y=0.3627431535977759, 
> Z=0.8087390201902855])], [lat=-0.6491383005683652, 
> lon=-0.6236527284532923([X=0.6465724515973865, Y=-0.46516869386856063, 
> Z=-0.6044327179281425])], [lat=-0.615469772740116, 
> lon=2.908550337184802([X=-0.7944279172337232, Y=0.1885612520247134, 
> Z=-0.5773400032472633])], [lat=-0.26863911348502323, 
> lon=1.2430264151885233([X=0.31065925040467024, Y=0.9136095339661758, 
> Z=-0.2656535169115309])], [lat=1.340203739358425, 
> lon=0.8281168704009712([X=0.15424430350138682, Y=0.16801937134287298, 
> Z=0.9715225323505815])], [lat=1.129241312019259, 
> lon=2.627460773729766([X=-0.3714930761512795, Y=0.20981779772740047, 
> Z=0.9026170614434411])]}}
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([35F19948C8D0B296:4C8BC51BAD80E140]:0)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>[junit4]>at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7990) Geo3dRptTest failure, GeoExactCircle and GeoComplexPolygon


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

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

Commit 3a95ccf32ee732d904dd544634567ee169465bac in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3a95ccf ]

LUCENE-7990: Fix polygon generator to not generate crossing polygons.  
Committed on behalf of Ignacio Vera.


> Geo3dRptTest failure, GeoExactCircle and GeoComplexPolygon
> --
>
> Key: LUCENE-7990
> URL: https://issues.apache.org/jira/browse/LUCENE-7990
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: 7.1
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-7990.patch, LUCENE-7990.patch
>
>
> To reproduce:
> {{ant test  -Dtestcase=Geo3dRptTest -Dtests.method=testOperations 
> -Dtests.seed=35F19948C8D0B296 -Dtests.multiplier=3 -Dtests.slow=true}}
> {noformat}
>   [junit4] FAILURE 1.60s | Geo3dRptTest.testOperations 
> {seed=[35F19948C8D0B296:4C8BC51BAD80E140]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: [Intersects] qIdx:46 
> Shouldn't match I#1:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-0.9559804772783842, 
> lon=2.3746400238746745([X=-0.41485128662362136, Y=0.3998224895518887, 
> Z=-0.8159609316679225])], radius=0.2927546208674785(16.773604208659055), 
> accuracy=1.9835991319951308E-4} Q:Geo3D:GeoComplexPolygon: 
> {planetmodel=PlanetModel.WGS84, number of shapes=1, address=48a56db9, 
> testPoint=[lat=-0.6911309532123969, 
> lon=-1.825801910033474([X=-0.19431732451263006, Y=-0.7454226529152223, 
> Z=-0.6372503253316519])], testPointInSet=true, shapes={ 
> {[lat=-1.387818122744865, lon=-2.7792398669224005([X=-0.16978152317325065, 
> Y=-0.06436270935780461, Z=-0.9812145381630729])], [lat=0.3097381417459196, 
> lon=-1.2840888403614732([X=0.2695553433310933, Y=-0.9142719953894461, 
> Z=0.30505479536297536])], [lat=-0.0480217407750678, 
> lon=-1.8503085663094863([X=-0.2758749814522231, Y=-0.9611487663811242, 
> Z=-0.04805662135798377])], [lat=-0.562588503679275, 
> lon=0.1031827231215822([X=0.841513436598657, Y=0.08713911491133425, 
> Z=-0.533463142870229])], [lat=-1.2344672208544873, 
> lon=-0.4462630141292253([X=0.29714578386731183, Y=-0.14217069789173978, 
> Z=-0.9422037262649413])], [lat=0.3278373341365327, 
> lon=-1.4874282088599309([X=0.07889725918747778, Y=-0.9441785582346046, 
> Z=0.3222439993016786])], [lat=1.084105292601162, 
> lon=2.757011421605791([X=-0.4328875155449605, Y=0.17520454460023893, 
> Z=0.8825538642625743])], [lat=0.9435002493553667, 
> lon=2.474535178256974([X=-0.4606403525400187, Y=0.3627431535977759, 
> Z=0.8087390201902855])], [lat=-0.6491383005683652, 
> lon=-0.6236527284532923([X=0.6465724515973865, Y=-0.46516869386856063, 
> Z=-0.6044327179281425])], [lat=-0.615469772740116, 
> lon=2.908550337184802([X=-0.7944279172337232, Y=0.1885612520247134, 
> Z=-0.5773400032472633])], [lat=-0.26863911348502323, 
> lon=1.2430264151885233([X=0.31065925040467024, Y=0.9136095339661758, 
> Z=-0.2656535169115309])], [lat=1.340203739358425, 
> lon=0.8281168704009712([X=0.15424430350138682, Y=0.16801937134287298, 
> Z=0.9715225323505815])], [lat=1.129241312019259, 
> lon=2.627460773729766([X=-0.3714930761512795, Y=0.20981779772740047, 
> Z=0.9026170614434411])]}}
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([35F19948C8D0B296:4C8BC51BAD80E140]:0)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>[junit4]>at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7990) Geo3dRptTest failure, GeoExactCircle and GeoComplexPolygon

2017-10-24 Thread ASF subversion and git services (JIRA)


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

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

Commit 088b63b2cb9c426bde44383a2ad040c223698d91 in lucene-solr's branch 
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=088b63b ]

LUCENE-7990: Fix polygon generator to not generate crossing polygons.  
Committed on behalf of Ignacio Vera.


> Geo3dRptTest failure, GeoExactCircle and GeoComplexPolygon
> --
>
> Key: LUCENE-7990
> URL: https://issues.apache.org/jira/browse/LUCENE-7990
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: 7.1
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-7990.patch, LUCENE-7990.patch
>
>
> To reproduce:
> {{ant test  -Dtestcase=Geo3dRptTest -Dtests.method=testOperations 
> -Dtests.seed=35F19948C8D0B296 -Dtests.multiplier=3 -Dtests.slow=true}}
> {noformat}
>   [junit4] FAILURE 1.60s | Geo3dRptTest.testOperations 
> {seed=[35F19948C8D0B296:4C8BC51BAD80E140]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: [Intersects] qIdx:46 
> Shouldn't match I#1:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-0.9559804772783842, 
> lon=2.3746400238746745([X=-0.41485128662362136, Y=0.3998224895518887, 
> Z=-0.8159609316679225])], radius=0.2927546208674785(16.773604208659055), 
> accuracy=1.9835991319951308E-4} Q:Geo3D:GeoComplexPolygon: 
> {planetmodel=PlanetModel.WGS84, number of shapes=1, address=48a56db9, 
> testPoint=[lat=-0.6911309532123969, 
> lon=-1.825801910033474([X=-0.19431732451263006, Y=-0.7454226529152223, 
> Z=-0.6372503253316519])], testPointInSet=true, shapes={ 
> {[lat=-1.387818122744865, lon=-2.7792398669224005([X=-0.16978152317325065, 
> Y=-0.06436270935780461, Z=-0.9812145381630729])], [lat=0.3097381417459196, 
> lon=-1.2840888403614732([X=0.2695553433310933, Y=-0.9142719953894461, 
> Z=0.30505479536297536])], [lat=-0.0480217407750678, 
> lon=-1.8503085663094863([X=-0.2758749814522231, Y=-0.9611487663811242, 
> Z=-0.04805662135798377])], [lat=-0.562588503679275, 
> lon=0.1031827231215822([X=0.841513436598657, Y=0.08713911491133425, 
> Z=-0.533463142870229])], [lat=-1.2344672208544873, 
> lon=-0.4462630141292253([X=0.29714578386731183, Y=-0.14217069789173978, 
> Z=-0.9422037262649413])], [lat=0.3278373341365327, 
> lon=-1.4874282088599309([X=0.07889725918747778, Y=-0.9441785582346046, 
> Z=0.3222439993016786])], [lat=1.084105292601162, 
> lon=2.757011421605791([X=-0.4328875155449605, Y=0.17520454460023893, 
> Z=0.8825538642625743])], [lat=0.9435002493553667, 
> lon=2.474535178256974([X=-0.4606403525400187, Y=0.3627431535977759, 
> Z=0.8087390201902855])], [lat=-0.6491383005683652, 
> lon=-0.6236527284532923([X=0.6465724515973865, Y=-0.46516869386856063, 
> Z=-0.6044327179281425])], [lat=-0.615469772740116, 
> lon=2.908550337184802([X=-0.7944279172337232, Y=0.1885612520247134, 
> Z=-0.5773400032472633])], [lat=-0.26863911348502323, 
> lon=1.2430264151885233([X=0.31065925040467024, Y=0.9136095339661758, 
> Z=-0.2656535169115309])], [lat=1.340203739358425, 
> lon=0.8281168704009712([X=0.15424430350138682, Y=0.16801937134287298, 
> Z=0.9715225323505815])], [lat=1.129241312019259, 
> lon=2.627460773729766([X=-0.3714930761512795, Y=0.20981779772740047, 
> Z=0.9026170614434411])]}}
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([35F19948C8D0B296:4C8BC51BAD80E140]:0)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>[junit4]>at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7990) Geo3dRptTest failure, GeoExactCircle and GeoComplexPolygon

2017-10-24 Thread ASF subversion and git services (JIRA)


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

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

Commit feda2ad006c3e8618a17be14106ed71f43e3d0c7 in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=feda2ad ]

LUCENE-7990: Fix polygon generator to not generate crossing polygons.  
Committed on behalf of Ignacio Vera.


> Geo3dRptTest failure, GeoExactCircle and GeoComplexPolygon
> --
>
> Key: LUCENE-7990
> URL: https://issues.apache.org/jira/browse/LUCENE-7990
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: 7.1
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-7990.patch, LUCENE-7990.patch
>
>
> To reproduce:
> {{ant test  -Dtestcase=Geo3dRptTest -Dtests.method=testOperations 
> -Dtests.seed=35F19948C8D0B296 -Dtests.multiplier=3 -Dtests.slow=true}}
> {noformat}
>   [junit4] FAILURE 1.60s | Geo3dRptTest.testOperations 
> {seed=[35F19948C8D0B296:4C8BC51BAD80E140]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: [Intersects] qIdx:46 
> Shouldn't match I#1:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-0.9559804772783842, 
> lon=2.3746400238746745([X=-0.41485128662362136, Y=0.3998224895518887, 
> Z=-0.8159609316679225])], radius=0.2927546208674785(16.773604208659055), 
> accuracy=1.9835991319951308E-4} Q:Geo3D:GeoComplexPolygon: 
> {planetmodel=PlanetModel.WGS84, number of shapes=1, address=48a56db9, 
> testPoint=[lat=-0.6911309532123969, 
> lon=-1.825801910033474([X=-0.19431732451263006, Y=-0.7454226529152223, 
> Z=-0.6372503253316519])], testPointInSet=true, shapes={ 
> {[lat=-1.387818122744865, lon=-2.7792398669224005([X=-0.16978152317325065, 
> Y=-0.06436270935780461, Z=-0.9812145381630729])], [lat=0.3097381417459196, 
> lon=-1.2840888403614732([X=0.2695553433310933, Y=-0.9142719953894461, 
> Z=0.30505479536297536])], [lat=-0.0480217407750678, 
> lon=-1.8503085663094863([X=-0.2758749814522231, Y=-0.9611487663811242, 
> Z=-0.04805662135798377])], [lat=-0.562588503679275, 
> lon=0.1031827231215822([X=0.841513436598657, Y=0.08713911491133425, 
> Z=-0.533463142870229])], [lat=-1.2344672208544873, 
> lon=-0.4462630141292253([X=0.29714578386731183, Y=-0.14217069789173978, 
> Z=-0.9422037262649413])], [lat=0.3278373341365327, 
> lon=-1.4874282088599309([X=0.07889725918747778, Y=-0.9441785582346046, 
> Z=0.3222439993016786])], [lat=1.084105292601162, 
> lon=2.757011421605791([X=-0.4328875155449605, Y=0.17520454460023893, 
> Z=0.8825538642625743])], [lat=0.9435002493553667, 
> lon=2.474535178256974([X=-0.4606403525400187, Y=0.3627431535977759, 
> Z=0.8087390201902855])], [lat=-0.6491383005683652, 
> lon=-0.6236527284532923([X=0.6465724515973865, Y=-0.46516869386856063, 
> Z=-0.6044327179281425])], [lat=-0.615469772740116, 
> lon=2.908550337184802([X=-0.7944279172337232, Y=0.1885612520247134, 
> Z=-0.5773400032472633])], [lat=-0.26863911348502323, 
> lon=1.2430264151885233([X=0.31065925040467024, Y=0.9136095339661758, 
> Z=-0.2656535169115309])], [lat=1.340203739358425, 
> lon=0.8281168704009712([X=0.15424430350138682, Y=0.16801937134287298, 
> Z=0.9715225323505815])], [lat=1.129241312019259, 
> lon=2.627460773729766([X=-0.3714930761512795, Y=0.20981779772740047, 
> Z=0.9026170614434411])]}}
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([35F19948C8D0B296:4C8BC51BAD80E140]:0)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>[junit4]>at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11501) Depending on the parser, QParser should not parse local-params


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

David Smiley commented on SOLR-11501:
-

bq. what about a specification of what parsers are allowed/disallowed?

Sounds good to me.  Could be added in a separate issue.  Here I can try to 
structure the code to make the ability to parse it be more dynamic rather than 
binary.

bq. We could even make this do double-duty... be able to turn off lucene parser 
builtins as well (fuzzy queries, etc?)

Interesting idea.  There's a namespace issue though, unless we prefix/suffix 
one or the other to mitigate that.  

bq. For dismax, it seems like bug this ever parsed/used local params, the 
escaping should be enhanced so this doesn't happen. Both dismax and edismax 
need to not throw exceptions when encountering localParams as well.

I don't think Dismax (or eDismax) needs to be modified for new escaping rules.  
Both parsers already catch exceptions from the parser and relax it in a 
simplified manner.  I can add some tests to make this fact more clear.

bq. As far as this patch... I don't know at this point in time. It's hard to 
figure out what might break or what behavior is undesirable. 

The patch is fairly small and with it applied, all tests pass :-)  Of course 
some user is bound to use it in a way that will no longer be supported but it's 
telling the changes in our codebase were so limited.

bq. Need to look at all of the places that use a defType other than lucene and 
func.

FWIW I did.  Specifically, the method to find the callers of is 
{{getParser(String qstr, String defaultParser, SolrQueryRequest req)}}.  In 
solr-core there are 10 usages, and analytics module 1.  Tests add 23 more but 
they are not pertinent.

bq. Why not do it the other way: disable for dismax, optionally disable for 
extended. That would seem to make it much easier to reason about.

I'd be happy to outright disable subquery parsing (with no option/toggle) on 
dismax!  I spoke of this in my comment; I'll modify the patch accordingly.  And 
it's optional for edismax (toggle'able via {{uf}}); maybe I'm misunderstanding 
you?

> Depending on the parser, QParser should not parse local-params
> --
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query 
> parser) in certain circumstances.  _Perhaps_ it is when the QParser.getParser 
> is passed "lucene" for the {{defaultParser}}?  This particular approach is 
> just a straw-man; I suspect certain valid embedded queries could no longer 
> work if this is done incorrectly.  Whatever the solution, I don't think we 
> should assume 'q' is special, as it's valid and useful to build up queries 
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax 
> v=$qq\}=user input}}  and we want to protect the user input there 
> similarly from unwelcome query parsing switching.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11530) Update ref-guide output snippets to match new default wt


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

Cassandra Targett reassigned SOLR-11530:


Assignee: Cassandra Targett

> Update ref-guide output snippets to match new default wt
> 
>
> Key: SOLR-11530
> URL: https://issues.apache.org/jira/browse/SOLR-11530
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Cassandra Targett
> Attachments: SOLR-11530.patch
>
>
> Solr 7.0 changed the default wt format from XML to JSON.  Many of the 
> API-output snippets from our documentation were never updated to accommodate 
> this change.  So as-is, the output won't match what users following along at 
> home would get from running the commands.  This could throw some newer Solr 
> users.
> This JIRA is created to resolve this inconsistency.  Either by adding the 
> "wt=xml" param to the API command corresponding to any XML snippets, or by 
> switching the snippets over to all use JSON.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11539) autogenerated pdf-main-body.adoc should use explicit anchors for each included page


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

Hoss Man resolved SOLR-11539.
-
   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)
   7.2

> autogenerated pdf-main-body.adoc should use explicit anchors for each 
> included page
> ---
>
> Key: SOLR-11539
> URL: https://issues.apache.org/jira/browse/SOLR-11539
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 7.2, master (8.0), 7.1
>
> Attachments: SOLR-11539.patch
>
>
> see parent task for a discussion of why/how we currently have broken 
> links/anchors in the PDF due to relying on the auto-generated "section" IDs 
> for each included page and how nothing currently enforces that those 
> auto-generated IDs (from the page titles) match the {{page-shortname}} used 
> in the HTML pages where we do link validation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 660 - Still Unstable!

2017-10-24 Thread ASF subversion and git services (JIRA)

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/660/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseG1GC

7 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.legacy.facet.LegacyRangeFacetCloudTest

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 90 
seconds
at __randomizedtesting.SeedInfo.seed([17B944B40B529D96]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:185)
at 
org.apache.solr.analytics.legacy.LegacyAbstractAnalyticsCloudTest.setupCollection(LegacyAbstractAnalyticsCloudTest.java:51)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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:748)


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.PeerSyncReplicationTest

Error Message:
20 threads leaked from SUITE scope at 
org.apache.solr.cloud.PeerSyncReplicationTest: 1) Thread[id=326, 
name=qtp12824006-326, state=TIMED_WAITING, group=TGRP-PeerSyncReplicationTest]  
   at java.lang.Thread.sleep(Native Method) at 
org.apache.solr.cloud.ZkController.waitForShardId(ZkController.java:1561)   
  at 
org.apache.solr.cloud.ZkController.doGetShardIdAndNodeNameProcess(ZkController.java:1512)
 at 
org.apache.solr.cloud.ZkController.preRegister(ZkController.java:1621) 
at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1029)
 at org.apache.solr.core.CoreContainer.create(CoreContainer.java:948)   
  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
 at 
org.apache.solr.handler.admin.CoreAdminOperation$$Lambda$84/29221609.execute(Unknown
 Source) at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:384)
 at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)
 at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
 at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
 at 
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:735) 
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:716)  
   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:497)  
   at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
 at

[jira] [Commented] (SOLR-11539) autogenerated pdf-main-body.adoc should use explicit anchors for each included page


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

ASF subversion and git services commented on SOLR-11539:


Commit 2d8c34b316c3ec655e073daab812644c24a09d0b in lucene-solr's branch 
refs/heads/branch_7_1 from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2d8c34b ]

SOLR-11539: use page shortnames as explicit anchors in generated 
pdf-main-body.adoc

(cherry picked from commit ab388fa3a723ec59c80567c3c0448e16b985d20b)


> autogenerated pdf-main-body.adoc should use explicit anchors for each 
> included page
> ---
>
> Key: SOLR-11539
> URL: https://issues.apache.org/jira/browse/SOLR-11539
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-11539.patch
>
>
> see parent task for a discussion of why/how we currently have broken 
> links/anchors in the PDF due to relying on the auto-generated "section" IDs 
> for each included page and how nothing currently enforces that those 
> auto-generated IDs (from the page titles) match the {{page-shortname}} used 
> in the HTML pages where we do link validation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11539) autogenerated pdf-main-body.adoc should use explicit anchors for each included page

2017-10-24 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-11539:


Commit 1225c9dcc610c2bce55e6f8c09308c6af378fe66 in lucene-solr's branch 
refs/heads/branch_7x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1225c9d ]

SOLR-11539: use page shortnames as explicit anchors in generated 
pdf-main-body.adoc

(cherry picked from commit ab388fa3a723ec59c80567c3c0448e16b985d20b)


> autogenerated pdf-main-body.adoc should use explicit anchors for each 
> included page
> ---
>
> Key: SOLR-11539
> URL: https://issues.apache.org/jira/browse/SOLR-11539
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-11539.patch
>
>
> see parent task for a discussion of why/how we currently have broken 
> links/anchors in the PDF due to relying on the auto-generated "section" IDs 
> for each included page and how nothing currently enforces that those 
> auto-generated IDs (from the page titles) match the {{page-shortname}} used 
> in the HTML pages where we do link validation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11539) autogenerated pdf-main-body.adoc should use explicit anchors for each included page

2017-10-24 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-11539:


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

SOLR-11539: use page shortnames as explicit anchors in generated 
pdf-main-body.adoc


> autogenerated pdf-main-body.adoc should use explicit anchors for each 
> included page
> ---
>
> Key: SOLR-11539
> URL: https://issues.apache.org/jira/browse/SOLR-11539
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-11539.patch
>
>
> see parent task for a discussion of why/how we currently have broken 
> links/anchors in the PDF due to relying on the auto-generated "section" IDs 
> for each included page and how nothing currently enforces that those 
> auto-generated IDs (from the page titles) match the {{page-shortname}} used 
> in the HTML pages where we do link validation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11176) support set-but-empty SOLR_TIMEZONE in bin/solr


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

Christine Poerschke resolved SOLR-11176.

Resolution: Won't Do

Resolving as _Won't Do_ since the solr.cmd side of things looks to be overly 
complicated and it would be preferable to keep solr and solr.cmd in sync in 
terms of behaviour.

> support set-but-empty SOLR_TIMEZONE in bin/solr
> ---
>
> Key: SOLR-11176
> URL: https://issues.apache.org/jira/browse/SOLR-11176
> Project: Solr
>  Issue Type: Task
>  Components: scripts and tools
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11176.patch, SOLR-11176.patch
>
>
> Existing behaviour:
> * SOLR_TIMEZONE is unset: default to UTC
> * SOLR_TIMEZONE is set but empty: default to UTC
> * SOLR_TIMEZONE is set: use the set value
> Proposed alternative behaviour:
> * SOLR_TIMEZONE is unset: default to UTC
> * SOLR_TIMEZONE is set but empty: {{-Duser.timezone}} is _not_ added to the 
> command line
> * SOLR_TIMEZONE is set: use the set value



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11389) call registerReporter after Solr(Shard|Cluster)Reporter.setCore[Container]


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

Christine Poerschke resolved SOLR-11389.

   Resolution: Fixed
Fix Version/s: master (8.0)
   7.2

> call registerReporter after Solr(Shard|Cluster)Reporter.setCore[Container]
> --
>
> Key: SOLR-11389
> URL: https://issues.apache.org/jira/browse/SOLR-11389
> Project: Solr
>  Issue Type: Task
>  Components: metrics
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11389.patch, SOLR-11389.patch
>
>
> Currently 
> [SolrMetricManager.loadReporter|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.0.0/solr/core/src/java/org/apache/solr/metrics/SolrMetricManager.java#L823-L844]
>  does four things:
> * creates a new {{SolrMetricReporter}} instance (object)
> * calls {{reporter.init(pluginInfo);}} on the object
> * calls {{registerReporter(registry, pluginInfo.name, tag, reporter);}} for 
> the object
> * {{return reporter;}} returns the object
> For the returned object the {{SolrMetricManager.loadShardReporters}} and 
> {{SolrMetricManager.loadClusterReporters}} callers of 
> SolrMetricManager.loadReporter then call the 
> {{((SolrShardReporter)reporter).setCore(core);}} or 
> {{((SolrClusterReporter)reporter).setCoreContainer(cc);}} method. This means 
> that {{registerReporter}} happened before the SolrShardReporter and 
> SolrClusterReporter objects were fully set up. _(I have not yet fully 
> investigated if this might be unintentional-and-not-required or 
> intentional-and-required.)_
> The changes proposed in this ticket can be summarised as follows:
> * SolrMetricReporter.java
> {code}
> -  public SolrMetricReporter loadReporter(...) throws Exception {
> +  public void   loadReporter(...) throws Exception {
>  ...
>  try {
> -  reporter.init(pluginInfo);
> +  if (reporter instanceof SolrShardReporter) {
> +((SolrShardReporter)reporter).init(pluginInfo, solrCore);
> +  } else if (reporter instanceof SolrClusterReporter) {
> +((SolrClusterReporter)reporter).init(pluginInfo, coreContainer);
> +  } else {
> +reporter.init(pluginInfo);
> +  }
>  } catch (IllegalStateException e) {
>throw new IllegalArgumentException("reporter init failed: " + 
> pluginInfo, e);
>  }
>  registerReporter(registry, pluginInfo.name, tag, reporter);
> -return reporter;
>}
> {code}
> * SolrShardReporter.java
> {code}
> +  @Override
> +  public void init(PluginInfo pluginInfo) {
> +throw new 
> UnsupportedOperationException(getClass().getCanonicalName()+".init(PluginInfo)
>  is not supported, use init(PluginInfo,SolrCore) instead.");
> +  }
> -  public void setCore(SolrCore core) {
> +  public void init(PluginInfo pluginInfo, SolrCore core) {
> +super.init(pluginInfo);
>  ...
>}
> {code}
> * SolrClusterReporter.java
> {code}
> +  @Override
> +  public void init(PluginInfo pluginInfo) {
> +throw new 
> UnsupportedOperationException(getClass().getCanonicalName()+".init(PluginInfo)
>  is not supported, use init(PluginInfo,CoreContainer) instead.");
> +  }
> -  public void setCoreContainer(CoreContainer cc) {
> +  public void init(PluginInfo pluginInfo, CoreContainer cc) {
> +super.init(pluginInfo);
>  ...
>}
> {code}
> Context and motivation for the proposed changes is to support (in SOLR-11291) 
> the factoring out of an abstract SolrCoreReporter class, allowing folks to 
> create new reporters that 'know' the SolrCore they are reporting on.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7990) Geo3dRptTest failure, GeoExactCircle and GeoComplexPolygon

2017-10-24 Thread Ignacio Vera (JIRA)


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

Ignacio Vera updated LUCENE-7990:
-
Attachment: LUCENE-7990.patch

Hi [~karl wright],

I managed to update the random generator and use a better algorithm to order 
points so they not cross. I calculate the center of mass and the angle between 
the center of mass and the points. Then you can order them to avoid crossing 
edges.

It fixed the failing test and beasting the tests did not throw any errors.

> Geo3dRptTest failure, GeoExactCircle and GeoComplexPolygon
> --
>
> Key: LUCENE-7990
> URL: https://issues.apache.org/jira/browse/LUCENE-7990
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: 7.1
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-7990.patch, LUCENE-7990.patch
>
>
> To reproduce:
> {{ant test  -Dtestcase=Geo3dRptTest -Dtests.method=testOperations 
> -Dtests.seed=35F19948C8D0B296 -Dtests.multiplier=3 -Dtests.slow=true}}
> {noformat}
>   [junit4] FAILURE 1.60s | Geo3dRptTest.testOperations 
> {seed=[35F19948C8D0B296:4C8BC51BAD80E140]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: [Intersects] qIdx:46 
> Shouldn't match I#1:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-0.9559804772783842, 
> lon=2.3746400238746745([X=-0.41485128662362136, Y=0.3998224895518887, 
> Z=-0.8159609316679225])], radius=0.2927546208674785(16.773604208659055), 
> accuracy=1.9835991319951308E-4} Q:Geo3D:GeoComplexPolygon: 
> {planetmodel=PlanetModel.WGS84, number of shapes=1, address=48a56db9, 
> testPoint=[lat=-0.6911309532123969, 
> lon=-1.825801910033474([X=-0.19431732451263006, Y=-0.7454226529152223, 
> Z=-0.6372503253316519])], testPointInSet=true, shapes={ 
> {[lat=-1.387818122744865, lon=-2.7792398669224005([X=-0.16978152317325065, 
> Y=-0.06436270935780461, Z=-0.9812145381630729])], [lat=0.3097381417459196, 
> lon=-1.2840888403614732([X=0.2695553433310933, Y=-0.9142719953894461, 
> Z=0.30505479536297536])], [lat=-0.0480217407750678, 
> lon=-1.8503085663094863([X=-0.2758749814522231, Y=-0.9611487663811242, 
> Z=-0.04805662135798377])], [lat=-0.562588503679275, 
> lon=0.1031827231215822([X=0.841513436598657, Y=0.08713911491133425, 
> Z=-0.533463142870229])], [lat=-1.2344672208544873, 
> lon=-0.4462630141292253([X=0.29714578386731183, Y=-0.14217069789173978, 
> Z=-0.9422037262649413])], [lat=0.3278373341365327, 
> lon=-1.4874282088599309([X=0.07889725918747778, Y=-0.9441785582346046, 
> Z=0.3222439993016786])], [lat=1.084105292601162, 
> lon=2.757011421605791([X=-0.4328875155449605, Y=0.17520454460023893, 
> Z=0.8825538642625743])], [lat=0.9435002493553667, 
> lon=2.474535178256974([X=-0.4606403525400187, Y=0.3627431535977759, 
> Z=0.8087390201902855])], [lat=-0.6491383005683652, 
> lon=-0.6236527284532923([X=0.6465724515973865, Y=-0.46516869386856063, 
> Z=-0.6044327179281425])], [lat=-0.615469772740116, 
> lon=2.908550337184802([X=-0.7944279172337232, Y=0.1885612520247134, 
> Z=-0.5773400032472633])], [lat=-0.26863911348502323, 
> lon=1.2430264151885233([X=0.31065925040467024, Y=0.9136095339661758, 
> Z=-0.2656535169115309])], [lat=1.340203739358425, 
> lon=0.8281168704009712([X=0.15424430350138682, Y=0.16801937134287298, 
> Z=0.9715225323505815])], [lat=1.129241312019259, 
> lon=2.627460773729766([X=-0.3714930761512795, Y=0.20981779772740047, 
> Z=0.9026170614434411])]}}
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([35F19948C8D0B296:4C8BC51BAD80E140]:0)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>[junit4]>at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>[junit4]>at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11539) autogenerated pdf-main-body.adoc should use explicit anchors for each included page


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

Cassandra Targett commented on SOLR-11539:
--

I applied this patch locally and generated a PDF from master then compared that 
to the PDF that was released for 7.0. All of the currently broken links are 
fixed with this patch. I wasn't sure what else to look for so I tried to click 
as many links as I could - whether they were broken or not  - and I could not 
find any examples of broken links.

So, unless you can think of something else to check, +1 to commit.

> autogenerated pdf-main-body.adoc should use explicit anchors for each 
> included page
> ---
>
> Key: SOLR-11539
> URL: https://issues.apache.org/jira/browse/SOLR-11539
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-11539.patch
>
>
> see parent task for a discussion of why/how we currently have broken 
> links/anchors in the PDF due to relying on the auto-generated "section" IDs 
> for each included page and how nothing currently enforces that those 
> auto-generated IDs (from the page titles) match the {{page-shortname}} used 
> in the HTML pages where we do link validation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 1407 - Still Failing

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

6 tests failed.
FAILED:  org.apache.lucene.index.TestBagOfPositions.test

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([F318A0E5FC5C51D]:0)


FAILED:  junit.framework.TestSuite.org.apache.lucene.index.TestBagOfPositions

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([F318A0E5FC5C51D]:0)


FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard

Error Message:
Error from server at https://127.0.0.1:44830/solr: KeeperErrorCode = NoNode for 
/overseer/collection-queue-work/qnr-28

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:44830/solr: KeeperErrorCode = NoNode for 
/overseer/collection-queue-work/qnr-28
at 
__randomizedtesting.SeedInfo.seed([C28AB6B61C219EA8:7D402AA9AD45455]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:867)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard(CollectionsAPISolrJTest.java:157)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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

Re: [ANNOUNCE] Apache Solr 5.5.5 released

2017-10-24 Thread Moenieb Davids

Hi Steve,

I have just started with Solr 7.*, so I am a bit confused with 5.5.5, same
with lucene.
Also, the sites register versions 7.*,
Apologies for my ignorance if I had missed anything or do not have a proper
understanding of the version management

Regards
Moenieb

On Tue, Oct 24, 2017 at 6:27 PM, Steve Rowe  wrote:

> Yes.
>
> --
> Steve
> www.lucidworks.com
>
> > On Oct 24, 2017, at 12:25 PM, Moenieb Davids 
> wrote:
> >
> > Solr 5.5.5?
> >
> > On 24 Oct 2017 17:34, "Steve Rowe"  wrote:
> >
> >> 24 October 2017, Apache Solr™ 5.5.5 available
> >>
> >> The Lucene PMC is pleased to announce the release of Apache Solr 5.5.5.
> >>
> >> Solr is the popular, blazing fast, open source NoSQL search platform
> from
> >> the
> >> Apache Lucene project. Its major features include powerful full-text
> >> search,
> >> hit highlighting, faceted search and analytics, rich document parsing,
> >> geospatial search, extensive REST APIs as well as parallel SQL. Solr is
> >> enterprise grade, secure and highly scalable, providing fault tolerant
> >> distributed search and indexing, and powers the search and navigation
> >> features
> >> of many of the world's largest internet sites.
> >>
> >> This release contains one bugfix.
> >>
> >> This release includes one critical and one important security fix.
> Details:
> >>
> >> * Fix for a 0-day exploit (CVE-2017-12629), details:
> >> https://s.apache.org/FJDl.
> >> RunExecutableListener has been disabled by default (can be enabled by
> >> -Dsolr.enableRunExecutableListener=true) and resolving external
> entities
> >> in the
> >> XML query parser (defType=xmlparser or {!xmlparser ... }) is disabled by
> >> default.
> >>
> >> * Fix for CVE-2017-7660: Security Vulnerability in secure inter-node
> >> communication
> >> in Apache Solr, details: https://s.apache.org/APTY
> >>
> >> Furthermore, this release includes Apache Lucene 5.5.5 which includes
> one
> >> security
> >> fix since the 5.5.4 release.
> >>
> >> The release is available for immediate download at:
> >>
> >> http://www.apache.org/dyn/closer.lua/lucene/solr/5.5.5
> >>
> >> Please read CHANGES.txt for a detailed list of changes:
> >>
> >> https://lucene.apache.org/solr/5_5_5/changes/Changes.html
> >>
> >> Please report any feedback to the mailing lists
> >> (http://lucene.apache.org/solr/discussion.html)
> >>
> >> Note: The Apache Software Foundation uses an extensive mirroring
> >> network for distributing releases. It is possible that the mirror you
> >> are using may not have replicated the release yet. If that is the
> >> case, please try another mirror. This also goes for Maven access.
>
>

[jira] [Created] (SOLR-11542) Add feature to DistributedURP to route time partitioned collections

David Smiley created SOLR-11542:
---

 Summary: Add feature to DistributedURP to route time partitioned 
collections
 Key: SOLR-11542
 URL: https://issues.apache.org/jira/browse/SOLR-11542
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Reporter: David Smiley
 Fix For: 7.2


Assuming we have some time partitioning metadata on an alias (see SOLR-11487 
for the metadata facility), we'll then need to route documents to the right 
collection.  I tentatively propose a helper class to DistributedURP to do this. 
 Perhaps a separate URP is plausible, though it will take some modifications to 
DistributedURP.

The scope of this issue is:
* decide on some alias metadata names & semantics
* decide the collection suffix pattern.  Read/write code (needed to route).
* the routing code

No new partition creation nor deletion happens is this issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11541) purge unneccessary page-shortname and page-permalink attributes from all source docs

Hoss Man created SOLR-11541:
---

 Summary: purge unneccessary page-shortname and page-permalink 
attributes from all source docs
 Key: SOLR-11541
 URL: https://issues.apache.org/jira/browse/SOLR-11541
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man


once SOLR-11540 is done, we can remove all explicitly declared 
{{page-shortname}} and {{page-permalink}} variables from our source files and 
update BuildNavAndPDFBody to fail if someone tries to declare them 
unnecessarily/redundantly/contradictory 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11540) eliminate the need for page-shortname and/or page-permalink attributes in our asciidoc source files

Hoss Man created SOLR-11540:
---

 Summary: eliminate the need for page-shortname and/or 
page-permalink attributes in our asciidoc source files
 Key: SOLR-11540
 URL: https://issues.apache.org/jira/browse/SOLR-11540
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man


>From parent issue...

bq. Furthermore: the entire {{page-shortname}} and {{page-permalink}} variables 
in all of our {{*.adoc}} files arn't really neccessary – they are a convention 
I introduced early on in the process of building our the sidebar & next/pre 
link generation logic, but are error prone if/when people rename files.

Assuming SOLR-11539 works out, we can implicitly (in BuildNavAndPDFBody and our 
jekyll templates) use the basename of the {{file.adoc}} as the {{shortname}}, 
and use {{shortname + ".html"}} as the {{permalink}} and be done with it.

If SOLR-11539 doesn't work out, we can still generate those variables in the 
same way -- but we also have to validate that the generated values match the 
title (see existing patch in parent issue)





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11536) Solr Index Partition by Timestamp(day)


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

David Smiley resolved SOLR-11536.
-
Resolution: Invalid

Hi,
This issue is filed as a question; if you have a question then ask on the 
mailing list.
As it so happens, time partitioned collections are being worked on right now 
via SOLR-11299

> Solr Index Partition by Timestamp(day)
> --
>
> Key: SOLR-11536
> URL: https://issues.apache.org/jira/browse/SOLR-11536
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1
>Reporter: David Cuesta Merino
>
> I am using Solr Cloud for indexing a big amount of log data files. Should it 
> be necessary to partition the index? We have thought about partitioning the 
> index by timestamp(day).
> I have not found any document about how to partition an Index in Solr Cloud 
> by different components(day, hour...) of a timestamp.
> How that should be done?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11539) autogenerated pdf-main-body.adoc should use explicit anchors for each included page


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

Hoss Man updated SOLR-11539:

Attachment: SOLR-11539.patch

Here's a patch which updates BuildNavAndPDFBody to:

* validate that the {{page-shortname}} and {{page-permalink}} of all {{*.adoc}} 
files is consistent with the basefilename (no files currently fail this check, 
but it's important to catch future mistakes like this moving forward untill we 
can eliminate these attributes)
* adds explicit anchors using the {{page-shortname}} before each {{include::}} 
declaration in the generated {{pdf-main-body.adoc}} file

This should fix all of the broken "section" links mentioned in the parent issue 
where a page title doesn't "match" the filename/shortname...

{quote}
...we have existing {{*.adoc}} files with titles that don't match...

{noformat}
 [java] Building up tree of all known pages
 [java] 
/home/hossman/lucene/dev/solr/build/solr-ref-guide/content/solrcloud-autoscaling-overview.adoc
 has a mismatched title: Overview of SolrCloud Autoscaling => 
overview-of-solrcloud-autoscaling
 [java] 
/home/hossman/lucene/dev/solr/build/solr-ref-guide/content/the-extended-dismax-query-parser.adoc
 has a mismatched title: The Extended DisMax (eDismax) Query Parser => 
the-extended-dismax-edismax-query-parser
 [java] 
/home/hossman/lucene/dev/solr/build/solr-ref-guide/content/solrcloud-autoscaling-auto-add-replicas.adoc
 has a mismatched title: SolrCloud AutoScaling Automatically Adding Replicas => 
solrcloud-autoscaling-automatically-adding-replicas
 [java] 
/home/hossman/lucene/dev/solr/build/solr-ref-guide/content/how-to-contribute.adoc
 has a mismatched title: How to Contribute to Solr Documentation => 
how-to-contribute-to-solr-documentation
 [java] 
/home/hossman/lucene/dev/solr/build/solr-ref-guide/content/solrcloud-autoscaling-api.adoc
 has a mismatched title: Autoscaling API => autoscaling-api
 [java] 
/home/hossman/lucene/dev/solr/build/solr-ref-guide/content/index.adoc has a 
mismatched title: Apache Solr Reference Guide => apache-solr-reference-guide
 [java] 
/home/hossman/lucene/dev/solr/build/solr-ref-guide/content/solrcloud-autoscaling-policy-preferences.adoc
 has a mismatched title: Autoscaling Policy and Preferences => 
autoscaling-policy-and-preferences
 [java] 
/home/hossman/lucene/dev/solr/build/solr-ref-guide/content/cross-data-center-replication-cdcr.adoc
 has a mismatched title: Cross Data Center Replication (CDCR) => 
cross-data-center-replication-cdcr-
{noformat}
...

A few concrete Examples that are easy to "find" in the PDF:
* All links with the text "The Extended DisMax Query Parser" from the sections 
generated by query-screen.adoc, query-syntax-and-parsing.adoc, and 
searching.adoc
* link text "Overview of Autoscaling in SolrCloud" from 
solrcloud-autoscaling.adoc


{quote}

...and will mean that moving forward, we should be free to change the "title" 
of pages all we want w/o breaking any links.



I think this patch is good to go, and should probably be backported to 
branch_7_1 before the 7.1 ref guide ... but it would be good to get more 
eyeballs on the generate PDF to verify that it doesn't break anything

> autogenerated pdf-main-body.adoc should use explicit anchors for each 
> included page
> ---
>
> Key: SOLR-11539
> URL: https://issues.apache.org/jira/browse/SOLR-11539
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-11539.patch
>
>
> see parent task for a discussion of why/how we currently have broken 
> links/anchors in the PDF due to relying on the auto-generated "section" IDs 
> for each included page and how nothing currently enforces that those 
> auto-generated IDs (from the page titles) match the {{page-shortname}} used 
> in the HTML pages where we do link validation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 1491 - Still Unstable!

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete

Error Message:
Error from server at 
http://127.0.0.1:62083/solr/testcollection_shard1_replica_n2: Expected mime 
type application/octet-stream but got text/html.Error 
404HTTP ERROR: 404 Problem accessing 
/solr/testcollection_shard1_replica_n2/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n2/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.20.v20170531 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:62083/solr/testcollection_shard1_replica_n2: 
Expected mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: /solr/testcollection_shard1_replica_n2/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.20.v20170531



at 
__randomizedtesting.SeedInfo.seed([E67497D9EFF07510:458E397C68189FB5]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:541)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:867)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:167)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_144) - Build # 20725 - Still Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20725/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseParallelGC

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

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:35381

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:35381
at 
__randomizedtesting.SeedInfo.seed([140A886390F90C6F:9C5EB7B93E056197]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:867)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:315)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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

[jira] [Updated] (SOLR-9440) ZkStateReader on a client can cache collection state and never refresh it

2017-10-24 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  updated SOLR-9440:

Fix Version/s: master (8.0)

> ZkStateReader on a client can cache collection state and never refresh it
> -
>
> Key: SOLR-9440
> URL: https://issues.apache.org/jira/browse/SOLR-9440
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.7, 7.0, master (8.0)
>
>
> I saw this while writing a test case for SOLR-9438. The collection1 
> collection which was in stateFormat=2 was somehow caching the 
> CloudSolrClient's ZkStateReader such that the returned cluster state 
> contained the collection state. However this collection was neither watched 
> nor lazy so any call to waitForRecoveriesToFinish would see stale state and 
> loop until timeout.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11539) autogenerated pdf-main-body.adoc should use explicit anchors for each included page

Hoss Man created SOLR-11539:
---

 Summary: autogenerated pdf-main-body.adoc should use explicit 
anchors for each included page
 Key: SOLR-11539
 URL: https://issues.apache.org/jira/browse/SOLR-11539
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man


see parent task for a discussion of why/how we currently have broken 
links/anchors in the PDF due to relying on the auto-generated "section" IDs for 
each included page and how nothing currently enforces that those auto-generated 
IDs (from the page titles) match the {{page-shortname}} used in the HTML pages 
where we do link validation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11531) ref-guide build tool assumptions missmatch with how "section" level anchor ids are actaully generated in PDF


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

Hoss Man commented on SOLR-11531:
-

2 thoughts occurred to me last night...

# we can/should break this up into smaller sub-tasks that can be committed 
individually
# it _might_ be possible to fix the pdf generation to use *explicitly* declared 
anchors for each "page section" using the {{page-shortname}} (and later just 
the base filename) rather then requiring that the file names match the 
asciidoctor auto-generated ID equivilents for the filenames

I've been experimenting with #2 this morning and i think it works -- i'll open 
a sub-task for that ASAP, and we can worry about eliminating the need for 
explicitly declaring {{page-shortname}} in a distinct sub-task.

> ref-guide build tool assumptions missmatch with how "section" level anchor 
> ids are actaully generated in PDF
> 
>
> Key: SOLR-11531
> URL: https://issues.apache.org/jira/browse/SOLR-11531
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-11531.patch
>
>
> About a month ago, cassandra noticed [some problems with a few 
> links|https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9beafb612fa22b747b8728d7d954ea6e2bd37844]
>  in the ref-guide PDF which confused both of us.  Working through it to try 
> and understand what was going on -- and why the existigg custom link-checking 
> we do of the html-site version of the guide wasn't adequate for spotting 
> these kinds of problems -- I realized a few gaps in the rules our build tools 
> are enforcing...
> * the link checker, sidebar builder, & jekyll templates all have various 
> degrees of implicit/explicit assumptions that the {{page-shortname}} will 
> match the filename for each {{*.adoc}} file
> ** but nothing actaully enforces this as people edit pages & their titles
> * the jekyll templates use the {{page-shortname}} to create the {{ id="???" .../>}} attribute, and the link checker depends on that for 
> validation of links -- but on the PDF side of things, the normal [asciidoctor 
> rules for auto generated ids from section 
> headings|http://asciidoctor.org/docs/user-manual/#auto-generated-ids] is what 
> determines the anchor for each (page) header.
> ** so even though our (html based) link checker may be happy, mismatches 
> between page titles and page-shortnames cause broken links in the PDF
> Furthermore: the entire {{page-shortname}} and {{page-permalink}} variables 
> in all of our {{*.adoc}} files arn't really neccessary -- they are a 
> convention I introduced early on in the process of building our the sidebar & 
> next/pre link generation logic, but are error prone if/when people rename 
> files.
> 
> We Should (and I intend to)...
> # eliminate our dependency on {{page-shortname}} & {{page-permalink}} 
> attributes from all of our templates and nav-building code and use implicitly 
> generate values (from the filenames) instead
> # beef up our nav-building and link-checking code to verify that the "page 
> title" for each page matches to the filename -- so we can be confident the 
> per-page header anchors in our generated PDF are consistent with teh per-page 
> header anchors in our generated HTML 
> # remove all (no longer useful) {{page-shortname}} & {{page-permalink}} 
> attributes from all {{*.adoc}} files



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

2017-10-24 Thread ASF subversion and git services (JIRA)

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

No tests ran.

Build Log:
[...truncated 28006 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (35.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 29.7 MB in 0.09 sec (315.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 69.5 MB in 0.19 sec (371.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 79.8 MB in 0.22 sec (363.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6184 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6184 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   5.5.5
   [smoker]   6.6.2
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1484, in 
   [smoker] main()
   [smoker]   File 
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1428, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1466, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, gitRevision, version, testArgs, baseURL)
   [smoker]   File 
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 622, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
gitRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 774, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
   [smoker]   File 
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1404, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/build.xml:622:
 exec returned: 1

Total time: 149 minutes 12 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Resolved] (LUCENE-7999) Invalid segment file name

2017-10-24 Thread Michael McCandless (JIRA)


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

Michael McCandless resolved LUCENE-7999.

   Resolution: Fixed
Fix Version/s: 7.2
   master (8.0)

Thank you [~mikedemi]!

> Invalid segment file name
> -
>
> Key: LUCENE-7999
> URL: https://issues.apache.org/jira/browse/LUCENE-7999
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.x, 6.x, 7.0
>Reporter: Mykhailo Demianenko
>Priority: Minor
> Fix For: master (8.0), 7.2
>
> Attachments: LUCENE-7999.patch, segmentName.patch
>
>
> After really long and intensive index usage its possible to overflow counter 
> that used to generate new segment name that will not satisfy validation 
> criteria:
> Caused by: java.lang.IllegalArgumentException: invalid codec filename 
> '_-zik0zk_Lucene54_0.dvm', must match: _[a-z0-9]+(_.*)?\..*
> at 
> org.apache.lucene.index.SegmentInfo.checkFileNames(SegmentInfo.java:280)
> at org.apache.lucene.index.SegmentInfo.addFiles(SegmentInfo.java:262)
> at org.apache.lucene.index.SegmentInfo.setFiles(SegmentInfo.java:256)
> at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4080)
> at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3655)
> at 
> org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:588)
> at 
> org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:626)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7999) Invalid segment file name


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

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

Commit 4c5ce2d646ba6c44aab19dab725fb74a98df4134 in lucene-solr's branch 
refs/heads/branch_7x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4c5ce2d ]

LUCENE-7999: upgrade int to long for tracking the counter for the next segment 
name to prevent overflow


> Invalid segment file name
> -
>
> Key: LUCENE-7999
> URL: https://issues.apache.org/jira/browse/LUCENE-7999
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.x, 6.x, 7.0
>Reporter: Mykhailo Demianenko
>Priority: Minor
> Fix For: master (8.0), 7.2
>
> Attachments: LUCENE-7999.patch, segmentName.patch
>
>
> After really long and intensive index usage its possible to overflow counter 
> that used to generate new segment name that will not satisfy validation 
> criteria:
> Caused by: java.lang.IllegalArgumentException: invalid codec filename 
> '_-zik0zk_Lucene54_0.dvm', must match: _[a-z0-9]+(_.*)?\..*
> at 
> org.apache.lucene.index.SegmentInfo.checkFileNames(SegmentInfo.java:280)
> at org.apache.lucene.index.SegmentInfo.addFiles(SegmentInfo.java:262)
> at org.apache.lucene.index.SegmentInfo.setFiles(SegmentInfo.java:256)
> at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4080)
> at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3655)
> at 
> org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:588)
> at 
> org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:626)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7999) Invalid segment file name

2017-10-24 Thread ASF subversion and git services (JIRA)


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

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

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

LUCENE-7999: upgrade int to long for tracking the counter for the next segment 
name to prevent overflow


> Invalid segment file name
> -
>
> Key: LUCENE-7999
> URL: https://issues.apache.org/jira/browse/LUCENE-7999
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.x, 6.x, 7.0
>Reporter: Mykhailo Demianenko
>Priority: Minor
> Attachments: LUCENE-7999.patch, segmentName.patch
>
>
> After really long and intensive index usage its possible to overflow counter 
> that used to generate new segment name that will not satisfy validation 
> criteria:
> Caused by: java.lang.IllegalArgumentException: invalid codec filename 
> '_-zik0zk_Lucene54_0.dvm', must match: _[a-z0-9]+(_.*)?\..*
> at 
> org.apache.lucene.index.SegmentInfo.checkFileNames(SegmentInfo.java:280)
> at org.apache.lucene.index.SegmentInfo.addFiles(SegmentInfo.java:262)
> at org.apache.lucene.index.SegmentInfo.setFiles(SegmentInfo.java:256)
> at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4080)
> at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3655)
> at 
> org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:588)
> at 
> org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:626)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: [ANNOUNCE] Apache Solr 5.5.5 released

2017-10-24 Thread Moenieb Davids

Solr 5.5.5?

On 24 Oct 2017 17:34, "Steve Rowe"  wrote:

> 24 October 2017, Apache Solr™ 5.5.5 available
>
> The Lucene PMC is pleased to announce the release of Apache Solr 5.5.5.
>
> Solr is the popular, blazing fast, open source NoSQL search platform from
> the
> Apache Lucene project. Its major features include powerful full-text
> search,
> hit highlighting, faceted search and analytics, rich document parsing,
> geospatial search, extensive REST APIs as well as parallel SQL. Solr is
> enterprise grade, secure and highly scalable, providing fault tolerant
> distributed search and indexing, and powers the search and navigation
> features
> of many of the world's largest internet sites.
>
> This release contains one bugfix.
>
> This release includes one critical and one important security fix. Details:
>
> * Fix for a 0-day exploit (CVE-2017-12629), details:
> https://s.apache.org/FJDl.
> RunExecutableListener has been disabled by default (can be enabled by
> -Dsolr.enableRunExecutableListener=true) and resolving external entities
> in the
> XML query parser (defType=xmlparser or {!xmlparser ... }) is disabled by
> default.
>
> * Fix for CVE-2017-7660: Security Vulnerability in secure inter-node
> communication
> in Apache Solr, details: https://s.apache.org/APTY
>
> Furthermore, this release includes Apache Lucene 5.5.5 which includes one
> security
> fix since the 5.5.4 release.
>
> The release is available for immediate download at:
>
> http://www.apache.org/dyn/closer.lua/lucene/solr/5.5.5
>
> Please read CHANGES.txt for a detailed list of changes:
>
> https://lucene.apache.org/solr/5_5_5/changes/Changes.html
>
> Please report any feedback to the mailing lists
> (http://lucene.apache.org/solr/discussion.html)
>
> Note: The Apache Software Foundation uses an extensive mirroring
> network for distributing releases. It is possible that the mirror you
> are using may not have replicated the release yet. If that is the
> case, please try another mirror. This also goes for Maven access.

Re: API Docs Output Snippet Formats

2017-10-24 Thread Jason Gerlowski

I've uploaded a patch adding the necessary "wt" parameter to the
output snippets.  I agree that aligning all of our API snippets on the
default output format is a better solution, but this serves as a
reasonable stop-gap until I'm (or someone else is) able to put that
together.

On Mon, Oct 23, 2017 at 7:36 PM, Jason Gerlowski  wrote:
> Thanks for the feedback (and context/history) guys.  I've created
> SOLR-11530 (https://issues.apache.org/jira/browse/SOLR-11530) to keep
> track of this.
>
> You're right Cassandra, switching the snippets over to JSON will
> probably take a bit of time.  I'm going to give it a shot this
> evening, in case it's easier than it first appears.  But assuming it's
> not, I plan to upload a patch adding the appropriate "wt" params, as a
> short term fix.
>
> Jason
>
> On Mon, Oct 23, 2017 at 12:14 PM, Cassandra Targett
>  wrote:
>> I did a pass through the Ref Guide for SOLR-10494 and noted there [1]
>> that I neglected to look for places where the output was XML but the
>> sample request did not include "wt=xml". My intent was to look for
>> those later, but then I forgot.
>>
>> It's likely easier to find where the request is missing "wt=xml" than
>> to change the XML examples to JSON, although having them all in JSON
>> is preferable. If you're willing to cook up a patch for either, it
>> would be appreciated.
>>
>> If you think changing them to JSON will take you a while (and it
>> might), I'd be happy to split the work and do the pass through for
>> missing "wt=xml" params as a temporary measure.
>>
>> Cassandra
>>
>> [1] 
>> https://issues.apache.org/jira/browse/SOLR-10494?focusedCommentId=16056403=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16056403
>>
>> On Sun, Oct 22, 2017 at 9:47 PM, Varun Thacker  wrote:
>>> I'd prefer 1>
>>>
>>> On Sun, Oct 22, 2017 at 7:39 PM, Jason Gerlowski 
>>> wrote:

 Hey all,

 Was doing some poking around the ref-guide this weekend.  I noticed
 that the output snippets given with the API documentation is split
 about 50/50 between xml and json.  Few of the examples contain an
 explicit "wt" parameter.  With the default "wt" format switching to
 json in 7.0, this means that any of the output snippets in XML format
 won't match what a user following along would see themselves.

 This won't trouble experienced users, but it could be a small
 speedbump for any new Solr adopters.  Making the snippets match the
 API calls would make the docs more correct, and more amateur-friendly.

 There's two approaches we could take to bring things into better
 alignment:

 1. Change all API output snippets to JSON.

 2, Don't change the format of any snippets.  Instead, add a "wt"
 parameter to the API call corresponding to any XML snippets, so that
 the input-call matches the output.

 Happy to create a JIRA and propose a patch for either approach if
 people think it's worth it, or have a particular preference on
 approach.  Anyone have any thoughts?

 Best,

 Jason

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

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

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

[jira] [Updated] (SOLR-11530) Update ref-guide output snippets to match new default wt

2017-10-24 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski updated SOLR-11530:
---
Attachment: SOLR-11530.patch

Attached patch adds the necessary wt=xml parameter to any Solr-ref-guide 
snippets whose output is in XML format.

A more ideal solution would involve aligning all API output snippets on the 
default format: JSON.  But this looks like it will take a bit of time, and this 
change makes a reasonable stopgap solution.

> Update ref-guide output snippets to match new default wt
> 
>
> Key: SOLR-11530
> URL: https://issues.apache.org/jira/browse/SOLR-11530
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
> Attachments: SOLR-11530.patch
>
>
> Solr 7.0 changed the default wt format from XML to JSON.  Many of the 
> API-output snippets from our documentation were never updated to accommodate 
> this change.  So as-is, the output won't match what users following along at 
> home would get from running the commands.  This could throw some newer Solr 
> users.
> This JIRA is created to resolve this inconsistency.  Either by adding the 
> "wt=xml" param to the API command corresponding to any XML snippets, or by 
> switching the snippets over to all use JSON.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11482) CVE-2017-12629: Remove RunExecutableListener from Solr

2017-10-24 Thread Steve Rowe (JIRA)


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

Steve Rowe resolved SOLR-11482.
---
Resolution: Fixed

> CVE-2017-12629: Remove RunExecutableListener from Solr
> --
>
> Key: SOLR-11482
> URL: https://issues.apache.org/jira/browse/SOLR-11482
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security, Server
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 5.5.5, 7.2, master (8.0), 6.6.2, 7.1
>
> Attachments: SOLR-11482-6.6.patch, 
> SOLR-11482-branch_5_5-restore-logged-warning.patch, SOLR-11482.patch
>
>
> This class should no longer be needed, as replication can be done through 
> Solr Cloud or via ReplicationHandler. The current listener is a security 
> risk, as it can be configured through the Config API. See the report:
> Solr "RunExecutableListener" class can be used to execute arbitrary commands 
> on specific events, for example after each update query. The problem is that 
> such listener can be enabled with any parameters just by using Config API 
> with add-listener command.
> {noformat}
> POST /solr/newcollection/config HTTP/1.1
> Host: localhost:8983
> Connection: close
> Content-Type: application/json  
> Content-Length: 198
> {
>   "add-listener" : {
> "event":"postCommit",
> "name":"newlistener",
> "class":"solr.RunExecutableListener",
> "exe":"ANYCOMMAND",
> "dir":"/usr/bin/",
> "args":["ANYARGS"]
>   }
> }
> {noformat}
> Parameters "exe", "args" and "dir" can be crafted throught the HTTP request 
> during modification of the collection's config. This means that anybody who 
> can send a HTTP request to Solr API is able to execute arbitrary shell 
> commands when "postCommit" event is fired. It leads to execution of arbitrary 
> remote code for a remote attacker.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Reopened] (SOLR-11469) LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the wrong shard's elections


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

Hoss Man reopened SOLR-11469:
-

> LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the 
> wrong shard's elections
> 
>
> Key: SOLR-11469
> URL: https://issues.apache.org/jira/browse/SOLR-11469
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11469.patch, SOLR-11469.patch, 
> SOLR-11469_incomplete_and_broken.patch
>
>
> LeaderElectionContextKeyTest is very flaky -- and on millers beastit reports 
> it shows a suspiciously close to "50%" failure rate.
> Digging into the test i realized that it creates a 2 shard index, then picks 
> "a leader" to kill (arbitrarily) and then asserts that the leader election 
> nodes for *shard1* are affected ... so ~50% of the time it kills the shard2 
> leader and then fails because it doesn't see an election in shard1.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11469) LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the wrong shard's elections


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

Hoss Man commented on SOLR-11469:
-

bq. We will have same replica names for each collection. ( This satisfy current 
logic of Assign.buildCoreNodeName )

Hmmm... i'm -0 having the test make these assumptions.  Fundementally this is 
the same problem the test had before: it makes assumptions about the lower 
level implementation of how/when coreNodeMakes will be assigned that the client 
code used in the test doesn't have any control over -- and doesn't directly 
validate.  if/when the implementation changes the test _may_ start failing in 
unpredictable ways.

Can we please at least add some sanity check assertions to this test that will 
look at the clusterstate and fail with a clear error message if the 
audo-assigned coreNodeNames don't match the expectations of the test?

> LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the 
> wrong shard's elections
> 
>
> Key: SOLR-11469
> URL: https://issues.apache.org/jira/browse/SOLR-11469
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11469.patch, SOLR-11469.patch, 
> SOLR-11469_incomplete_and_broken.patch
>
>
> LeaderElectionContextKeyTest is very flaky -- and on millers beastit reports 
> it shows a suspiciously close to "50%" failure rate.
> Digging into the test i realized that it creates a 2 shard index, then picks 
> "a leader" to kill (arbitrarily) and then asserts that the leader election 
> nodes for *shard1* are affected ... so ~50% of the time it kills the shard2 
> leader and then fails because it doesn't see an election in shard1.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: [ANNOUNCE] Apache Solr 5.5.5 released

2017-10-24 Thread Steve Rowe

Yes.  

--
Steve
www.lucidworks.com

> On Oct 24, 2017, at 12:25 PM, Moenieb Davids  wrote:
> 
> Solr 5.5.5?
> 
> On 24 Oct 2017 17:34, "Steve Rowe"  wrote:
> 
>> 24 October 2017, Apache Solr™ 5.5.5 available
>> 
>> The Lucene PMC is pleased to announce the release of Apache Solr 5.5.5.
>> 
>> Solr is the popular, blazing fast, open source NoSQL search platform from
>> the
>> Apache Lucene project. Its major features include powerful full-text
>> search,
>> hit highlighting, faceted search and analytics, rich document parsing,
>> geospatial search, extensive REST APIs as well as parallel SQL. Solr is
>> enterprise grade, secure and highly scalable, providing fault tolerant
>> distributed search and indexing, and powers the search and navigation
>> features
>> of many of the world's largest internet sites.
>> 
>> This release contains one bugfix.
>> 
>> This release includes one critical and one important security fix. Details:
>> 
>> * Fix for a 0-day exploit (CVE-2017-12629), details:
>> https://s.apache.org/FJDl.
>> RunExecutableListener has been disabled by default (can be enabled by
>> -Dsolr.enableRunExecutableListener=true) and resolving external entities
>> in the
>> XML query parser (defType=xmlparser or {!xmlparser ... }) is disabled by
>> default.
>> 
>> * Fix for CVE-2017-7660: Security Vulnerability in secure inter-node
>> communication
>> in Apache Solr, details: https://s.apache.org/APTY
>> 
>> Furthermore, this release includes Apache Lucene 5.5.5 which includes one
>> security
>> fix since the 5.5.4 release.
>> 
>> The release is available for immediate download at:
>> 
>> http://www.apache.org/dyn/closer.lua/lucene/solr/5.5.5
>> 
>> Please read CHANGES.txt for a detailed list of changes:
>> 
>> https://lucene.apache.org/solr/5_5_5/changes/Changes.html
>> 
>> Please report any feedback to the mailing lists
>> (http://lucene.apache.org/solr/discussion.html)
>> 
>> Note: The Apache Software Foundation uses an extensive mirroring
>> network for distributing releases. It is possible that the mirror you
>> are using may not have replicated the release yet. If that is the
>> case, please try another mirror. This also goes for Maven access.


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

[jira] [Commented] (SOLR-11537) Add Replica after upgrading from Solr 6.2.1 to Solr 7.1.0 throws InvalidClassException

2017-10-24 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on SOLR-11537:
-

Yes, I discussed this with [~dsmiley] on the dev IRC channel as he mentioned.  
I also fired off an email to [~erickerickson] asking for his opinion on whether 
it looked as bad to him as it did to me.

After a look at git history, I think that the commit for SOLR-10755 is what 
caused the new value for SimpleOrderedMap#SerialVersionUID.  That change 
certainly looked innocent enough.  If I'm right, then if SimpleOrderedMap had 
contained a hard-coded definition of SerialVersionUID, there wouldn't have been 
an issue.

We should look at any other classes that are transmitted with the javabin 
format to see if any are missing SerialVersionUID, find out what the compiler's 
calculated value is, and explicitly set them.


> Add Replica after upgrading from Solr 6.2.1 to Solr 7.1.0 throws 
> InvalidClassException
> --
>
> Key: SOLR-11537
> URL: https://issues.apache.org/jira/browse/SOLR-11537
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.1
> Environment: Solr 6.2.1 & Solr 7.1.0
>Reporter: Atita Arora
>
> We have a Solr cloud running with multiple collections with each collection 
> split over 6 shards with replication factor of 2.
> We would want to use some advance features like  LTR and advance analysis 
> using heavily nested documents, thus we wished to upgrade.
> So we attempted to upgrade one of the nodes from the cluster to Solr 7.1.0.
> Ideally when restarted the node happily became the part of cluster while when 
> attempted to ADDREPLICA through API and through Admin console we ran into the 
> below issue :
> null:org.apache.solr.common.SolrException: java.io.InvalidClassException: 
> org.apache.solr.common.util.SimpleOrderedMap; local class incompatible: 
> stream classdesc serialVersionUID = -2149411884323073227, local class 
> serialVersionUID = 4921066926612345812
>   at 
> org.apache.solr.client.solrj.SolrResponse.deserialize(SolrResponse.java:61)
>   at 
> org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:301)
>   at 
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:243)
>   at 
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:221)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:745)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:726)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:507)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:534)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
>   at 
>

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 264 - Still Unstable!