Re: The Gradle train.

2019-08-15 Thread Dawid Weiss
I'm +1. Gradle can be annoying like hell, but it's much faster and
flexible than any other build tool I've tried.
D.

On Thu, Aug 15, 2019 at 11:24 PM Mark Miller  wrote:
>
> https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the 
> lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
>
> Okay, we are at the point where either this thing lands soon and gains some 
> contributors to help finish or it  overwhelms me and crashes & burns. That 
> almost sounds negative, but it was actually the plan so far and I'm pretty 
> excited after all this time invested. I need to punt this over to the 
> community though - the final implications and ramifications of moving fully 
> to gradle are just too big for me individually regardless of the time frame.
>
> I've done about 95%+ of what I wanted to do before trying to land something - 
> a few more hoops to jump around. We pull in more deps than we should right 
> now, I'll deal with that shortly, and mvn publishing needs work (mostly 
> around solr-server, but dist and publishing both prob need edge work at 
> least). Those are the main things on my mind. There are probably a ton of 
> other little things, but I'm thinking those that are important will rise up 
> quickly and the rest can be handled over time.
>
> This will be a large change. Some things will still take time to get up to 
> par with what we have now. Many things will need to be sorted out (jenkins, 
> releases, smoke tester type things, docs, etc).
>
> I've also made all the decisions and trade-offs and what not. I'm pretty 
> happy about that, but I'm sure some will want to discuss and debate some 
> choices once things are in their face. I've spent a lot of time in my recent 
> life on this stuff and I'm ready to battle for some of it :) And to be 
> mistaken, ignorant, or convinced of other paths for some other parts of it. 
> I'll only say, every time I go from working with the gradle build back to 
> ant+ivy+mvn, it feels like a big backslide.
>
> I'm thinking maybe in September/October? And only on master, hopefully living 
> side by side with ant+ivy+mvn, but the goal would be for that period to be 
> brief. They can't live in complete harmony - someone has to own the 
> dependency view of the world for example, the one that actually gets 
> committed (license, checksums, etc). Otherwise, I've done my best to do this 
> in a way that doesn't break the current build. Will need to inspect that 
> closer before landing though.
>
> This is just another heads up. Once we are in a main branch, I'm hoping a few 
> of you will either have to jump in and help this land or we will have to pull 
> it back out I think. Be prepared :)
>
> --
> - Mark
>
> http://about.me/markrmiller

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



[jira] [Commented] (LUCENE-8648) TestIndexWriterDelete.testUpdatesOnDiskFull hangs indefinitely (?)

2019-08-15 Thread Dawid Weiss (JIRA)


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

Dawid Weiss commented on LUCENE-8648:
-

Well, that's strange. I can reproduce it with full reliability on different 
machines. I can't work on it now though. Let's leave the issue open.

> TestIndexWriterDelete.testUpdatesOnDiskFull hangs indefinitely (?)
> --
>
> Key: LUCENE-8648
> URL: https://issues.apache.org/jira/browse/LUCENE-8648
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master (9.0)
>Reporter: Dawid Weiss
>Priority: Major
>
> I didn't have time to investigate but this seed hangs for me on this test:
> -Dtests.seed=A586F88535C84727



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 182 - Still unstable

2019-08-15 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/182/

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest.testSimple

Error Message:
Waiting for collection testSimple2 Timeout waiting to see state for 
collection=testSimple2 
:DocCollection(testSimple2//collections/testSimple2/state.json/24)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{  
 "range":"8000-",   "state":"active",   "replicas":{
 "core_node3":{   
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node3/data/",
   "base_url":"https://127.0.0.1:33261/solr;,   
"node_name":"127.0.0.1:33261_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node3/data/tlog",
   "core":"testSimple2_shard1_replica_n1",   
"shared_storage":"true",   "state":"down"}, "core_node5":{  
 
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node5/data/",
   "base_url":"https://127.0.0.1:46348/solr;,   
"node_name":"127.0.0.1:46348_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node5/data/tlog",
   "core":"testSimple2_shard1_replica_n2",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}}}, "shard2":{   "range":"0-7fff",   
"state":"active",   "replicas":{ "core_node7":{   
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node7/data/",
   "base_url":"https://127.0.0.1:33261/solr;,   
"node_name":"127.0.0.1:33261_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node7/data/tlog",
   "core":"testSimple2_shard2_replica_n4",   
"shared_storage":"true",   "state":"down"}, "core_node8":{  
 
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node8/data/",
   "base_url":"https://127.0.0.1:46348/solr;,   
"node_name":"127.0.0.1:46348_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node8/data/tlog",
   "core":"testSimple2_shard2_replica_n6",   
"shared_storage":"true",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"2",   "autoAddReplicas":"true",   "nrtReplicas":"2",   
"tlogReplicas":"0"} Live Nodes: [127.0.0.1:44135_solr, 127.0.0.1:46348_solr] 
Last available state: 
DocCollection(testSimple2//collections/testSimple2/state.json/24)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{  
 "range":"8000-",   "state":"active",   "replicas":{
 "core_node3":{   
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node3/data/",
   "base_url":"https://127.0.0.1:33261/solr;,   
"node_name":"127.0.0.1:33261_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node3/data/tlog",
   "core":"testSimple2_shard1_replica_n1",   
"shared_storage":"true",   "state":"down"}, "core_node5":{  
 
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node5/data/",
   "base_url":"https://127.0.0.1:46348/solr;,   
"node_name":"127.0.0.1:46348_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node5/data/tlog",
   "core":"testSimple2_shard1_replica_n2",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}}}, "shard2":{   "range":"0-7fff",   
"state":"active",   "replicas":{ "core_node7":{   
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node7/data/",
   "base_url":"https://127.0.0.1:33261/solr;,   
"node_name":"127.0.0.1:33261_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node7/data/tlog",
   "core":"testSimple2_shard2_replica_n4",   
"shared_storage":"true",   "state":"down"}, "core_node8":{  
 

[JENKINS] Lucene-Solr-Tests-master - Build # 3566 - Unstable

2019-08-15 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3566/

2 tests failed.
FAILED:  org.apache.solr.cloud.SystemCollectionCompatTest.testBackCompat

Error Message:
re-indexing warning not found

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


FAILED:  org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom

Error Message:
Error from server at 
http://127.0.0.1:42409/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection:
 Expected mime type application/octet-stream but got text/html.   
 
Error 500 Server Error  HTTP ERROR 500 
Problem accessing 

[jira] [Commented] (SOLR-13696) DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest failures due commitWithin/openSearcher delays

2019-08-15 Thread Gus Heck (JIRA)


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

Gus Heck commented on SOLR-13696:
-

Thx for the write up and suggestions. I will look as soon as I can, but this 
weekend is not looking likely due to weekend commitments & visiting family. 
Possibly by Monday or Tuesday I'll just declare a solr day (or half day) for 
myself, there are several things I want to look at that keep getting pushed. 
Routed Alias tests in general do seem to run up against the timing sorts of 
issues frequently. I've had no end of trouble with various bits of code that 
need to wait for a collection to be available, or a zookeeper related change to 
be visible (or both) etc. The existing wait methods for that stuff all seem to 
fail some small fraction of a percent of the time... for example SOLR-13059... 
which is among the things on my list to go back and check the status of and see 
if it's improved or if anything I've learned since makes the solution more 
obvious...

> DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest 
> failures due commitWithin/openSearcher delays
> 
>
> Key: SOLR-13696
> URL: https://issues.apache.org/jira/browse/SOLR-13696
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Gus Heck
>Priority: Major
> Attachments: thetaphi_Lucene-Solr-8.x-MacOSX_272.log.txt
>
>
> Recent jenkins failure...
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/272/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
> {noformat}
> Stack Trace:
> java.lang.AssertionError: expected:<16> but was:<15>
> at 
> __randomizedtesting.SeedInfo.seed([DB6DC28D5560B1D2:E295833E1541FDB9]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:677
> )
> at 
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> Digging into the logs, the problem appears to be in the way the test 
> verifies/assumes docs have been committed.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Assigned] (SOLR-13059) TimeRoutedAliasUpdateProcessorTest rarely fails to see collection just created

2019-08-15 Thread Gus Heck (JIRA)


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

Gus Heck reassigned SOLR-13059:
---

Assignee: Gus Heck

> TimeRoutedAliasUpdateProcessorTest rarely fails to see collection just created
> --
>
> Key: SOLR-13059
> URL: https://issues.apache.org/jira/browse/SOLR-13059
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 8.0
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
>
> This issue is for tracking down and fixing this stack trace observed during 
> SOLR-13051:
> {code:java}
> [junit4] ERROR 11.2s | TimeRoutedAliasUpdateProcessorTest.testSliceRouting <<<
> [junit4] > Throwable #1: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException: 
> Error from server at http://127.0.0.1:32891/solr: no core retrieved for 
> testSliceRouting
> [junit4] > at 
> __randomizedtesting.SeedInfo.seed([D9B32625DD304967:E823AAC97966B64E]:0)
> [junit4] > at 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:829)
> [junit4] > at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:620)
> [junit4] > at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> [junit4] > at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> [junit4] > at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:484)
> [junit4] > at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414)
> [junit4] > at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1110){code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-12.0.1) - Build # 5293 - Failure!

2019-08-15 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5293/
Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testCatTime

Error Message:
took over 10 seconds after collection creation to update aliases

Stack Trace:
java.lang.AssertionError: took over 10 seconds after collection creation to 
update aliases
at 
__randomizedtesting.SeedInfo.seed([6E89C34E7B1D0825:69828C4D44EE59CD]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.update.processor.RoutedAliasUpdateProcessorTest.waitColAndAlias(RoutedAliasUpdateProcessorTest.java:77)
at 
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testCatTime(DimensionalRoutedAliasUpdateProcessorTest.java:480)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)




Build Log:
[...truncated 2043 lines...]
   [junit4] JVM J1: stderr was not empty, see: 

[jira] [Commented] (LUCENE-8648) TestIndexWriterDelete.testUpdatesOnDiskFull hangs indefinitely (?)

2019-08-15 Thread Chongchen Chen (JIRA)


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

Chongchen Chen commented on LUCENE-8648:


I checkout the version before 2e468abecc. But still cannot reproduce. :(

> TestIndexWriterDelete.testUpdatesOnDiskFull hangs indefinitely (?)
> --
>
> Key: LUCENE-8648
> URL: https://issues.apache.org/jira/browse/LUCENE-8648
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master (9.0)
>Reporter: Dawid Weiss
>Priority: Major
>
> I didn't have time to investigate but this seed hangs for me on this test:
> -Dtests.seed=A586F88535C84727



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

2019-08-15 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1931/

No tests ran.

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

[jira] [Updated] (SOLR-13701) JWTAuthPlugin calls authenticationFailure (which calls HttpServletResponsesendError) before updating metrics - breaks tests

2019-08-15 Thread Hoss Man (JIRA)


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

Hoss Man updated SOLR-13701:

Attachment: SOLR-13701.patch
Status: Open  (was: Open)


Attaching patch that addressess this.  

I also updates the existing code paths that propogate the request via 
{{filterChain.doFilter(...)}} to ensure that the associated metrics ( 
{{numPassThrough}} and/or {{numAuthenticated}} ) are updated *before* 
{{filterChain.doFilter(...)}} is called, so that they are correct even if a 
subsequent filter (or ultimately, the SolrCore/RequestHandler) encounters an 
error or otherwise rejects the request.

[~janhoy] - would appreciate if you could review.

> JWTAuthPlugin calls authenticationFailure (which calls 
> HttpServletResponsesendError) before updating metrics - breaks tests
> ---
>
> Key: SOLR-13701
> URL: https://issues.apache.org/jira/browse/SOLR-13701
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13701.patch
>
>
> The way JWTAuthPlugin is currently implemented, any failures are sent to the 
> remote client (via {{authenticationFailure(...)}} which calls 
> {{HttpServletResponsesendError(...)}}) *before* 
> {{JWTAuthPlugin.doAuthenticate(...)}} has a chance to update it's metrics 
> (like {{numErrors}} and {{numWrongCredentials}})
> This causes a race condition in tests where test threads can:
>  * see an error response/Exception before the server thread has updated 
> metrics (like {{numErrors}} and {{numWrongCredentials}})
>  * call white box methods like 
> {{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} to assert expected 
> metrics
> ...all before the server thread has ever gotten around to being able to 
> update the metrics in question.
> {{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} currently has some 
> {{"First metrics count assert failed, pausing 2s before re-attempt"}} 
> evidently to try and work around this bug, but it's still no garuntee that 
> the server thread will be scheduled before the retry happens.
> We can/should just fix JWTAuthPlugin to ensure the metrics are updated before 
> {{authenticationFailure(...)}} is called, and then remove the "pausing 2s 
> before re-attempt" logic from {{SolrCloudAuthTestCase}} - between this bug 
> fix, and the existing work around for SOLR-13464, there should be absolutely 
> no reason to "retry" reading hte metrics.
> (NOTE: BasicAuthPlugin has a similar {{authenticationFailure(...)}} method 
> that also calls {{HttpServletResponse.sendError(...)}} - but it already 
> (correctly) updates the error/failure metrics *before* calling that method.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Created] (SOLR-13701) JWTAuthPlugin calls authenticationFailure (which calls HttpServletResponsesendError) before updating metrics - breaks tests

2019-08-15 Thread Hoss Man (JIRA)
Hoss Man created SOLR-13701:
---

 Summary: JWTAuthPlugin calls authenticationFailure (which calls 
HttpServletResponsesendError) before updating metrics - breaks tests
 Key: SOLR-13701
 URL: https://issues.apache.org/jira/browse/SOLR-13701
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man


The way JWTAuthPlugin is currently implemented, any failures are sent to the 
remote client (via {{authenticationFailure(...)}} which calls 
{{HttpServletResponsesendError(...)}}) *before* 
{{JWTAuthPlugin.doAuthenticate(...)}} has a chance to update it's metrics (like 
{{numErrors}} and {{numWrongCredentials}})

This causes a race condition in tests where test threads can:
 * see an error response/Exception before the server thread has updated metrics 
(like {{numErrors}} and {{numWrongCredentials}})
 * call white box methods like 
{{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} to assert expected 
metrics

...all before the server thread has ever gotten around to being able to update 
the metrics in question.

{{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} currently has some 
{{"First metrics count assert failed, pausing 2s before re-attempt"}} evidently 
to try and work around this bug, but it's still no garuntee that the server 
thread will be scheduled before the retry happens.

We can/should just fix JWTAuthPlugin to ensure the metrics are updated before 
{{authenticationFailure(...)}} is called, and then remove the "pausing 2s 
before re-attempt" logic from {{SolrCloudAuthTestCase}} - between this bug fix, 
and the existing work around for SOLR-13464, there should be absolutely no 
reason to "retry" reading hte metrics.

(NOTE: BasicAuthPlugin has a similar {{authenticationFailure(...)}} method that 
also calls {{HttpServletResponse.sendError(...)}} - but it already (correctly) 
updates the error/failure metrics *before* calling that method.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Updated] (SOLR-13700) Race condition in initializing metrics for new security plugins when security.json is modified

2019-08-15 Thread Hoss Man (JIRA)


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

Hoss Man updated SOLR-13700:

  Assignee: Hoss Man
Attachment: SOLR-13700.patch
Status: Open  (was: Open)


Attaching a patch to address this, one nocommit regarding something that makes 
no sense to me...

[~ab] - can you please review and sanity check:

# that my understanding is correct, and that it's "safe" (and more correct) for 
the "old" and "new" instances of these plugins to be using the same Metric 
instances before the "new" plugin replaces the old one
# the nocommit comments -- unless i'm missing something 
{{reloadSecurityProperties()}} has no business calling 
{{pkiAuthenticationPlugin.initializeMetrics(...)}}, because 
{{pkiAuthenticationPlugin}} can never change as a result of reloading the 
security.json ... so {{pkiAuthenticationPlugin.initializeMetrics(...)}} should 
be called exactly once (and only once) for it's entire lifecycle ... ideally in 
{{CoreContainer.load()}} immediately after calling {{pkiAuthenticationPlugin = 
new PKIAuthenticationPlugin...)}}



> Race condition in initializing metrics for new security plugins when 
> security.json is modified
> --
>
> Key: SOLR-13700
> URL: https://issues.apache.org/jira/browse/SOLR-13700
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13700.patch
>
>
> When new security plugins are initialized due to remote API requetss, there 
> is a delay between "registering" the new plugins for use in methods like 
> {{initializeAuthenticationPlugin()}} (by assigning them to CoreContainer's 
> volatile {{this.authenticationPlugin}} variable) and when the 
> {{initializeMetrics(..)}} method is called on these plugins, so that they 
> continue to use the existing {{Metric}} instances as the plugins they are 
> replacing.
> Because these security plugins maintain local refrences to these Metrics (and 
> don't "get" them from the MetricRegisty everytime they need to {{inc()}} 
> them) this means that there is short race condition situation such that 
> during the window of time after a new plugin instance is put into use, but 
> before  {{initializeMetrics(..)}} is called on them, at these plugins are 
> responsible for accepting/rejecting requests, and decisions in {{Metric}} 
> instances that are not registered and subsequently get thrown away (and GCed) 
> once the CoreContainer gets around to calling {{initializeMetrics(..)}} (and 
> the plugin starts using the pre-existing metric objects)
> 
> This has some noticible impacts on auth tests on CPU constrained jenkins 
> machines (even after putting in place SOLR-13464 work arounds) that make 
> assertions about the metrics recorded.
> In real world situations, the impact of this bug on users is minor: for a few 
> micro/milli-seconds, requests may come in w/o being counted in the auth 
> metrics -- which may also result in descrepencies between the auth metrics 
> totals and the overall request metrics.  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Created] (SOLR-13700) Race condition in initializing metrics for new security plugins when security.json is modified

2019-08-15 Thread Hoss Man (JIRA)
Hoss Man created SOLR-13700:
---

 Summary: Race condition in initializing metrics for new security 
plugins when security.json is modified
 Key: SOLR-13700
 URL: https://issues.apache.org/jira/browse/SOLR-13700
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


When new security plugins are initialized due to remote API requetss, there is 
a delay between "registering" the new plugins for use in methods like 
{{initializeAuthenticationPlugin()}} (by assigning them to CoreContainer's 
volatile {{this.authenticationPlugin}} variable) and when the 
{{initializeMetrics(..)}} method is called on these plugins, so that they 
continue to use the existing {{Metric}} instances as the plugins they are 
replacing.

Because these security plugins maintain local refrences to these Metrics (and 
don't "get" them from the MetricRegisty everytime they need to {{inc()}} them) 
this means that there is short race condition situation such that during the 
window of time after a new plugin instance is put into use, but before  
{{initializeMetrics(..)}} is called on them, at these plugins are responsible 
for accepting/rejecting requests, and decisions in {{Metric}} instances that 
are not registered and subsequently get thrown away (and GCed) once the 
CoreContainer gets around to calling {{initializeMetrics(..)}} (and the plugin 
starts using the pre-existing metric objects)



This has some noticible impacts on auth tests on CPU constrained jenkins 
machines (even after putting in place SOLR-13464 work arounds) that make 
assertions about the metrics recorded.

In real world situations, the impact of this bug on users is minor: for a few 
micro/milli-seconds, requests may come in w/o being counted in the auth metrics 
-- which may also result in descrepencies between the auth metrics totals and 
the overall request metrics.  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-11.0.3) - Build # 402 - Still Unstable!

2019-08-15 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/402/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

5 tests failed.
FAILED:  
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud

Error Message:
IOException occurred when talking to server at: https://127.0.0.1:57981/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occurred when 
talking to server at: https://127.0.0.1:57981/solr
at 
__randomizedtesting.SeedInfo.seed([77EED741CBFE36A9:A6E925C46FF1BD9B]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:670)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.createAndTest(LegacyCloudClusterPropTest.java:87)
at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud(LegacyCloudClusterPropTest.java:79)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk1.8.0_201) - Build # 1024 - Unstable!

2019-08-15 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/1024/
Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom

Error Message:
Error from server at 
http://127.0.0.1:35431/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection:
 Error from server at null: Expected mime type application/octet-stream but got 
text/html.Error 500 Server Error 
 HTTP ERROR 500 Problem accessing 
/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection_shard1_replica_n1/select.
 Reason: Server ErrorCaused 
by:java.lang.AssertionError  at 
java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1849)  at 
java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2014)  at 
java.util.HashMap.putVal(HashMap.java:638)  at 
java.util.HashMap.put(HashMap.java:612)  at 
org.apache.solr.search.LRUCache.put(LRUCache.java:196)  at 
org.apache.solr.search.SolrCacheHolder.put(SolrCacheHolder.java:46)  at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449)
  at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568)  at 
org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1484)
  at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:398)
  at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:305)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2592)  at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:780)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:165)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:703)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) 
 at org.eclipse.jetty.server.Server.handle(Server.java:505)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)  at 
org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:311)  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917)
  at java.lang.Thread.run(Thread.java:748)  http://eclipse.org/jetty;>Powered by Jetty:// 9.4.19.v20190610  
  

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at 
http://127.0.0.1:35431/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection:
 Error from server at null: Expected mime type application/octet-stream but got 
text/html. 


Error 500 Server Error

HTTP ERROR 500
Problem accessing 
/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection_shard1_replica_n1/select.
 Reason:
Server ErrorCaused by:java.lang.AssertionError
at java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1849)
at java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2014)
at java.util.HashMap.putVal(HashMap.java:638)
at java.util.HashMap.put(HashMap.java:612)
at org.apache.solr.search.LRUCache.put(LRUCache.java:196)
at org.apache.solr.search.SolrCacheHolder.put(SolrCacheHolder.java:46)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449)
at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568)
at 

Re: The Gradle train.

2019-08-15 Thread Erick Erickson
Go for it! I’ve been amazed by the effort you’ve put in it, and it’ll be good 
for some of the load to be distributed.

Of course I’ll need to learn new tricks (something about old dogs in here)…..

Erick

> On Aug 15, 2019, at 5:23 PM, Mark Miller  wrote:
> 
> https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the 
> lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> 
> Okay, we are at the point where either this thing lands soon and gains some 
> contributors to help finish or it  overwhelms me and crashes & burns. That 
> almost sounds negative, but it was actually the plan so far and I'm pretty 
> excited after all this time invested. I need to punt this over to the 
> community though - the final implications and ramifications of moving fully 
> to gradle are just too big for me individually regardless of the time frame.
> 
> I've done about 95%+ of what I wanted to do before trying to land something - 
> a few more hoops to jump around. We pull in more deps than we should right 
> now, I'll deal with that shortly, and mvn publishing needs work (mostly 
> around solr-server, but dist and publishing both prob need edge work at 
> least). Those are the main things on my mind. There are probably a ton of 
> other little things, but I'm thinking those that are important will rise up 
> quickly and the rest can be handled over time.
> 
> This will be a large change. Some things will still take time to get up to 
> par with what we have now. Many things will need to be sorted out (jenkins, 
> releases, smoke tester type things, docs, etc).
> 
> I've also made all the decisions and trade-offs and what not. I'm pretty 
> happy about that, but I'm sure some will want to discuss and debate some 
> choices once things are in their face. I've spent a lot of time in my recent 
> life on this stuff and I'm ready to battle for some of it :) And to be 
> mistaken, ignorant, or convinced of other paths for some other parts of it. 
> I'll only say, every time I go from working with the gradle build back to 
> ant+ivy+mvn, it feels like a big backslide.
> 
> I'm thinking maybe in September/October? And only on master, hopefully living 
> side by side with ant+ivy+mvn, but the goal would be for that period to be 
> brief. They can't live in complete harmony - someone has to own the 
> dependency view of the world for example, the one that actually gets 
> committed (license, checksums, etc). Otherwise, I've done my best to do this 
> in a way that doesn't break the current build. Will need to inspect that 
> closer before landing though.
> 
> This is just another heads up. Once we are in a main branch, I'm hoping a few 
> of you will either have to jump in and help this land or we will have to pull 
> it back out I think. Be prepared :)
> 
> -- 
> - Mark
> 
> http://about.me/markrmiller


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



The Gradle train.

2019-08-15 Thread Mark Miller
https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the
lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

Okay, we are at the point where either this thing lands soon and gains some
contributors to help finish or it  overwhelms me and crashes & burns. That
almost sounds negative, but it was actually the plan so far and I'm pretty
excited after all this time invested. I need to punt this over to the
community though - the final implications and ramifications of moving fully
to gradle are just too big for me individually regardless of the time frame.

I've done about 95%+ of what I wanted to do before trying to land something
- a few more hoops to jump around. We pull in more deps than we should
right now, I'll deal with that shortly, and mvn publishing needs work
(mostly around solr-server, but dist and publishing both prob need edge
work at least). Those are the main things on my mind. There are probably a
ton of other little things, but I'm thinking those that are important will
rise up quickly and the rest can be handled over time.

This will be a large change. Some things will still take time to get up to
par with what we have now. Many things will need to be sorted out (jenkins,
releases, smoke tester type things, docs, etc).

I've also made all the decisions and trade-offs and what not. I'm pretty
happy about that, but I'm sure some will want to discuss and debate some
choices once things are in their face. I've spent a lot of time in my
recent life on this stuff and I'm ready to battle for some of it :) And to
be mistaken, ignorant, or convinced of other paths for some other parts of
it. I'll only say, every time I go from working with the gradle build back
to ant+ivy+mvn, it feels like a big backslide.

I'm thinking maybe in September/October? And only on master, hopefully
living side by side with ant+ivy+mvn, but the goal would be for that period
to be brief. They can't live in complete harmony - someone has to own the
dependency view of the world for example, the one that actually gets
committed (license, checksums, etc). Otherwise, I've done my best to do
this in a way that doesn't break the current build. Will need to inspect
that closer before landing though.

This is just another heads up. Once we are in a main branch, I'm hoping a
few of you will either have to jump in and help this land or we will have
to pull it back out I think. Be prepared :)

-- 
- Mark

http://about.me/markrmiller


[jira] [Assigned] (SOLR-13699) maxChars no longer working as designed on CopyField

2019-08-15 Thread Erick Erickson (JIRA)


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

Erick Erickson reassigned SOLR-13699:
-

Assignee: Erick Erickson

> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Assignee: Erick Erickson
>Priority: Major
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. I am currently not 
> sure if this issue is limited to indexing via SolrJ or if it applies to 
> documents indexed via any means



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

2019-08-15 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13452:


Commit 81132db7ca28faa2cf09b94c27686e1139c88a9e in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=81132db ]

SOLR-13452: Remove almost all transitive dep disables. Will cleanup the extra 
deps that come in now later.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

2019-08-15 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13452:


Commit 23d06dadb206f8d5b5fe95d352eec77233c51647 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=23d06da ]

SOLR-13452: Start including more than the default artifacts in solr-server 
module dist packages and handle start.jar.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField

2019-08-15 Thread Chris Troullis (JIRA)


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

Chris Troullis commented on SOLR-13699:
---

[~erickerickson] So after looking through the CopyFieldTest unit tests, I found 
that we are already testing the maxChars functionality via the 
testCopyFieldFunctionality() test, and the maxChars functionality is working 
properly when the test runs! 

After further digging it seems that the issue only occurs when docs are indexed 
in Binary format, using the JavaBinCodec, as this is where there change was 
made to read strings as a ByteArrayUtf8CharSequence instead of a string. It 
appears that the test framework indexes docs in XML format, which does not use 
the JavaBinCodec, so the fields are read as strings, and the maxChars works as 
designed. 

So, in other words, it's still an issue, but looks like it only effects docs 
indexed in Binary format. Since it looks like the test framework only supports 
indexing in XML format (although I didn't look that hard), do you have any 
suggestions on how to properly unit test this?

> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Priority: Major
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. I am currently not 
> sure if this issue is limited to indexing via SolrJ or if it applies to 
> documents indexed via any means



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



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

2019-08-15 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/268/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
Failed while waiting for active collection Timeout waiting to see state for 
collection=testcollection :null Live Nodes: [127.0.0.1:34780_solr, 
127.0.0.1:40043_solr, 127.0.0.1:45871_solr, 127.0.0.1:46441_solr, 
127.0.0.1:49951_solr] Last available state: null

Stack Trace:
java.lang.RuntimeException: Failed while waiting for active collection
Timeout waiting to see state for collection=testcollection :null
Live Nodes: [127.0.0.1:34780_solr, 127.0.0.1:40043_solr, 127.0.0.1:45871_solr, 
127.0.0.1:46441_solr, 127.0.0.1:49951_solr]
Last available state: null
at 
__randomizedtesting.SeedInfo.seed([7899523D88C883F4:DB63FC980F206951]:0)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.waitForActiveCollection(MiniSolrCloudCluster.java:758)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.waitForActiveCollection(MiniSolrCloudCluster.java:764)
at 
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.createCollection(TestCollectionsAPIViaSolrCloudCluster.java:97)
at 
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:173)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 

[jira] [Updated] (SOLR-13699) maxChars no longer working as designed on CopyField

2019-08-15 Thread Chris Troullis (JIRA)


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

Chris Troullis updated SOLR-13699:
--
Description: 
We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
property on a copy field is no longer functioning as designed, while indexing 
via SolrJ. Per the most recent documentation it looks like there have been no 
intentional changes as to the functionality of this property, so I assume this 
is a bug.
  
 In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
DocumentBuilder where the maxChar limit is applied, it first checks if the 
value is instanceof String. As of SOLR-12992, string values are now coming in 
as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String check, 
and the maxChar truncation is not being applied. I am currently not sure if 
this issue is limited to indexing via SolrJ or if it applies to documents 
indexed via any means

  was:
We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
property on a copy field is no longer functioning as designed, while indexing 
via SolrJ. Per the most recent documentation it looks like there have been no 
intentional changes as to the functionality of this property, so I assume this 
is a bug.
  
 In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
DocumentBuilder where the maxChar limit is applied, it first checks if the 
value is instanceof String. As of SOLR-12992, string values are now coming in 
as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String check, 
and the maxChar truncation is not being applied. 


> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Priority: Major
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. I am currently not 
> sure if this issue is limited to indexing via SolrJ or if it applies to 
> documents indexed via any means



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Updated] (SOLR-13699) maxChars no longer working as designed on CopyField

2019-08-15 Thread Chris Troullis (JIRA)


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

Chris Troullis updated SOLR-13699:
--
Description: 
We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
property on a copy field is no longer functioning as designed, while indexing 
via SolrJ. Per the most recent documentation it looks like there have been no 
intentional changes as to the functionality of this property, so I assume this 
is a bug.
  
 In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
DocumentBuilder where the maxChar limit is applied, it first checks if the 
value is instanceof String. As of SOLR-12992, string values are now coming in 
as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String check, 
and the maxChar truncation is not being applied. 

  was:
We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
property on a copy field is no longer functioning as designed. Per the most 
recent documentation it looks like there have been no intentional changes as to 
the functionality of this property, so I assume this is a bug.
 
In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
DocumentBuilder where the maxChar limit is applied, it first checks if the 
value is instanceof String. As of SOLR-12992, string values are now coming in 
as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String check, 
and the maxChar truncation is not being applied. 


> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Priority: Major
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField

2019-08-15 Thread Chris Troullis (JIRA)


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

Chris Troullis commented on SOLR-13699:
---

Created after discussion with [~erickerickson] on the mailing list. I think I 
have a fix working, just finishing testing and writing a unit test, then I will 
attach my patch.

> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Priority: Major
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed. Per the most 
> recent documentation it looks like there have been no intentional changes as 
> to the functionality of this property, so I assume this is a bug.
>  
> In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Created] (SOLR-13699) maxChars no longer working as designed on CopyField

2019-08-15 Thread Chris Troullis (JIRA)
Chris Troullis created SOLR-13699:
-

 Summary: maxChars no longer working as designed on CopyField
 Key: SOLR-13699
 URL: https://issues.apache.org/jira/browse/SOLR-13699
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.1.1, 8.2, 8.1, 8.0, 7.7.2, 7.7.1, 7.7, 8.0.1, 7.7.3, 
8.1.2
Reporter: Chris Troullis


We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
property on a copy field is no longer functioning as designed. Per the most 
recent documentation it looks like there have been no intentional changes as to 
the functionality of this property, so I assume this is a bug.
 
In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
DocumentBuilder where the maxChar limit is applied, it first checks if the 
value is instanceof String. As of SOLR-12992, string values are now coming in 
as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String check, 
and the maxChar truncation is not being applied. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

2019-08-15 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1422/

No tests ran.

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

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

package:

-unpack-solr-tgz:

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

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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


[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

2019-08-15 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13452:


Commit ba6f6bb285e33c4b1ea9b071a7eba97706a59241 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ba6f6bb ]

SOLR-13452: Remove more warnings from more modules.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

2019-08-15 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13452:


Commit 7208a46af27cbb113f7c03445c0a115b3f33785b in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7208a46 ]

SOLR-13452: More work on removing compile warnings.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

2019-08-15 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13452:


Commit 47124b63b02cb7a1f4ce14064b68d098ad9a74b9 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=47124b6 ]

SOLR-13452: Work on test run output improvements and removing basic compiler 
warnings (so they don't clutter up the build output and we don't just hide them)


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

2019-08-15 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13452:


Commit 4914e637d009692a0fa9b3fde6186248831781cd in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4914e63 ]

SOLR-13452: Cleanup silly ant output about overriding javadoc task.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

2019-08-15 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13452:


Commit 863594ae31b7d98ed891322193725029eb173694 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=863594a ]

SOLR-13452: Fix a couple of bugs in the license checker.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

2019-08-15 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-13452:


[~tomoko], ping - probably not a bad time to start looking at support for 
intellij? I think from that perspective things are in fairly good shape.

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

2019-08-15 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-13452:


[~ctargett], one thing still left is the doc module!

I stubbed it out, but if you have any spare cycles, would love to take you up 
on the help offer. I can pitch in on the gradle side, but I'm pretty out of the 
know on the doc stuff and this project is already swallowing me up. Either way, 
I'll look to tackle it eventually.

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Updated] (SOLR-13698) Querying suggester with alias fails

2019-08-15 Thread Eileen Mosch (JIRA)


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

Eileen Mosch updated SOLR-13698:

Summary: Querying suggester with alias fails  (was: Calling Suggester via 
Alias fails)

> Querying suggester with alias fails
> ---
>
> Key: SOLR-13698
> URL: https://issues.apache.org/jira/browse/SOLR-13698
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 8.2, 8.1.1
>Reporter: Eileen Mosch
>Priority: Major
> Attachments: http_suggester_stacktrace.json
>
>
> There's a problem using a multi-collection alias in combination with 
> suggester request. We used version 7.3.1 and had no problems, after upgrading 
> to version 8.x exceptions are thrown.
> *Details*
> I created an alias called „WORLD“ pointing to six collections.
> {code:java}
> // aliases.json
> {"collection":{
> "AT":"AT.test",
> "BE":"BE.test",
> "DE":"DE.test",
> "FR":"FR.test",
> "LU":"LU.test",
> "NL":"NL.test",
> "WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
> }
> {code}
> If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the 
> error message: „No live SolrServers available to handle this 
> request:[http://[myIP]:8983/solr/WORLD“.
> If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while 
> waiting response from server at: 
> [http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full 
> stacktrace attached). The collection name within the error messages differs 
> (AT.test... or BE.test... ) but the error information is still the same.
> {code:java}
> // HTTP API Suggester Call
> http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
> {code}
>  If I use single-collection Aliases (e.g. "AT") everything works fine.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[JENKINS] Lucene-Solr-Tests-8.x - Build # 415 - Still Unstable

2019-08-15 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/415/

1 tests failed.
FAILED:  org.apache.solr.handler.TestContainerReqHandler.testRuntimeLib

Error Message:
attempt: 9 Mismatch for value : 'requestHandler' in response {   
"responseHeader":{ "status":0, "QTime":0},   "metadata":{"version":3},  
 "runtimeLib":[{   "name":"foo",   
"url":"http://localhost:36368/jar3.jar;,   
"60ec88c2a2e9b409f7afc309273383810a0d07a078b482434eda9674f7e25b8adafa8a67c9913c996cbfb78a7f6ad2b9db26dbd4fe0ca4068f248d5db563f922":"60ec88c2a2e9b409f7afc309273383810a0d07a078b482434eda9674f7e25b8adafa8a67c9913c996cbfb78a7f6ad2b9db26dbd4fe0ca4068f248d5db563f922"}],
   "requestHandler":[{"bar":"org.apache.solr.core.RuntimeLibReqHandler"}]}

Stack Trace:
java.lang.AssertionError: attempt: 9 Mismatch for value : 'requestHandler' in 
response {
  "responseHeader":{
"status":0,
"QTime":0},
  "metadata":{"version":3},
  "runtimeLib":[{
  "name":"foo",
  "url":"http://localhost:36368/jar3.jar;,
  
"60ec88c2a2e9b409f7afc309273383810a0d07a078b482434eda9674f7e25b8adafa8a67c9913c996cbfb78a7f6ad2b9db26dbd4fe0ca4068f248d5db563f922":"60ec88c2a2e9b409f7afc309273383810a0d07a078b482434eda9674f7e25b8adafa8a67c9913c996cbfb78a7f6ad2b9db26dbd4fe0ca4068f248d5db563f922"}],
  "requestHandler":[{"bar":"org.apache.solr.core.RuntimeLibReqHandler"}]}
at 
__randomizedtesting.SeedInfo.seed([C05E7BAA7922060F:F3F9EFFE8AB2F7BB]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.handler.TestContainerReqHandler.assertResponseValues(TestContainerReqHandler.java:106)
at 
org.apache.solr.handler.TestContainerReqHandler.testRuntimeLib(TestContainerReqHandler.java:222)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[GitHub] [lucene-solr] uschindler commented on issue #758: LUCENE-8833: Add a #load() method to IndexInput to allow preloading file content into physical memory

2019-08-15 Thread GitBox
uschindler commented on issue #758: LUCENE-8833: Add a #load() method to 
IndexInput to allow preloading file content into physical memory
URL: https://github.com/apache/lucene-solr/pull/758#issuecomment-521674174
 
 
   > I am still in review (have to feed my brain with all details, reading C++ 
source code of JVM and so on).
   > 
   > Because of Adrien's comment you changed the slice building to also take 
the start position into account, so the slice method returns a byte buffer that 
is really only a view and a call to load() would not read data of the whole CFS 
file.
   > 
   > As you changed this method to take care of the start offset/position, 
please fix the javadocs comment:
   > 
   > ```
   >   /** Returns a sliced view from a set of already-existing buffers: 
   >*  the last buffer's limit() will be correct, but
   >*  you must deal with offset separately (the first buffer will not be 
adjusted) */
   >   private ByteBuffer[] buildSlice(ByteBuffer[] buffers, long offset, long 
length) {
   > ```
   
   I am not fully sure how the comment would look like. Currently it only fixes 
the start offset for single-buffer indexinputs.
   
   The code is horrible here, I still don't fully understand the code 
difference for single and multi buffer indexinputs. IMHO, we should change the 
code and make buildSlice always fix position() and limit() and build a buffer 
slice for the first and last buffer. How it's done currently is hard to 
understand. I cannot make any guarantees that the code behaves correctly after 
this patch and I am not sure if testing of all cases is fine. Maybe only apply 
to master first and let Jenkins test it.


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


With regards,
Apache Git Services

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



[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-13-rc) - Build # 24549 - Unstable!

2019-08-15 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24549/
Java: 64bit/jdk-13-rc -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestLockTree.testLocks

Error Message:
expected:<2> but was:<3>

Stack Trace:
java.lang.AssertionError: expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([698CDCF5866383ED:1046A60C8EB36806]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at org.apache.solr.cloud.TestLockTree.testLocks(TestLockTree.java:99)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:830)




Build Log:
[...truncated 2039 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J2-20190815_123125_9439732664721030066917.syserr
   [junit4] >>> JVM 

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

2019-08-15 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/414/

1 tests failed.
FAILED:  
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testCatTime

Error Message:
took over 10 seconds after collection creation to update aliases

Stack Trace:
java.lang.AssertionError: took over 10 seconds after collection creation to 
update aliases
at 
__randomizedtesting.SeedInfo.seed([A49B1CEEC4DB6F1A:A39053EDFB283EF2]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.update.processor.RoutedAliasUpdateProcessorTest.waitColAndAlias(RoutedAliasUpdateProcessorTest.java:77)
at 
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testCatTime(DimensionalRoutedAliasUpdateProcessorTest.java:480)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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)




Build Log:
[...truncated 13462 lines...]
   [junit4] Suite: 
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest
  

[jira] [Commented] (SOLR-12315) the number of docs in each group depends on rows

2019-08-15 Thread Chongchen Chen (JIRA)


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

Chongchen Chen commented on SOLR-12315:
---

I tried to reproduce your problem, but failed. here's my unit test code.
can you give me your files in solr.home .
{code:java}
package org.apache.solr.cloud;

import java.util.Arrays;
import java.util.List;
import java.util.Random;
import java.util.stream.Stream;

import org.apache.solr.client.solrj.SolrQuery;
import org.apache.solr.client.solrj.impl.CloudSolrClient;
import org.apache.solr.client.solrj.request.CollectionAdminRequest;
import org.apache.solr.client.solrj.request.UpdateRequest;
import org.apache.solr.client.solrj.response.Group;
import org.apache.solr.client.solrj.response.QueryResponse;
import org.apache.solr.common.SolrInputDocument;
import org.junit.BeforeClass;
import org.junit.Test;

public class NumStableTest  extends SolrCloudTestCase {

  private static final String COLLECTION = "num_stable" ;

  private static final int numShards = 3;
  private static final int numReplicas = 2;
  private static final int maxShardsPerNode = 2;
  private static final int nodeCount = (numShards*numReplicas + 
(maxShardsPerNode-1))/maxShardsPerNode;

  private static final String id = "id";
  private static final int docNum = 200;

  @BeforeClass
  public static void setupCluster() throws Exception {

// create and configure cluster
configureCluster(nodeCount)
.addConfig("conf", configset("cloud-dynamic"))
.configure();

// create an empty collection
CollectionAdminRequest.createCollection(COLLECTION, "conf", numShards, 
numReplicas)
.setMaxShardsPerNode(maxShardsPerNode)
.process(cluster.getSolrClient());

Random rnd = random();
UpdateRequest r =  new UpdateRequest();
// add documents
for(int i = 0; i < docNum; i++){
  SolrInputDocument doc = sdoc(id, "1",
  "monthly_payment_i", "" + rnd.nextInt(1000),
  "score_d", "" + rnd.nextInt(1000),
  "car_age_id_i", "" + rnd.nextInt(1000),
  "car_variant_and_offer_type_s1", "" + rnd.nextInt(4));
  r.add(doc);
}
r.commit(cluster.getSolrClient(), COLLECTION);
  }

  @Test
  public void testNumStable() throws Exception {
String[] params = {
"q", "*:*",
"fl", "id",
"group.sort", "monthly_payment_i asc, score_d desc",
"group.limit", "100",
"sort", "car_age_id_i asc, score_d desc",
"debugQuery", "on",
"group.field", "car_variant_and_offer_type_s1",
"group", "true"
};

final SolrQuery solrQuery1 = new SolrQuery("rows","2", params);
final SolrQuery solrQuery2 = new SolrQuery("rows", "6", params);
final CloudSolrClient cloudSolrClient = cluster.getSolrClient();
final QueryResponse rsp1 = cloudSolrClient.query(COLLECTION, solrQuery1);
final QueryResponse rsp2 = cloudSolrClient.query(COLLECTION, solrQuery2);
final List grp1 = 
rsp1.getGroupResponse().getValues().get(0).getValues();
final List grp2 = 
rsp2.getGroupResponse().getValues().get(0).getValues();
assertEquals(grp1.size(), grp2.size());
int groupNum = grp1.size();
for(int i = 0; i < groupNum; i++){
  Group g1 = grp1.get(i);
  Group g2 = grp2.get(i);
  assertEquals(g1.getResult().getNumFound(), g2.getResult().getNumFound());
}
  }

}
{code}

> the number of docs in each group depends on rows
> 
>
> Key: SOLR-12315
> URL: https://issues.apache.org/jira/browse/SOLR-12315
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 7.1
>Reporter: Duo Chen
>Priority: Critical
> Attachments: difference.jpeg
>
>
> Hi, 
> We used Solr Cloud 7.1.0(3 nodes, 3 shards with 2 replicas). When we used 
> group query, we found that the number of docs in each group depends on the 
> rows number(group number). 
> When the rows bigger then 5, the return docs are correct and stable, for the 
> rest, the number of docs is smaller than the actual result. 
> Could you please explain why and give me some suggestion about how to decide 
> the rows number? 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-11.0.3) - Build # 401 - Unstable!

2019-08-15 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/401/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
Software caused connection abort: recv failed

Stack Trace:
javax.net.ssl.SSLException: Software caused connection abort: recv failed
at 
__randomizedtesting.SeedInfo.seed([6EE3FA5FE64B562D:D28D8C4D4218D557]:0)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at 
java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1314)
at 
java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:839)
at 
org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
at 
org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
at 
org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
at 
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
at 
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.verifySecurityStatus(SolrCloudAuthTestCase.java:202)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.verifySecurityStatus(SolrCloudAuthTestCase.java:178)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:130)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 

[jira] [Updated] (SOLR-13698) Calling Suggester via Alias fails

2019-08-15 Thread Eileen Mosch (JIRA)


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

Eileen Mosch updated SOLR-13698:

Description: 
There's a problem using a multi-collection alias in combination with suggester 
request. We used version 7.3.1 and had no problems, after upgrading to version 
8.x exceptions are thrown.

*Details*

I created an alias called „WORLD“ pointing to six collections.
{code:java}
// aliases.json
{"collection":{
"AT":"AT.test",
"BE":"BE.test",
"DE":"DE.test",
"FR":"FR.test",
"LU":"LU.test",
"NL":"NL.test",
"WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
}
{code}
If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the error 
message: „No live SolrServers available to handle this 
request:[http://[myIP]:8983/solr/WORLD“.

If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while 
waiting response from server at: 
[http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full 
stacktrace attached). The collection name within the error messages differs 
(AT.test... or BE.test... ) but the error information is still the same.
{code:java}
// HTTP API Suggester Call
http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
{code}
 If I use single-collection Aliases (e.g. "AT") everything works fine.

  was:
There's a problem using a multi-collection alias in combination with suggester 
request. We used version 7.3.1 and had no problems, after upgrading to version 
8.x exceptions are thrown.

*Details*

I created an alias called „WORLD“ pointing to six collections.
{code:java}
// aliases.json
{"collection":{
"AT":"AT.test",
"BE":"BE.test",
"DE":"DE.test",
"FR":"FR.test",
"LU":"LU.test",
"NL":"NL.test",
"WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
}
{code}
If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the error 
message: „No live SolrServers available to handle this 
request:[http://[myIP]:8983/solr/WORLD“.

If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while 
waiting response from server at: 
[http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full 
stacktrace attached)
{code:java}
// HTTP API Suggester Call
http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
{code}
 If I use single-collection Aliases (e.g. "DE") everything is fine.


> Calling Suggester via Alias fails
> -
>
> Key: SOLR-13698
> URL: https://issues.apache.org/jira/browse/SOLR-13698
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 8.2, 8.1.1
>Reporter: Eileen Mosch
>Priority: Major
> Attachments: http_suggester_stacktrace.json
>
>
> There's a problem using a multi-collection alias in combination with 
> suggester request. We used version 7.3.1 and had no problems, after upgrading 
> to version 8.x exceptions are thrown.
> *Details*
> I created an alias called „WORLD“ pointing to six collections.
> {code:java}
> // aliases.json
> {"collection":{
> "AT":"AT.test",
> "BE":"BE.test",
> "DE":"DE.test",
> "FR":"FR.test",
> "LU":"LU.test",
> "NL":"NL.test",
> "WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
> }
> {code}
> If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the 
> error message: „No live SolrServers available to handle this 
> request:[http://[myIP]:8983/solr/WORLD“.
> If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while 
> waiting response from server at: 
> [http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full 
> stacktrace attached). The collection name within the error messages differs 
> (AT.test... or BE.test... ) but the error information is still the same.
> {code:java}
> // HTTP API Suggester Call
> http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
> {code}
>  If I use single-collection Aliases (e.g. "AT") everything works fine.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Updated] (SOLR-13698) Calling Suggester via Alias fails

2019-08-15 Thread Eileen Mosch (JIRA)


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

Eileen Mosch updated SOLR-13698:

Description: 
There's a problem using a multi-collection alias in combination with suggester 
request. We used version 7.3.1 and had no problems, after upgrading to version 
8.x exceptions are thrown.

*Details*

I created an alias called „WORLD“ pointing to six collections.
{code:java}
// aliases.json
{"collection":{
"AT":"AT.test",
"BE":"BE.test",
"DE":"DE.test",
"FR":"FR.test",
"LU":"LU.test",
"NL":"NL.test",
"WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
}
{code}
If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the error 
message: „No live SolrServers available to handle this 
request:[http://[myIP]:8983/solr/WORLD“.

If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while 
waiting response from server at: 
[http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full 
stacktrace attached)
{code:java}
// HTTP API Suggester Call
http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
{code}
 If I use single-collection Aliases (e.g. "DE") everything is fine.

  was:
There's a problem using a multi-collection alias in combination with suggester 
request. We used version 7.3.1 and had no problems, after upgrading to version 
8.x exceptions are thrown.

*Details*

I created an alias called „WORLD“ pointing to six collections.

 
{code:java}
// aliases.json
{"collection":{
"AT":"AT.test",
"BE":"BE.test",
"DE":"DE.test",
"FR":"FR.test",
"LU":"LU.test",
"NL":"NL.test",
"WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
}
{code}
If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the error 
message: „No live SolrServers available to handle this 
request:[http://[myIP]:8983/solr/WORLD“.

If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while 
waiting response from server at: 
[http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full 
stacktrace attached)
{code:java}
// HTTP API Suggester Call
http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
{code}
 If I use single-collection Aliases (e.g. "DE") everything is fine.


> Calling Suggester via Alias fails
> -
>
> Key: SOLR-13698
> URL: https://issues.apache.org/jira/browse/SOLR-13698
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 8.2, 8.1.1
>Reporter: Eileen Mosch
>Priority: Major
> Attachments: http_suggester_stacktrace.json
>
>
> There's a problem using a multi-collection alias in combination with 
> suggester request. We used version 7.3.1 and had no problems, after upgrading 
> to version 8.x exceptions are thrown.
> *Details*
> I created an alias called „WORLD“ pointing to six collections.
> {code:java}
> // aliases.json
> {"collection":{
> "AT":"AT.test",
> "BE":"BE.test",
> "DE":"DE.test",
> "FR":"FR.test",
> "LU":"LU.test",
> "NL":"NL.test",
> "WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
> }
> {code}
> If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the 
> error message: „No live SolrServers available to handle this 
> request:[http://[myIP]:8983/solr/WORLD“.
> If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while 
> waiting response from server at: 
> [http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full 
> stacktrace attached)
> {code:java}
> // HTTP API Suggester Call
> http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
> {code}
>  If I use single-collection Aliases (e.g. "DE") everything is fine.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Created] (SOLR-13698) Calling Suggester via Alias fails

2019-08-15 Thread Eileen Mosch (JIRA)
Eileen Mosch created SOLR-13698:
---

 Summary: Calling Suggester via Alias fails
 Key: SOLR-13698
 URL: https://issues.apache.org/jira/browse/SOLR-13698
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Suggester
Affects Versions: 8.1.1, 8.2
Reporter: Eileen Mosch
 Attachments: http_suggester_stacktrace.json

There's a problem using a multi-collection alias in combination with suggester 
request. We used version 7.3.1 and had no problems, after upgrading to version 
8.x exceptions are thrown.

*Details*

I created an alias called „WORLD“ pointing to six collections.

 
{code:java}
// aliases.json
{"collection":{
"AT":"AT.test",
"BE":"BE.test",
"DE":"DE.test",
"FR":"FR.test",
"LU":"LU.test",
"NL":"NL.test",
"WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
}
{code}
If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the error 
message: „No live SolrServers available to handle this 
request:[http://[myIP]:8983/solr/WORLD“.

If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while 
waiting response from server at: 
[http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full 
stacktrace attached)
{code:java}
// HTTP API Suggester Call
http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
{code}
 If I use single-collection Aliases (e.g. "DE") everything is fine.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-11.0.3) - Build # 8088 - Still Unstable!

2019-08-15 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8088/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseSerialGC

14 tests failed.
FAILED:  
org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testFilePersistence

Error Message:
Software caused connection abort: recv failed

Stack Trace:
javax.net.ssl.SSLException: Software caused connection abort: recv failed
at 
__randomizedtesting.SeedInfo.seed([2F01E582C06239F3:DA081FF650E5FB6]:0)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at 
java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1314)
at 
java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:839)
at 
org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
at 
org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
at 
org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
at 
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
at 
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at 
org.apache.solr.util.RestTestHarness.getResponse(RestTestHarness.java:215)
at org.apache.solr.util.RestTestHarness.query(RestTestHarness.java:107)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:226)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
at 
org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testFilePersistence(TestModelManagerPersistence.java:168)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 

[jira] [Commented] (SOLR-12069) Default operator parameter q.op ignored.

2019-08-15 Thread Chongchen Chen (JIRA)


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

Chongchen Chen commented on SOLR-12069:
---

Hi, I have resolved this bug. [pull 
request|https://github.com/apache/lucene-solr/pull/833]

> Default operator parameter q.op ignored.
> 
>
> Key: SOLR-12069
> URL: https://issues.apache.org/jira/browse/SOLR-12069
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 7.2
>Reporter: Christoph Strobl
>Priority: Critical
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The {{q.op}} parameter as described in the [7.2 reference for the Standard 
> Query 
> Parser|http://lucene.apache.org/solr/guide/7_2/the-standard-query-parser.html#standard-query-parser-parameters]
>  does not get used when executing a query.
> Reproduce via _techproducts_ example.
>  # {{./bin/solr -e tchproducts}}
>  # {{./bin/post -c techproducts example/exampledocs/*.xml}}
>  # {{http "http://localhost:8983/solr/techproducts/select?q=inStock:(true 
> false)=AND"}}
> The search above is expected to return {{0}} results but instead matches all 
> {{21}} entries.
> The response header lists the {{q.op}} parameter 
> {code:javascript}
> {
>   "responseHeader": {
> "QTime": 3,
> "params": {
>   "debugQuery": "on",
>   "q": "inStock:(true false)",
>   "q.op": "AND"
> },
> "status": 0
>   },
>   // ...
> }
> {code}
> The debug output is as follows:
> {code:javascript}
> debug": {
>   "QParser": "LuceneQParser",
>   "explain": {
>   "100-435805": "\n1.5869651 = sum of:\n  1.5869651 = weight(inStock:F in 
> 31) [SchemaSimilarity], result of:\n1.5869651 = score(doc=31,freq=1.0 = 
> termFreq=1.0\n), product of:\n  1.5869651 = idf, computed as log(1 + 
> (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n4.0 = docFreq\n  
>   21.0 = docCount\n  1.0 = tfNorm, computed as (freq * (k1 + 1)) / 
> (freq + k1) from:\n1.0 = termFreq=1.0\n1.2 = parameter k1\n   
>  0.0 = parameter b (norms omitted for field)\n",
>   "6H500F0": "\n0.22884157 = sum of:\n  0.22884157 = weight(inStock:T in 
> 2) [SchemaSimilarity], result of:\n0.22884157 = score(doc=2,freq=1.0 = 
> termFreq=1.0\n), product of:\n  0.22884157 = idf, computed as log(1 + 
> (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n17.0 = docFreq\n 
>21.0 = docCount\n  1.0 = tfNorm, computed as (freq * (k1 + 1)) / 
> (freq + k1) from:\n1.0 = termFreq=1.0\n1.2 = parameter k1\n   
>  0.0 = parameter b (norms omitted for field)\n",
>   "EN7800GTX/2DHTV/256M": "\n1.5869651 = sum of:\n  1.5869651 = 
> weight(inStock:F in 30) [SchemaSimilarity], result of:\n1.5869651 = 
> score(doc=30,freq=1.0 = termFreq=1.0\n), product of:\n  1.5869651 = idf, 
> computed as log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n 
>4.0 = docFreq\n21.0 = docCount\n  1.0 = tfNorm, computed as 
> (freq * (k1 + 1)) / (freq + k1) from:\n1.0 = termFreq=1.0\n
> 1.2 = parameter k1\n0.0 = parameter b (norms omitted for field)\n",
>   "F8V7067-APL-KIT": "\n1.5869651 = sum of:\n  1.5869651 = 
> weight(inStock:F in 3) [SchemaSimilarity], result of:\n1.5869651 = 
> score(doc=3,freq=1.0 = termFreq=1.0\n), product of:\n  1.5869651 = idf, 
> computed as log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n 
>4.0 = docFreq\n21.0 = docCount\n  1.0 = tfNorm, computed as 
> (freq * (k1 + 1)) / (freq + k1) from:\n1.0 = termFreq=1.0\n
> 1.2 = parameter k1\n0.0 = parameter b (norms omitted for field)\n",
>   "GB18030TEST": "\n0.22884157 = sum of:\n  0.22884157 = weight(inStock:T 
> in 0) [SchemaSimilarity], result of:\n0.22884157 = score(doc=0,freq=1.0 = 
> termFreq=1.0\n), product of:\n  0.22884157 = idf, computed as log(1 + 
> (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n17.0 = docFreq\n 
>21.0 = docCount\n  1.0 = tfNorm, computed as (freq * (k1 + 1)) / 
> (freq + k1) from:\n1.0 = termFreq=1.0\n1.2 = parameter k1\n   
>  0.0 = parameter b (norms omitted for field)\n",
>   "IW-02": "\n1.5869651 = sum of:\n  1.5869651 = weight(inStock:F in 4) 
> [SchemaSimilarity], result of:\n1.5869651 = score(doc=4,freq=1.0 = 
> termFreq=1.0\n), product of:\n  1.5869651 = idf, computed as log(1 + 
> (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n4.0 = docFreq\n  
>   21.0 = docCount\n  1.0 = tfNorm, computed as (freq * (k1 + 1)) / 
> (freq + k1) from:\n1.0 = termFreq=1.0\n1.2 = parameter k1\n   
>  0.0 = parameter b (norms omitted for field)\n",
>   "MA147LL/A": "\n0.22884157 = sum of:\n  0.22884157 

[GitHub] [lucene-solr] chenkovsky opened a new pull request #833: SOLR-12069: Default operator parameter q.op ignored.

2019-08-15 Thread GitBox
chenkovsky opened a new pull request #833: SOLR-12069: Default operator 
parameter q.op ignored.
URL: https://github.com/apache/lucene-solr/pull/833
 
 
   Just change one line of code.
   I have run all tests in org.apache.solr.search.


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


With regards,
Apache Git Services

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



[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 180 - Failure

2019-08-15 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/180/

No tests ran.

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

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

package:

-unpack-solr-tgz:

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

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:

[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them

2019-08-15 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13677:


Commit 956f61dde9b1ce3fee6b609955d41d0b90c67285 in lucene-solr's branch 
refs/heads/jira/SOLR-13677_1 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=956f61d ]

SOLR-13677: minimize changes


> All Metrics Gauges should be unregistered by the objects that registered them
> -
>
> Key: SOLR-13677
> URL: https://issues.apache.org/jira/browse/SOLR-13677
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Noble Paul
>Priority: Major
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> The life cycle of Metrics producers are managed by the core (mostly). So, if 
> the lifecycle of the object is different from that of the core itself, these 
> objects will never be unregistered from the metrics registry. This will lead 
> to memory leaks



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-14-ea+9) - Build # 24547 - Unstable!

2019-08-15 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24547/
Java: 64bit/jdk-14-ea+9 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI

Error Message:
should be a routed alias

Stack Trace:
java.lang.AssertionError: should be a routed alias
at 
__randomizedtesting.SeedInfo.seed([9C51C70310DBA372:83865B2F63D05A39]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:315)
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:565)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:830)




Build Log:
[...truncated 13083 lines...]
   [junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest
   [junit4]   2> 338212 INFO  
(SUITE-AliasIntegrationTest-seed#[9C51C70310DBA372]-worker) [ ] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & 

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

2019-08-15 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/185/

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
Expected metric minimums for prefix SECURITY./authentication.: 
{failMissingCredentials=0, authenticated=2, passThrough=3, 
failWrongCredentials=0, requests=5, errors=0}, but got: 
{failMissingCredentials=0, authenticated=1, passThrough=3, totalTime=1799649, 
failWrongCredentials=0, requestTimes=546, requests=4, errors=0}

Stack Trace:
java.lang.AssertionError: Expected metric minimums for prefix 
SECURITY./authentication.: {failMissingCredentials=0, authenticated=2, 
passThrough=3, failWrongCredentials=0, requests=5, errors=0}, but got: 
{failMissingCredentials=0, authenticated=1, passThrough=3, totalTime=1799649, 
failWrongCredentials=0, requestTimes=546, requests=4, errors=0}
at 
__randomizedtesting.SeedInfo.seed([39FF0721EE8BB2C8:859171334AD831B2]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:131)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:85)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:184)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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