[jira] [Updated] (SOLR-9187) Export handler does not export date/tdate or boolean

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-9187:
-
Attachment: SOLR-9187.patch

There was a problem with the previous patch, this one fixes it.

I'm probably going to let this settle for a day or so then check it in unless 
there are objections.

> Export handler does not export date/tdate or boolean
> 
>
> Key: SOLR-9187
> URL: https://issues.apache.org/jira/browse/SOLR-9187
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-9187.patch, SOLR-9187.patch
>
>
> Since these can be DV fields it seems like it should. The first-level problem 
> is that SortingResponseWriter doesn't check for date types as a legal export 
> value. Whether there are repercussions elsewhere I don't know yet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7287) New lemma-tizer plugin for ukrainian language.

[Andriy Rysin (JIRA)]

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

Andriy Rysin commented on LUCENE-7287:
--

I just realized that Lucene includes morfologik analyzer 
(https://github.com/apache/lucene-solr/blob/master/lucene/analysis/morfologik/src/java/org/apache/lucene/analysis/morfologik/MorfologikAnalyzer.java).
 We already use the Ukrainian dictionary in morfologik format for LanguageTool 
(https://github.com/languagetool-org/languagetool/blob/master/languagetool-language-modules/uk/src/main/resources/org/languagetool/resource/uk/ukrainian.dict).
It's about 1.6MB in file and should be quite fast and memory efficient.

> New lemma-tizer plugin for ukrainian language.
> --
>
> Key: LUCENE-7287
> URL: https://issues.apache.org/jira/browse/LUCENE-7287
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Dmytro Hambal
>Priority: Minor
>  Labels: analysis, language, plugin
>
> Hi all,
> I wonder whether you are interested in supporting a plugin which provides a 
> mapping between ukrainian word forms and their lemmas. Some tests and docs go 
> out-of-the-box =) .
> https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer
> It's really simple but still works and generates some value for its users.
> More: https://github.com/elastic/elasticsearch/issues/18303



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
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 (32bit/jdk-9-ea+121) - Build # 16933 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16933/
Java: 32bit/jdk-9-ea+121 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:45719/solr/testschemaapi_shard1_replica1: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:45719/solr/testschemaapi_shard1_replica1: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([5B31964DEB662D96:D365A997459A406E]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:697)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1109)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_92) - Build # 840 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/840/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
ObjectTracker found 4 object(s) that were not released!!! 
[MockDirectoryWrapper, MDCAwareThreadPoolExecutor, SolrCore, 
MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 4 object(s) that were not 
released!!! [MockDirectoryWrapper, MDCAwareThreadPoolExecutor, SolrCore, 
MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([AE7EF232A10F4145]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestCoreDiscovery

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestCoreDiscovery: 
1) Thread[id=8920, name=searcherExecutor-4505-thread-1, state=WAITING, 
group=TGRP-TestCoreDiscovery] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)   
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestCoreDiscovery: 
   1) Thread[id=8920, name=searcherExecutor-4505-thread-1, state=WAITING, 
group=TGRP-TestCoreDiscovery]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+121) - Build # 16932 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16932/
Java: 64bit/jdk-9-ea+121 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not find collection:.system

Stack Trace:
java.lang.AssertionError: Could not find collection:.system
at 
__randomizedtesting.SeedInfo.seed([2001F7D03DF48A55:F84CDA87CA292FF5]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:154)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:134)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:111)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

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

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:45528/collection1: Expected mime type 
application/octet-stream but got text/html.Error 
500HTTP ERROR: 500 Problem accessing 
/collection1/update. Reason: 
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg=SolrCore
 collection1 is not available due to init failure: Timed out 
getting coreNodeName for 
collection1,trace=org.apache.solr.common.SolrException: SolrCore 
collection1 is not available due to init failure: Timed out getting 
coreNodeName for collection1  at 
org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:1080)  at 
org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:256)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:418)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:109)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:399)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:518)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572) 
 at java.lang.Thread.run(java.base@9-ea/Thread.java:843) Caused by: 
org.apache.solr.common.SolrException: Timed out getting coreNodeName for 
collection1  at 
org.apache.solr.cloud.ZkController.waitForCoreNodeName(ZkController.java:1387)  
at 
org.apache.solr.cloud.ZkController.doGetShardIdAndNodeNameProcess(ZkController.java:1365)
  at org.apache.solr.cloud.ZkController.preRegister(ZkController.java:1456)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:809)  at 
org.apache.solr.core.CoreContainer.lambda$load$0(CoreContainer.java:468)  at 
java.util.concurrent.FutureTask.run(java.base@9-ea/FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1158)
  at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
  ... 1 more ,code=500} http://eclipse.org/jetty;>Powered by Jetty:// 9.3.8.v20160314 
  

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


Error 500 


HTTP ERROR: 500
Problem accessing /collection1/update. Reason:

{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg=SolrCore
 collection1 is not available due to init failure: Timed out 
getting coreNodeName for 
collection1,trace=org.apache.solr.common.SolrException: SolrCore 
collection1 is not available due to init failure: Timed out getting 
coreNodeName for collection1
at org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:1080)
at org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:256)
at 

[jira] [Commented] (SOLR-9189) explosion of timeout related failures in jenkins the past few days

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9189:


yeah ... i think the evidence is pretty strong that this issue was caused by 
something related to the ZkStateReader changes [~romseygeek] was working on in 
SOLR-9181+SOLR-9140...

sarowe's 6.x jenkins job just finished build#1207 -- the first build after 
4e3884bec7c386fe718abc423b2381b68aaf1a97 landed on branch_6x -- and it only 
took 12 minutes  (this in spite of the fact that i made no SSL randomization 
suppression related changes to branch_6x as part of this issue -- that was just 
to master)

http://jenkins.sarowe.net/job/Lucene-Solr-tests-6.x/1207/

Just to be safe, i'll leave 59b4fc0bb0105ec25285f763fde86739433a38b1 on master 
until tomorrow morning (in case my observations related to SOLR-9181+SOLR-9140 
wind up being total flukes) before reverting.

> explosion of timeout related failures in jenkins the past few days
> --
>
> Key: SOLR-9189
> URL: https://issues.apache.org/jira/browse/SOLR-9189
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 6.1
>
>
> In the past few days, something has gone seriously wonky with our jenkins 
> tests -- causing a serious explosion in the number of test failures -- 
> notably do to various sorts of timeouts...
> * "Unable to create core ... Timed out getting coreNodeName for ..."
> * "msg=SolrCore is loading,code=503"
> * "Timeout occured while waiting response from server"
> * "No registered leader was found after waiting for 3ms"
> * "Unable to create core ... Caused by: Timed out getting shard id for core: 
> ..."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
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/jdk1.8.0_92) - Build # 5894 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5894/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 70083 lines...]
BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:740: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:101: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build.xml:632: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build.xml:607: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:2496:
 java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:209)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at 
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at 
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at 
sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
at 
org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:660)
at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579)
at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569)

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



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

[jira] [Commented] (LUCENE-7316) Geo3d test failure

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7316:
-

Ok, that fix worked.  I have to port it to GeoConcavePolygon as well, but other 
than that the problem with bounds would appear to be solved.


> Geo3d test failure
> --
>
> Key: LUCENE-7316
> URL: https://issues.apache.org/jira/browse/LUCENE-7316
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
> Attachments: LUCENE-7316.patch
>
>
> Reproducible on master with:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations 
> -Dtests.seed=EEA08DD7FAE3C688 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.directory=MMapDirectory -Dtests.locale=es 
> -Dtests.timezone=America/Manaus -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}
> Note: I was initially unable to reproduce this, until I pulled up code that 
> [~mikemccand] recently committed.  It seems possible that encoding/decoding 
> changes are triggering it.  Of specific concern is the new way 
> maximum/minimum decoded values are computed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Apache Jenkins Server]

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

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

Error Message:
Expected to find shardAddress in the up shard info

Stack Trace:
java.lang.AssertionError: Expected to find shardAddress in the up shard info
at 
__randomizedtesting.SeedInfo.seed([A5D189AD312CE909:2D85B6779FD084F1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.TestDistributedSearch.comparePartialResponses(TestDistributedSearch.java:1172)
at 
org.apache.solr.TestDistributedSearch.queryPartialResults(TestDistributedSearch.java:1113)
at 
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:973)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1011)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (SOLR-5944) Support updates of numeric DocValues

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-5944:


bq. Removed all non 3x, 4x codec suppression. They need to be suppressed as per 
a comment from Mikhail. ...

that comment is over 2 years old, from a time when those codecs existed but did 
not support updating doc values.

those codecs no longer exist (on either master or branch_6x) -- even if someone 
had na existing index with segments from those codecs, they would not be 
supported by any Solr 6.x version because they are more then 1 major version 
old -- we only have to worry about Lucene5* codecs and higher.

bq. As of now, both will generate a new version. I think "inc" 0 should be 
dropped, and "set" same value should be versioned. I'll check if behaviour in 
this patch is at par with regular atomic updates; and if so, will open a 
separate issue for this later.

yeah, sorry -- my point was: "whatever the current, non-patched, behavior is 
for the version returned from these types of updates, we need to assert that 
behavior is true here." -- we should not be changing any semantics here, 
absolutely open a distinct issue for that if you think it makes sense as a 
future improvement.

bq. I think we can do the same in TestStressInPlaceUpdates, by randomly setting 
number of writer threads to 1 sometimes.

Isn't that still a cloud based test with multiple nodes/shards?  Even with only 
1 writer thread it's going ot be harder to debug then doing more randomized 
testing in a single node test (via something like checkReplay as in my previous 
suggestion)

bq. I couldn't find a way to do this (check RTG against uncommitted model) for 
the TestInPlaceUpdate (now called TestInPlaceUpdatesStandalone in this patch). 
This is based on SolrTestCaseJ4.

{{SolrTestCaseJ4.addAndGetVersion(...)}}



> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: DUP.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.62D328FA1DEA57FD.fail2.txt, 
> hoss.62D328FA1DEA57FD.fail3.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8859) AbstractSpatialFieldType can use ShapeContext to read/write shapes (WKT, GeoJSON)

[David Smiley (JIRA)]

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

David Smiley updated SOLR-8859:
---
Attachment: SOLR-8859_part2.patch

The attached patch rectifies the aforementioned problems includes more testing. 
 Fixing RptWithGeometrySpatialField was actually pretty easy so I just did it 
here.  The patch also clarifies the CHANGES.txt to make it more apparent that 
this adds GeoJSON:

{noformat}
* SOLR-8859: Spatial fields like RPT can now be configured to use Spatial4j 
registered shape formats
  e.g. via format="GeoJSON".  (ryan, David Smiley)
{noformat}

I plan to commit this tomorrow.

> AbstractSpatialFieldType can use ShapeContext to read/write shapes (WKT, 
> GeoJSON)
> -
>
> Key: SOLR-8859
> URL: https://issues.apache.org/jira/browse/SOLR-8859
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Blocker
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8859.patch, SOLR-8859_part2.patch
>
>
> Right now the AbstractSpatialFieldType throws exceptions if it needs to 
> convert to/from a string.  We should use the context to convert



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-2199) DIH JdbcDataSource - Support multiple resultsets

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-2199:


[~tinexw], at least it lacks a unit test. I'd like to commit if it's provided. 

> DIH JdbcDataSource - Support multiple resultsets
> 
>
> Key: SOLR-2199
> URL: https://issues.apache.org/jira/browse/SOLR-2199
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4.1
>Reporter: Mark Waddle
>Assignee: Mikhail Khludnev
> Attachments: SOLR-2199.patch
>
>
> Database servers can return multiple result sets from a single statement. 
> This can be beneficial for indexing because it reduces the number of 
> connections and statements being executed against a database, therefore 
> reducing overhead. The JDBC Statement object supports reading multiple 
> ResultSets. Support should be added to the JdbcDataSource to take advantage 
> of this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-2199) DIH JdbcDataSource - Support multiple resultsets

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev reassigned SOLR-2199:
--

Assignee: Mikhail Khludnev

> DIH JdbcDataSource - Support multiple resultsets
> 
>
> Key: SOLR-2199
> URL: https://issues.apache.org/jira/browse/SOLR-2199
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4.1
>Reporter: Mark Waddle
>Assignee: Mikhail Khludnev
> Attachments: SOLR-2199.patch
>
>
> Database servers can return multiple result sets from a single statement. 
> This can be beneficial for indexing because it reduces the number of 
> connections and statements being executed against a database, therefore 
> reducing overhead. The JDBC Statement object supports reading multiple 
> ResultSets. Support should be added to the JdbcDataSource to take advantage 
> of this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8747) ExclusiveMarking enum and checkExclusiveMarking method is very confusing

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8747:
--

Is this fixed now per Noble's treelocking changes?

> ExclusiveMarking enum and checkExclusiveMarking method is very confusing
> 
>
> Key: SOLR-8747
> URL: https://issues.apache.org/jira/browse/SOLR-8747
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 6.0
>
>
> ExclusiveMarking enum and checkExclusiveMarking method is very confusing.  It 
> appears to do the opposite of its name e.g.
> {code}
> @Override
>   public ExclusiveMarking checkExclusiveMarking(String collectionName, 
> ZkNodeProps message) {
> // CLUSTERSTATUS is always mutually exclusive
> //TODO deprecated remove this check .
> if(CLUSTERSTATUS.isEqual(message.getStr(Overseer.QUEUE_OPERATION)))
>   return ExclusiveMarking.EXCLUSIVE;
> synchronized (collectionWip) {
>   if(collectionWip.contains(collectionName))
> return ExclusiveMarking.NONEXCLUSIVE;
> }
> return ExclusiveMarking.NOTDETERMINED;
>   }
> {code}
> I guess it returns exclusive if the current task is the only one to run. We 
> should document it or rename it to make its function more comprehensible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-8610) DIH - Resolve variables in encryptKeyFile

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev resolved SOLR-8610.

   Resolution: Fixed
Fix Version/s: (was: 6.0)
   master (7.0)
   6.1

> DIH - Resolve variables in encryptKeyFile
> -
>
> Key: SOLR-8610
> URL: https://issues.apache.org/jira/browse/SOLR-8610
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8610.patch, SOLR-8610.patch
>
>
> I would like to use a variable like {{$\{path.to.file\}}} for  
> {{encryptKeyFile}} in my DIH config files so that I don't have to specify the 
> concrete absolute path in all files. This is currently not possible since 
> variables are not resolved. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-8676) It's not possible to use a different log4.properties file on windows

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev resolved SOLR-8676.

   Resolution: Fixed
Fix Version/s: master (7.0)
   6.1

> It's not possible to use a different log4.properties file on windows
> 
>
> Key: SOLR-8676
> URL: https://issues.apache.org/jira/browse/SOLR-8676
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8676.patch, SOLR-8676.patch, verifying SOLR-8676.txt
>
>
> It's currently not possible to change the location of the log4j.properties 
> file on windows. The value of {{LOG4J_CONFIG}} always gets replaced with the 
> default value {{server\resources\log4j.properties}}. Thus, this file inside 
> the server directory needs to be changed after every update.
> See attached patch for a fix. Unfortunately, I couldn't figure out why 
> {{LOG4J_CONFIG}} was set to empty. I tested manually that logging still works 
> when running an example so I hope that this line is really just obsolete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-8445) fix line separator in log4j.properties files

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev resolved SOLR-8445.

   Resolution: Fixed
Fix Version/s: (was: 6.0)
   (was: 5.5)
   master (7.0)
   6.1

> fix line separator in log4j.properties files
> 
>
> Key: SOLR-8445
> URL: https://issues.apache.org/jira/browse/SOLR-8445
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.4, 6.0
>Reporter: Ahmet Arslan
>Assignee: Mikhail Khludnev
>Priority: Trivial
>  Labels: log4j, logging
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8445.patch, SOLR-8445.patch
>
>
> new line is mistyped in conversion pattern 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8445) fix line separator in log4j.properties files

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8445: fix line separator in log4j.properties files


> fix line separator in log4j.properties files
> 
>
> Key: SOLR-8445
> URL: https://issues.apache.org/jira/browse/SOLR-8445
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.4, 6.0
>Reporter: Ahmet Arslan
>Assignee: Mikhail Khludnev
>Priority: Trivial
>  Labels: log4j, logging
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-8445.patch, SOLR-8445.patch
>
>
> new line is mistyped in conversion pattern 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9140) Replace some state polling with CollectionStateWatchers

[ASF subversion and git services (JIRA)]

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

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

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

Revert "SOLR-9140: Replace some zk state polling with CollectionStateWatchers"

Alan's comments (via Uwe) in SOLR-9140 jira comments suggest that he thought he 
had already
reverted this on both branches, but that is not the case.  Reverting on his 
behalf due to the
likelyhood that this is causing SOLR-9189.

Alan's comments regarding the master equivilent revert...

"There's still some places where notifications can be missed, so I'm reverting
this until those are fixed."

This reverts commit 9f299bb6ad39960469e297b0b364f5972e485621.


> Replace some state polling with CollectionStateWatchers
> ---
>
> Key: SOLR-9140
> URL: https://issues.apache.org/jira/browse/SOLR-9140
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 6.1
>
> Attachments: SOLR-9140.patch, SOLR-9140.patch
>
>
> There are a few places in ZkController and the collection processing code 
> that directly query ZK for collection state, and then wait and poll for 
> expected state changes.  We can now replace these with 
> CollectionStateWatchers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9189) explosion of timeout related failures in jenkins the past few days

[ASF subversion and git services (JIRA)]

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

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

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

Revert "SOLR-9140: Replace some zk state polling with CollectionStateWatchers"

Alan's comments (via Uwe) in SOLR-9140 jira comments suggest that he thought he 
had already
reverted this on both branches, but that is not the case.  Reverting on his 
behalf due to the
likelyhood that this is causing SOLR-9189.

Alan's comments regarding the master equivilent revert...

"There's still some places where notifications can be missed, so I'm reverting
this until those are fixed."

This reverts commit 9f299bb6ad39960469e297b0b364f5972e485621.


> explosion of timeout related failures in jenkins the past few days
> --
>
> Key: SOLR-9189
> URL: https://issues.apache.org/jira/browse/SOLR-9189
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 6.1
>
>
> In the past few days, something has gone seriously wonky with our jenkins 
> tests -- causing a serious explosion in the number of test failures -- 
> notably do to various sorts of timeouts...
> * "Unable to create core ... Timed out getting coreNodeName for ..."
> * "msg=SolrCore is loading,code=503"
> * "Timeout occured while waiting response from server"
> * "No registered leader was found after waiting for 3ms"
> * "Unable to create core ... Caused by: Timed out getting shard id for core: 
> ..."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9140) Replace some state polling with CollectionStateWatchers

[ASF subversion and git services (JIRA)]

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

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

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

Revert "SOLR-9140: Replace some zk state polling with CollectionStateWatchers"

Alan's comments (via Uwe) in SOLR-9140 jira comments suggest that he thought he 
had already
reverted this on both branches, but that is not the case.  Reverting on his 
behalf due to the
likelyhood that this is causing SOLR-9189.

Alan's comments regarding the master equivilent revert...

"There's still some places where notifications can be missed, so I'm reverting
this until those are fixed."

This reverts commit 9f299bb6ad39960469e297b0b364f5972e485621.


> Replace some state polling with CollectionStateWatchers
> ---
>
> Key: SOLR-9140
> URL: https://issues.apache.org/jira/browse/SOLR-9140
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 6.1
>
> Attachments: SOLR-9140.patch, SOLR-9140.patch
>
>
> There are a few places in ZkController and the collection processing code 
> that directly query ZK for collection state, and then wait and poll for 
> expected state changes.  We can now replace these with 
> CollectionStateWatchers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8445) fix line separator in log4j.properties files

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8445: fix line separator in log4j.properties files


> fix line separator in log4j.properties files
> 
>
> Key: SOLR-8445
> URL: https://issues.apache.org/jira/browse/SOLR-8445
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.4, 6.0
>Reporter: Ahmet Arslan
>Assignee: Mikhail Khludnev
>Priority: Trivial
>  Labels: log4j, logging
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-8445.patch, SOLR-8445.patch
>
>
> new line is mistyped in conversion pattern 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 181 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/181/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

20 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'first' for path 
'response/params/x/_appends_/add' full output: {   "responseHeader":{ 
"status":0, "QTime":0},   "response":{ "znodeVersion":3, "params":{ 
  "x":{ "a":"A val", "b":"B val", "":{"v":0}},  
 "y":{ "p":"P val", "q":"Q val", "":{"v":2},  from 
server:  http://127.0.0.1:61530/uw_gxj/dc/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'first' for path 
'response/params/x/_appends_/add' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":3,
"params":{
  "x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
  "y":{
"p":"P val",
"q":"Q val",
"":{"v":2},  from server:  
http://127.0.0.1:61530/uw_gxj/dc/collection1
at 
__randomizedtesting.SeedInfo.seed([E23C5815F355BF8A:6A6867CF5DA9D272]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:457)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:231)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:62)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (LUCENE-7304) Doc values based block join implementation

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen commented on LUCENE-7304:
---

[~paul.elsc...@xs4all.nl] This is a lot of code :) I really think this should 
be moved to a new issue, not just because of this size of the patch, but also 
because the implementation is different compared to what was initially proposed 
here. Also I think that EliasFanoDocIdSet and friends shouldn't be added to 
core, but should be added the join module instead. EliasFano was superseded 
from core as general purposes docidset by other implementations a while ago and 
since now it will be used in context of block join, it makes sense to just add 
it to the join module. 

> Doc values based block join implementation
> --
>
> Key: LUCENE-7304
> URL: https://issues.apache.org/jira/browse/LUCENE-7304
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Minor
> Attachments: LUCENE-5092-20140313.patch, LUCENE-7304-20160531.patch, 
> LUCENE-7304-20160606.patch, LUCENE_7304.patch
>
>
> At query time the block join relies on a bitset for finding the previous 
> parent doc during advancing the doc id iterator. On large indices these 
> bitsets can consume large amounts of jvm heap space.  Also typically due the 
> nature how these bitsets are set, the 'FixedBitSet' implementation is used.
> The idea I had was to replace the bitset usage by a numeric doc values field 
> that stores offsets. Each child doc stores how many docids it is from its 
> parent doc and each parent stores how many docids it is apart from its first 
> child. At query time this information can be used to perform the block join.
> I think another benefit of this approach is that external tools can now 
> easily determine if a doc is part of a block of documents and perhaps this 
> also helps index time sorting?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8676) It's not possible to use a different log4.properties file on windows

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8676: keep LOG4J_CONFIG in solr.cmd


> It's not possible to use a different log4.properties file on windows
> 
>
> Key: SOLR-8676
> URL: https://issues.apache.org/jira/browse/SOLR-8676
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Attachments: SOLR-8676.patch, SOLR-8676.patch, verifying SOLR-8676.txt
>
>
> It's currently not possible to change the location of the log4j.properties 
> file on windows. The value of {{LOG4J_CONFIG}} always gets replaced with the 
> default value {{server\resources\log4j.properties}}. Thus, this file inside 
> the server directory needs to be changed after every update.
> See attached patch for a fix. Unfortunately, I couldn't figure out why 
> {{LOG4J_CONFIG}} was set to empty. I tested manually that logging still works 
> when running an example so I hope that this line is really just obsolete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8676) It's not possible to use a different log4.properties file on windows

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8676: keep LOG4J_CONFIG in solr.cmd


> It's not possible to use a different log4.properties file on windows
> 
>
> Key: SOLR-8676
> URL: https://issues.apache.org/jira/browse/SOLR-8676
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Attachments: SOLR-8676.patch, SOLR-8676.patch, verifying SOLR-8676.txt
>
>
> It's currently not possible to change the location of the log4j.properties 
> file on windows. The value of {{LOG4J_CONFIG}} always gets replaced with the 
> default value {{server\resources\log4j.properties}}. Thus, this file inside 
> the server directory needs to be changed after every update.
> See attached patch for a fix. Unfortunately, I couldn't figure out why 
> {{LOG4J_CONFIG}} was set to empty. I tested manually that logging still works 
> when running an example so I hope that this line is really just obsolete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8610) DIH - Resolve variables in encryptKeyFile

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8610: Resolve variables in encryptKeyFile of DIH's JdbcDataSource


> DIH - Resolve variables in encryptKeyFile
> -
>
> Key: SOLR-8610
> URL: https://issues.apache.org/jira/browse/SOLR-8610
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.0
>
> Attachments: SOLR-8610.patch, SOLR-8610.patch
>
>
> I would like to use a variable like {{$\{path.to.file\}}} for  
> {{encryptKeyFile}} in my DIH config files so that I don't have to specify the 
> concrete absolute path in all files. This is currently not possible since 
> variables are not resolved. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8610) DIH - Resolve variables in encryptKeyFile

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8610: Resolve variables in encryptKeyFile of DIH's JdbcDataSource


> DIH - Resolve variables in encryptKeyFile
> -
>
> Key: SOLR-8610
> URL: https://issues.apache.org/jira/browse/SOLR-8610
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.0
>
> Attachments: SOLR-8610.patch, SOLR-8610.patch
>
>
> I would like to use a variable like {{$\{path.to.file\}}} for  
> {{encryptKeyFile}} in my DIH config files so that I don't have to specify the 
> concrete absolute path in all files. This is currently not possible since 
> variables are not resolved. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16931 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16931/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:39549/solr/testschemaapi_shard1_replica2: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:39549/solr/testschemaapi_shard1_replica2: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([83721422E27BCB92:B262BF84C87A66A]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:697)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1109)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 85 - Still Failing

[Apache Jenkins Server]

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

20 tests failed.
FAILED:  org.apache.solr.cloud.BasicZkTest.testBasic

Error Message:
No registered leader was found after waiting for 3ms , collection: 
collection1 slice: shard1

Stack Trace:
org.apache.solr.common.SolrException: No registered leader was found after 
waiting for 3ms , collection: collection1 slice: shard1
at 
__randomizedtesting.SeedInfo.seed([2C1AFD9AB08B3EFF:87E0E08F6F57B8D1]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderRetry(ZkStateReader.java:718)
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderUrl(ZkStateReader.java:685)
at org.apache.solr.cloud.BasicZkTest.testBasic(BasicZkTest.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
1 thread leaked from SUITE scope at 

[jira] [Commented] (SOLR-8612) DIH JdbcDataSource - statement not always closed

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8612:


Commit message a little bit superfluous, but I think it's forgivable. 

> DIH JdbcDataSource - statement not always closed
> 
>
> Key: SOLR-8612
> URL: https://issues.apache.org/jira/browse/SOLR-8612
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8612.patch, SOLR-8612.patch, SOLR-8612.patch, 
> SOLR-8612.patch, SOLR-8612.patch
>
>
> There are several cases where the Statement used by JdbcDataSource is not 
> closed, potentially resulting in too many open connections:
> - an exception is throw in the {{ResultSetIterator}} constructor
> - the result set is null in the {{ResultSetIterator}} constructor
> - an exception is thrown during import and the import is aborted (onError 
> flag set to abort)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7304) Doc values based block join implementation

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-7304:
--

To save some space for multilevel blocks, at a higher level one could use an 
EliasFanoSequence of the indexes of the lower level.

> Doc values based block join implementation
> --
>
> Key: LUCENE-7304
> URL: https://issues.apache.org/jira/browse/LUCENE-7304
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Minor
> Attachments: LUCENE-5092-20140313.patch, LUCENE-7304-20160531.patch, 
> LUCENE-7304-20160606.patch, LUCENE_7304.patch
>
>
> At query time the block join relies on a bitset for finding the previous 
> parent doc during advancing the doc id iterator. On large indices these 
> bitsets can consume large amounts of jvm heap space.  Also typically due the 
> nature how these bitsets are set, the 'FixedBitSet' implementation is used.
> The idea I had was to replace the bitset usage by a numeric doc values field 
> that stores offsets. Each child doc stores how many docids it is from its 
> parent doc and each parent stores how many docids it is apart from its first 
> child. At query time this information can be used to perform the block join.
> I think another benefit of this approach is that external tools can now 
> easily determine if a doc is part of a block of documents and perhaps this 
> also helps index time sorting?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9140) Replace some state polling with CollectionStateWatchers

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9140:
-

Message from @romseygeek: "I think I reverted both branches, but the Berlin 
buzzwords internet was flakey."

> Replace some state polling with CollectionStateWatchers
> ---
>
> Key: SOLR-9140
> URL: https://issues.apache.org/jira/browse/SOLR-9140
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 6.1
>
> Attachments: SOLR-9140.patch, SOLR-9140.patch
>
>
> There are a few places in ZkController and the collection processing code 
> that directly query ZK for collection state, and then wait and poll for 
> expected state changes.  We can now replace these with 
> CollectionStateWatchers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-7304) Doc values based block join implementation

[Paul Elschot (JIRA)]

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

Paul Elschot updated LUCENE-7304:
-
Attachment: LUCENE-7304-20160606.patch

Patch of 6 June 2016.
This is the EliasFano code from  LUCENE-5627 put into core.

This has EliasFanoSequence implemented as EliasFanoBytes and as EliasFanoLongs, 
and an encoder and a decoder for these.

The EliasFanoDocIdSet uses an EliasFanoLongs except when it is dense, in that 
case it uses a FixedBitSet.

I added a getBitSet() method in this EliasFanoDocIdSet.

I also added the test cases from LUCENE-5627, but I did not add a test for the 
getBitSet() method yet. It works as a DocIdSet, so as a BitSet should be no 
problem.

EliasFanoDocIdSet could also be implemented on EliasFanoBytes, and it should be 
doable to put that in an index. At LUCENE-5627 EliasFanoBytes is used as a 
Payload already.


> Doc values based block join implementation
> --
>
> Key: LUCENE-7304
> URL: https://issues.apache.org/jira/browse/LUCENE-7304
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Minor
> Attachments: LUCENE-5092-20140313.patch, LUCENE-7304-20160531.patch, 
> LUCENE-7304-20160606.patch, LUCENE_7304.patch
>
>
> At query time the block join relies on a bitset for finding the previous 
> parent doc during advancing the doc id iterator. On large indices these 
> bitsets can consume large amounts of jvm heap space.  Also typically due the 
> nature how these bitsets are set, the 'FixedBitSet' implementation is used.
> The idea I had was to replace the bitset usage by a numeric doc values field 
> that stores offsets. Each child doc stores how many docids it is from its 
> parent doc and each parent stores how many docids it is apart from its first 
> child. At query time this information can be used to perform the block join.
> I think another benefit of this approach is that external tools can now 
> easily determine if a doc is part of a block of documents and perhaps this 
> also helps index time sorting?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-9190) upgrade from solr4 to solr-5.5.0

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-9190.
--
Resolution: Invalid

First, please raise issues like this on the user's list first, it'll get a lot 
more eyes. We try to reserve JIRA for known code problems. Since this is the 
first time I've seen any kind of issue like this I suspect you've done 
something unfortunate in your installation. When you talk about adding lib 
directives to solrconfig.xml, I suspect you're trying to mix Solr 5 jars with 
Solr 4 jars which won't work.

I'm closing this on the theory it's not a bug in Solr, we can re-open if 
necessary (after this gets discussed on the user's list).

Try this:
Shut down Solr
Install a fresh 5.5 in another directory
start up the fresh 5.5 with SOLR_HOME set to the same thing it was in Solr 4.x

> upgrade from solr4 to solr-5.5.0
> 
>
> Key: SOLR-9190
> URL: https://issues.apache.org/jira/browse/SOLR-9190
> Project: Solr
>  Issue Type: Bug
> Environment: solr-5.5.0
>Reporter: Lena Gurevich
>
> Installed solr-5.5.0. Example shard works fine. No matter what I do for 
> existing shards, I get 
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> org/apache/solr/util/plugin/SolrCoreAware
>  in solrconfig.xml I put the first line: dir="/opt/solr-5.5.0/server/solr-webapp/webapp/WEB-INF/lib/solr-core-5.5.0.jar"
>  />
> SolrCoreAware.class is a part of solr-core-5.5.o.jar



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-8612) DIH JdbcDataSource - statement not always closed

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev resolved SOLR-8612.

   Resolution: Fixed
Fix Version/s: (was: 6.0)
   master (7.0)
   6.1

> DIH JdbcDataSource - statement not always closed
> 
>
> Key: SOLR-8612
> URL: https://issues.apache.org/jira/browse/SOLR-8612
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8612.patch, SOLR-8612.patch, SOLR-8612.patch, 
> SOLR-8612.patch, SOLR-8612.patch
>
>
> There are several cases where the Statement used by JdbcDataSource is not 
> closed, potentially resulting in too many open connections:
> - an exception is throw in the {{ResultSetIterator}} constructor
> - the result set is null in the {{ResultSetIterator}} constructor
> - an exception is thrown during import and the import is aborted (onError 
> flag set to abort)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9140) Replace some state polling with CollectionStateWatchers

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9140:


[~romseygeek] - you reverted from master by not 6.x ?

Also - please note SOLR-9189 if you haven't already.

> Replace some state polling with CollectionStateWatchers
> ---
>
> Key: SOLR-9140
> URL: https://issues.apache.org/jira/browse/SOLR-9140
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 6.1
>
> Attachments: SOLR-9140.patch, SOLR-9140.patch
>
>
> There are a few places in ZkController and the collection processing code 
> that directly query ZK for collection state, and then wait and poll for 
> expected state changes.  We can now replace these with 
> CollectionStateWatchers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9189) explosion of timeout related failures in jenkins the past few days

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-9189:
---
 Priority: Blocker  (was: Critical)
Fix Version/s: 6.1
  Description: 
In the past few days, something has gone seriously wonky with our jenkins tests 
-- causing a serious explosion in the number of test failures -- notably do to 
various sorts of timeouts...

* "Unable to create core ... Timed out getting coreNodeName for ..."
* "msg=SolrCore is loading,code=503"
* "Timeout occured while waiting response from server"
* "No registered leader was found after waiting for 3ms"
* "Unable to create core ... Caused by: Timed out getting shard id for core: 
..."


  was:

In the past few days, something has gone seriously wonky with our jenkins tests 
-- causing a serious explosion in the number of test failures -- notably do to 
various sorts of timeouts...

* "Unable to create core ... Timed out getting coreNodeName for ..."
* "msg=SolrCore is loading,code=503"
* "Timeout occured while waiting response from server"
* "No registered leader was found after waiting for 3ms"
* "Unable to create core ... Caused by: Timed out getting shard id for core: 
..."



marking as a blocker for 6.1 -- even if the problem has magically started to 
disipate, we should probably not release unless we're confident we understand 
why this hapened.

> explosion of timeout related failures in jenkins the past few days
> --
>
> Key: SOLR-9189
> URL: https://issues.apache.org/jira/browse/SOLR-9189
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 6.1
>
>
> In the past few days, something has gone seriously wonky with our jenkins 
> tests -- causing a serious explosion in the number of test failures -- 
> notably do to various sorts of timeouts...
> * "Unable to create core ... Timed out getting coreNodeName for ..."
> * "msg=SolrCore is loading,code=503"
> * "Timeout occured while waiting response from server"
> * "No registered leader was found after waiting for 3ms"
> * "Unable to create core ... Caused by: Timed out getting shard id for core: 
> ..."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9189) explosion of timeout related failures in jenkins the past few days

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9189:


sarowe reminded me offline about the "buildTimeTrend" feature of jenkins -- 
while the ASF jenkins machines have only been running tests about once a day, 
so it's hard to spot an obvious pattern, uwe & sarowe's jenkins machines have 
been hammering on tests a lot faster, and you can really spot a trend...

http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/buildTimeTrend
http://jenkins.thetaphi.de/view/All/job/Lucene-Solr-6.x-Linux/buildTimeTrend

http://jenkins.sarowe.net/job/Lucene-Solr-tests-master/buildTimeTrend
http://jenkins.sarowe.net/job/Lucene-Solr-tests-6.x/buildTimeTrend

...from sarowe's master job, build #7028 was the first test in a while to go 
over 20 minutes, and from that point on tests were reliably over 40 minutes 
until build #7035 which droped down to 10 minutes

* http://jenkins.sarowe.net/job/Lucene-Solr-tests-master/7028/
** 1e2ba9fe9be84f0b5defe4965735eae892fabf7b
** "Jun 4, 2016 7:14:24 AM"
** changes:
*** Revert "SOLR-9181: Fix test bug in ZkStateReaderTest" (detail)
* http://jenkins.sarowe.net/job/Lucene-Solr-tests-master/7035/
** c8570ed821654cdce5f92ae17d06a21f242524e2
** "Jun 6, 2016 1:08:05 PM"
** changes:
*** Revert "SOLR-9140: Replace some zk state polling with (detail)
*** LUCENE-7132: BooleanQuery sometimes assigned the wrong score when ranges 
(detail)

...that means the slow down didn't hit jenkins master until 3 days *after* i 
committed SOLR-9107 to that branch -- but it did start right whne a 
SOLR-9181commit happened.  Likewise the build#7035 speedup was *before* my 
SOLR-9189 commit to disable randomized ssl testing on on master completely - 
and again, coincided with a SOLR-9140 commit.

[~romseygeek] - definitely wnat to draw your attention to this issue -- your 
recent commits may have resvolved the slowdowns (at least on master), but i 
want to make sure you're aware of the situation.


> explosion of timeout related failures in jenkins the past few days
> --
>
> Key: SOLR-9189
> URL: https://issues.apache.org/jira/browse/SOLR-9189
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Critical
>
> In the past few days, something has gone seriously wonky with our jenkins 
> tests -- causing a serious explosion in the number of test failures -- 
> notably do to various sorts of timeouts...
> * "Unable to create core ... Timed out getting coreNodeName for ..."
> * "msg=SolrCore is loading,code=503"
> * "Timeout occured while waiting response from server"
> * "No registered leader was found after waiting for 3ms"
> * "Unable to create core ... Caused by: Timed out getting shard id for core: 
> ..."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7021) Leader will not publish core as active without recovering first, but never recovers

[James Hardwick (JIRA)]

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

James Hardwick commented on SOLR-7021:
--

[~forest_soup] since updating to Solr 5.5+ we haven't had such issues. 

> Leader will not publish core as active without recovering first, but never 
> recovers
> ---
>
> Key: SOLR-7021
> URL: https://issues.apache.org/jira/browse/SOLR-7021
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.10
>Reporter: James Hardwick
>Priority: Critical
>  Labels: recovery, solrcloud, zookeeper
>
> A little background: 1 core solr-cloud cluster across 3 nodes, each with its 
> own shard and each shard with a single replica hence each replica is itself a 
> leader. 
> For reasons we won't get into, we witnessed a shard go down in our cluster. 
> We restarted the cluster but our core/shards still did not come back up. 
> After inspecting the logs, we found this:
> {code}
> 015-01-21 15:51:56,494 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - We are http://xxx.xxx.xxx.35:8081/solr/xyzcore/ and leader is 
> http://xxx.xxx.xxx.35:8081/solr/xyzcore/
> 2015-01-21 15:51:56,496 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - No LogReplay needed for core=xyzcore baseURL=http://xxx.xxx.xxx.35:8081/solr
> 2015-01-21 15:51:56,496 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - I am the leader, no recovery necessary
> 2015-01-21 15:51:56,496 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - publishing core=xyzcore state=active collection=xyzcore
> 2015-01-21 15:51:56,497 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - numShards not found on descriptor - reading it from system property
> 2015-01-21 15:51:56,498 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - publishing core=xyzcore state=down collection=xyzcore
> 2015-01-21 15:51:56,498 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - numShards not found on descriptor - reading it from system property
> 2015-01-21 15:51:56,501 [coreZkRegister-1-thread-2] ERROR core.ZkContainer  - 
> :org.apache.solr.common.SolrException: Cannot publish state of core 'xyzcore' 
> as active without recovering first!
>   at org.apache.solr.cloud.ZkController.publish(ZkController.java:1075)
> {code}
> And at this point the necessary shards never recover correctly and hence our 
> core never returns to a functional state. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8612) DIH JdbcDataSource - statement not always closed

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8612: closing JDBC Statement on exceptions from JdbcDataSource in 
DataImportHandler aka DIH (Kristine Jetzke via Mikhail Khludnev)


> DIH JdbcDataSource - statement not always closed
> 
>
> Key: SOLR-8612
> URL: https://issues.apache.org/jira/browse/SOLR-8612
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.0
>
> Attachments: SOLR-8612.patch, SOLR-8612.patch, SOLR-8612.patch, 
> SOLR-8612.patch, SOLR-8612.patch
>
>
> There are several cases where the Statement used by JdbcDataSource is not 
> closed, potentially resulting in too many open connections:
> - an exception is throw in the {{ResultSetIterator}} constructor
> - the result set is null in the {{ResultSetIterator}} constructor
> - an exception is thrown during import and the import is aborted (onError 
> flag set to abort)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-7317) Remove auto prefix terms

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-7317:


 Summary: Remove auto prefix terms
 Key: LUCENE-7317
 URL: https://issues.apache.org/jira/browse/LUCENE-7317
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Priority: Minor


This was mostly superseded by the new points API so should we remove 
auto-prefix terms?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-5944:


Fixed two bugs:
1. Added a check while writing a document to exclude anything to do with the id 
field.
2. Added an exception when a "set" or "inc" operation is attempted at a 
non-existent document.

Review comments:

bq. * in general, all these tests seem to depend on autoCommit being disabled, 
and use a config that is setup that way, but don't actaully assert that it's 
true in case someone changes the configs in the future
TODO

bq. * TestInPlaceUpdate
Renamed this test to TestInPlaceUpdatesStandalone.

bq. ** SuppressCodecs should be removed
Removed all non 3x, 4x codec suppression. They need to be suppressed as per a 
comment from Mikhail. 
https://issues.apache.org/jira/browse/LUCENE-5189?focusedCommentId=13958205=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13958205

bq. ** should at least have class level javadocs explaining what's being tested
TODO

** testUpdatingDocValues
bq. *** for addAndGetVersion calls where we don't care about the returned 
version, don't bother assigning it to a variable (distracting)
Fixed
bq. *** for addAndGetVersion calls where we do care about the returned version, 
we need check it for every update to that doc...
TODO
bq.  currently version1 is compared to newVersion1 to assert that an update 
incrememnted the version, but in between those 2 updates are 4 other places 
where that document was updated -- we have to assert it has the expected value 
(either the same as before, or new - and if new record it) after all of those 
addAndGetVersion calls, or we can't be sure where/why/how a bug exists if that 
existing comparison fails.
TODO
bq.  ideally we should be asserting the version of every doc when we query 
it right along side the assertion for it's updated "ratings" value
TODO
bq. *** most of the use of "field(ratings)" can probbaly just be replaced with 
"ratings" now that DV are returnable -- although it's nice to have both 
included in the test at least once to demo that both work, but when doing that 
there should be a comment making it clear why
Fixed
** testOnlyPartialUpdatesBetweenCommits
*** ditto comment about checking return value from addAndGetVersion
bq. *** this also seems like a good place to to test if doing a redundent 
atomic update (either via set to the same value or via inc=0) returns a new 
version or not -- should it?
As of now, both will generate a new version. I think "inc" 0 should be dropped, 
and "set" same value should be versioned. I'll check if behaviour in this patch 
is at par with regular atomic updates; and if so, will open a separate issue 
for this later.
bq. ** DocInfo should be a private static class and have some javadocs
Fixed
bq. ** based on how testing has gone so far, and the discover of LUCENE-7301 it 
seems clear that adding even single thread, single node, randomized testing of 
lots of diff types of add/update calls would be good to add
I think we can do the same in TestStressInPlaceUpdates, by randomly setting 
number of writer threads to 1 sometimes.
bq. *** we could refactor/improve the "checkReplay" function I added in the 
last patch to do more testing of a randomly generated Iterable of "commands" 
(commit, doc, doc+atomic mutation, etc...)
TODO
bq. *** and of course: improve checkReplay to verify RTG against hte uncommited 
model as well
I couldn't find a way to do this for the TestInPlaceUpdate (now called 
TestInPlaceUpdatesStandalone in this patch). This is based on SolrTestCaseJ4.

bq. *** testReplayFromFile and getSDdoc should probably go away once we have 
more structured tests for doing this
Fixed

bq. ** createMap can be elimianted -- callers can just use 
SolrTestCaseJ4.map(...)
Fixed

bq. ** In general the tests in this class should include more queries / sorting 
against the updated docvalues field after commits to ensure that the updated 
value is searchable & sortable
TODO

bq. ** Likewise the test methods in this class should probably have a lot more 
RTG checks -- with filter queries that constrain against the updated docvalues 
field, and checks of the expected version field -- to ensure that is all 
working properly.
Couldn't figure out how to do RTGs with this test, but will check RTGs + filter 
queries in the TestInPlaceUpdatesDistrib test (which was formerly 
InPlaceUpdateDistribTest)

bq. * InPlaceUpdateDistribTest
Renamed to TestInPlaceUpdatesDistrib now

bq. ** SuppressCodecs should be removed
3x and 4x codec suppressions cannot be removed.
bq. ** should at least have class level javadocs explaining what's being tested
TODO
bq. ** Once LUCENE-7301 is fixed and we can demonstate that this passes 
reliably all of the time, we should ideally refactor this to subclass 
SolrCloudTestCase
TODO
bq. ** in general, 

[jira] [Commented] (SOLR-9189) explosion of timeout related failures in jenkins the past few days

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9189: temp disable randomized ssl to get to bottom of recent explosion of 
timeout related failures in jenkins builds


> explosion of timeout related failures in jenkins the past few days
> --
>
> Key: SOLR-9189
> URL: https://issues.apache.org/jira/browse/SOLR-9189
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Critical
>
> In the past few days, something has gone seriously wonky with our jenkins 
> tests -- causing a serious explosion in the number of test failures -- 
> notably do to various sorts of timeouts...
> * "Unable to create core ... Timed out getting coreNodeName for ..."
> * "msg=SolrCore is loading,code=503"
> * "Timeout occured while waiting response from server"
> * "No registered leader was found after waiting for 3ms"
> * "Unable to create core ... Caused by: Timed out getting shard id for core: 
> ..."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8612) DIH JdbcDataSource - statement not always closed

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8612: closing JDBC Statement on exceptions from JdbcDataSource in 
DataImportHandler aka DIH (Kristine Jetzke via Mikhail Khludnev)


> DIH JdbcDataSource - statement not always closed
> 
>
> Key: SOLR-8612
> URL: https://issues.apache.org/jira/browse/SOLR-8612
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.0
>
> Attachments: SOLR-8612.patch, SOLR-8612.patch, SOLR-8612.patch, 
> SOLR-8612.patch, SOLR-8612.patch
>
>
> There are several cases where the Statement used by JdbcDataSource is not 
> closed, potentially resulting in too many open connections:
> - an exception is throw in the {{ResultSetIterator}} constructor
> - the result set is null in the {{ResultSetIterator}} constructor
> - an exception is thrown during import and the import is aborted (onError 
> flag set to abort)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/838/
Java: 64bit/jdk-9-ea+121 -XX:-UseCompressedOops -XX:+UseG1GC

22 tests failed.
FAILED:  org.apache.solr.schema.TestCloudManagedSchema.test

Error Message:
Schema resource name differs from expected name expected:<[managed-schema]> but 
was:<[schema.xml]>

Stack Trace:
org.junit.ComparisonFailure: Schema resource name differs from expected name 
expected:<[managed-schema]> but was:<[schema.xml]>
at 
__randomizedtesting.SeedInfo.seed([D9809254EDA791CE:51D4AD8E435BFC36]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.solr.schema.TestCloudManagedSchema.test(TestCloudManagedSchema.java:68)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  

[jira] [Updated] (SOLR-9187) Export handler does not export date/tdate or boolean

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-9187:
-
Attachment: SOLR-9187.patch

Running through precommit and test now, I think it's ready if I get through 
those.

> Export handler does not export date/tdate or boolean
> 
>
> Key: SOLR-9187
> URL: https://issues.apache.org/jira/browse/SOLR-9187
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-9187.patch
>
>
> Since these can be DV fields it seems like it should. The first-level problem 
> is that SortingResponseWriter doesn't check for date types as a legal export 
> value. Whether there are repercussions elsewhere I don't know yet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9190) upgrade from solr4 to solr-5.5.0

[Lena Gurevich (JIRA)]

Lena Gurevich created SOLR-9190:
---

 Summary: upgrade from solr4 to solr-5.5.0
 Key: SOLR-9190
 URL: https://issues.apache.org/jira/browse/SOLR-9190
 Project: Solr
  Issue Type: Bug
 Environment: solr-5.5.0
Reporter: Lena Gurevich


Installed solr-5.5.0. Example shard works fine. No matter what I do for 
existing shards, I get 
org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
org/apache/solr/util/plugin/SolrCoreAware
 in solrconfig.xml I put the first line:

SolrCoreAware.class is a part of solr-core-5.5.o.jar





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Solr-NightlyTests-master - Build # 1034 - Still Failing

[Chris Hostetter]

something seriously fucked up with jenkins tests timing out the past few 
days ... not sure if i caused it, so i'm going to be paranoied and assume 
i did -- details: https://issues.apache.org/jira/browse/SOLR-9189


: Date: Mon, 6 Jun 2016 15:15:50 + (UTC)
: From: Apache Jenkins Server 
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: [JENKINS] Lucene-Solr-NightlyTests-master - Build # 1034 - Still
: Failing
: 
: Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1034/
: 
: 44 tests failed.
: FAILED:  org.apache.solr.cloud.AliasIntegrationTest.test
: 
: Error Message:
: Error from server at https://127.0.0.1:58574/collection1: Expected mime type 
application/octet-stream but got text/html.Error 
503HTTP ERROR: 503 Problem accessing 
/collection1/update. Reason: 
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg=SolrCore
 is loading,code=503} http://eclipse.org/jetty;>Powered by Jetty:// 9.3.8.v20160314 
  
: 
: Stack Trace:
: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:58574/collection1: Expected mime type 
application/octet-stream but got text/html. 
: 
: 
: Error 503 
: 
: 
: HTTP ERROR: 503
: Problem accessing /collection1/update. Reason:
: 
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg=SolrCore
 is loading,code=503}
: http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.8.v20160314
: 
: 
: 
:   at 
__randomizedtesting.SeedInfo.seed([F3664AD702923DEB:7B32750DAC6E5013]:0)
:   at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:574)
:   at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
:   at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
:   at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
:   at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:895)
:   at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:858)
:   at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:873)
:   at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.del(AbstractFullDistribZkTestBase.java:835)
:   at 
org.apache.solr.cloud.AliasIntegrationTest.test(AliasIntegrationTest.java:71)
:   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:1764)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
:   at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
:   at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
:   at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
:   at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
:   at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
:   at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
:   at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
:   at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
:   at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
:   at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
:   at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
:   at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
:   at 

[jira] [Comment Edited] (SOLR-9189) explosion of timeout related failures in jenkins the past few days

[Hoss Man (JIRA)]

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

Hoss Man edited comment on SOLR-9189 at 6/6/16 5:55 PM:


My initial gut paranoia skimming the jenkins emails this morning was to assume 
that this might be because of SOLR-9107 / SOLR-5776 -- the hypothosis being: 
"The increased randomized use of ssl (factoring in tests.nightly / 
tests.multiplier) is causing more tests to slow down due to the crypto 
calculations"

... but that hypothosis seems weak when i started looking at the logs -- there 
is a "Randomized ssl" line as part of the logs for every SolrTestCaseJ4 
subclass showing if ssl is being used or not...

* http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/834/
** 25 test failures
** only 7 of those were using ssl
* https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1034/
** 44 test failures
** only 17 of those were using ssl

...even if we assume every test failure where ssl was in use was directly 
caused by ssl, that still leaves a really high increase in the number of failed 
tests in those two runs.

So my ammended (paranoid) hypothosis is "The increased randomized use of ssl 
(factoring in tests.nightly / tests.multiplier) is causing more tests to slow 
down due to the crypto calculations *EVEN IN OTHER TESTS AT THE SAME TIME DUE 
TO CPU STARVATION*"

I'm going to commit a blanket disable of all SSL randomization _on master_ ASAP 
to test this hypothosis.

Part of me feels like this is an overkill reaction, and that a more rational 
response would simply be to undo the "increased odds of using ssl" portion of 
SOLR-9107 -- but I'd really like to get a difinitive understanding of wether 
SSL usage is really having such a seriously pronounced affect on other tests in 
the same jenkins run -- OR -- *is it just a red herring, and some other recent 
change has caused serious timeout issues?*


EDIT: clarified jira refrences



was (Author: hossman):

My initial gut paranoia skimming the jenkins emails this morning was to assume 
that this might be because of SOLR-5776 -- the hypothosis being: "The increased 
randomized use of ssl (factoring in tests.nightly / tests.multiplier) is 
causing more tests to slow down due to the crypto calculations"

... but that hypothosis seems weak when i started looking at the logs -- there 
is a "Randomized ssl" line as part of the logs for every SolrTestCaseJ4 
subclass showing if ssl is being used or not...

* http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/834/
** 25 test failures
** only 7 of those were using ssl
* https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1034/
** 44 test failures
** only 17 of those were using ssl

...even if we assume every test failure where ssl was in use was directly 
caused by ssl, that still leaves a really high increase in the number of failed 
tests in those two runs.

So my ammended (paranoid) hypothosis is "The increased randomized use of ssl 
(factoring in tests.nightly / tests.multiplier) is causing more tests to slow 
down due to the crypto calculations *EVEN IN OTHER TESTS AT THE SAME TIME DUE 
TO CPU STARVATION*"

I'm going to commit a blanket disable of all SSL randomization _on master_ ASAP 
to test this hypothosis.

Part of me feels like this is an overkill reaction, and that a more rational 
response would simply be to undo the "increased odds of using ssl" portion of 
SOLR-5776 -- but I'd really like to get a difinitive understanding of wether 
SSL usage is really having such a seriously pronounced affect on other tests in 
the same jenkins run -- OR -- *is it just a red herring, and some other recent 
change has caused serious timeout issues?*



> explosion of timeout related failures in jenkins the past few days
> --
>
> Key: SOLR-9189
> URL: https://issues.apache.org/jira/browse/SOLR-9189
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Critical
>
> In the past few days, something has gone seriously wonky with our jenkins 
> tests -- causing a serious explosion in the number of test failures -- 
> notably do to various sorts of timeouts...
> * "Unable to create core ... Timed out getting coreNodeName for ..."
> * "msg=SolrCore is loading,code=503"
> * "Timeout occured while waiting response from server"
> * "No registered leader was found after waiting for 3ms"
> * "Unable to create core ... Caused by: Timed out getting shard id for core: 
> ..."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9189) explosion of timeout related failures in jenkins the past few days

[Hoss Man (JIRA)]

Hoss Man created SOLR-9189:
--

 Summary: explosion of timeout related failures in jenkins the past 
few days
 Key: SOLR-9189
 URL: https://issues.apache.org/jira/browse/SOLR-9189
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
Priority: Critical



In the past few days, something has gone seriously wonky with our jenkins tests 
-- causing a serious explosion in the number of test failures -- notably do to 
various sorts of timeouts...

* "Unable to create core ... Timed out getting coreNodeName for ..."
* "msg=SolrCore is loading,code=503"
* "Timeout occured while waiting response from server"
* "No registered leader was found after waiting for 3ms"
* "Unable to create core ... Caused by: Timed out getting shard id for core: 
..."




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9189) explosion of timeout related failures in jenkins the past few days

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9189:



My initial gut paranoia skimming the jenkins emails this morning was to assume 
that this might be because of SOLR-5776 -- the hypothosis being: "The increased 
randomized use of ssl (factoring in tests.nightly / tests.multiplier) is 
causing more tests to slow down due to the crypto calculations"

... but that hypothosis seems weak when i started looking at the logs -- there 
is a "Randomized ssl" line as part of the logs for every SolrTestCaseJ4 
subclass showing if ssl is being used or not...

* http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/834/
** 25 test failures
** only 7 of those were using ssl
* https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1034/
** 44 test failures
** only 17 of those were using ssl

...even if we assume every test failure where ssl was in use was directly 
caused by ssl, that still leaves a really high increase in the number of failed 
tests in those two runs.

So my ammended (paranoid) hypothosis is "The increased randomized use of ssl 
(factoring in tests.nightly / tests.multiplier) is causing more tests to slow 
down due to the crypto calculations *EVEN IN OTHER TESTS AT THE SAME TIME DUE 
TO CPU STARVATION*"

I'm going to commit a blanket disable of all SSL randomization _on master_ ASAP 
to test this hypothosis.

Part of me feels like this is an overkill reaction, and that a more rational 
response would simply be to undo the "increased odds of using ssl" portion of 
SOLR-5776 -- but I'd really like to get a difinitive understanding of wether 
SSL usage is really having such a seriously pronounced affect on other tests in 
the same jenkins run -- OR -- *is it just a red herring, and some other recent 
change has caused serious timeout issues?*



> explosion of timeout related failures in jenkins the past few days
> --
>
> Key: SOLR-9189
> URL: https://issues.apache.org/jira/browse/SOLR-9189
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Critical
>
> In the past few days, something has gone seriously wonky with our jenkins 
> tests -- causing a serious explosion in the number of test failures -- 
> notably do to various sorts of timeouts...
> * "Unable to create core ... Timed out getting coreNodeName for ..."
> * "msg=SolrCore is loading,code=503"
> * "Timeout occured while waiting response from server"
> * "No registered leader was found after waiting for 3ms"
> * "Unable to create core ... Caused by: Timed out getting shard id for core: 
> ..."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7374) Backup/Restore should provide a param for specifying the directory implementation it should use

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7374:
---

I'm try to pinpoint if this has destabilized TestReplicationHandlerBackup or if 
it was before. Otherwise this is looking pretty good, just want to do a little 
manual testing. Anything else would be nitpicky mostly, but perhaps more 
comments coming.

> Backup/Restore should provide a param for specifying the directory 
> implementation it should use
> ---
>
> Key: SOLR-7374
> URL: https://issues.apache.org/jira/browse/SOLR-7374
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Assignee: Mark Miller
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch
>
>
> Currently when we create a backup we use SimpleFSDirectory to write the 
> backup indexes. Similarly during a restore we open the index using 
> FSDirectory.open . 
> We should provide a param called {{directoryImpl}} or {{type}} which will be 
> used to specify the Directory implementation to backup the index. 
> Likewise during a restore you would need to specify the directory impl which 
> was used during backup so that the index can be opened correctly.
> This param will address the problem that currently if a user is running Solr 
> on HDFS there is no way to use the backup/restore functionality as the 
> directory is hardcoded.
> With this one could be running Solr on a local FS but backup the index on 
> HDFS etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-5944:
---
Attachment: SOLR-5944.patch

Updated the patch. Fixed some issues from Hoss' comments. Some nocommits are 
remaining. I'll reply to Hoss' suggestions in-line shortly.
Couple of error handling fixes, but mostly changes to test suites.

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: DUP.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.62D328FA1DEA57FD.fail2.txt, 
> hoss.62D328FA1DEA57FD.fail3.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7316) Geo3d test failure

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7316:
-

Looks like this is a problem because of minimum resolution.  Here's some 
debugging output:

{code}
   [junit4]   1> Looking for coplanar points for: [[lat=0.0425265613312593, 
lon=0.0([X=1.0002076326868337, Y=0.0, Z=0.042561051669501374])], [lat=0.0, 
lon=-1.7156310907312492E-12([X=1.0011188539924791, Y=-1.7175506314267352E-12, 
Z=0.0])], [lat=-0.7766317703682181, 
lon=3.141592653589793([X=-0.7128972529667801, Y=8.730473389667082E-17, 
Z=-0.7005064828988063])]]
   [junit4]   1> planeToFind.evaluate(start) = 0.0
   [junit4]   1> planeToFind.evaluate(end) = 0.0
   [junit4]   1>  failing because planeToFind = [A=1.7156310907312492E-12, 
B=1.0; C=-4.031825447240733E-11; D=0.0] doesn't contain 
[lat=-0.7766317703682181, lon=3.141592653589793([X=-0.7128972529667801, 
Y=8.730473389667082E-17, Z=-0.7005064828988063])]; off by 2.7020217250132315E-11
   [junit4]   1> planeToFind.evaluate(start) = 0.0
   [junit4]   1> planeToFind.evaluate(end) = -2.0194839173657902E-28
   [junit4]   1>  failing because planeToFind = [A=1.7156310907312492E-12, 
B=1.0; C=-1.7458530603341764E-12; D=0.0] doesn't contain 
[lat=0.0425265613312593, lon=0.0([X=1.0002076326868337, Y=0.0, 
Z=0.042561051669501374])]; off by 1.6416819695159931E-12
   [junit4]   1> planeToFind.evaluate(start) = 0.0
   [junit4]   1> planeToFind.evaluate(end) = -7.703719777548943E-34
   [junit4]   1>  failing because planeToFind = [A=5.543375111216114E-18, 
B=-1.0; C=-1.3027230013345064E-16; D=0.0] doesn't contain [lat=0.0, 
lon=-1.7156310907312492E-12([X=1.0011188539924791, Y=-1.7175506314267352E-12, 
Z=0.0])]; off by 1.7175561810040737E-12
   [junit4]   1> ... not coplanar
{code}

Note that the amount it is "off" by is just larger than 
Vector.MINIMUM_RESOLUTION (1e-12).  The triangle is therefore barely not 
degenerate, but it is close enough to degenerate to make plane sidedness not 
work well in determining inclusion of a given point.

I solved a similar problem for GeoBBox shapes by computing the bounds of 
intersections as well as of edges and points.  The only other solution is to 
create a pair of cutoff planes for each edge of the polygon.  That would be a 
more accurate solution that we might want to adopt in the future, since acute 
angles between planes otherwise will allow quite a bit of "leakage" of places 
that shouldn't legitimately be "in set", but are, due to the MINIMUM_RESOLUTION 
value.

> Geo3d test failure
> --
>
> Key: LUCENE-7316
> URL: https://issues.apache.org/jira/browse/LUCENE-7316
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
> Attachments: LUCENE-7316.patch
>
>
> Reproducible on master with:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations 
> -Dtests.seed=EEA08DD7FAE3C688 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.directory=MMapDirectory -Dtests.locale=es 
> -Dtests.timezone=America/Manaus -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}
> Note: I was initially unable to reproduce this, until I pulled up code that 
> [~mikemccand] recently committed.  It seems possible that encoding/decoding 
> changes are triggering it.  Of specific concern is the new way 
> maximum/minimum decoded values are computed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Apache Jenkins Server]

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

44 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.test

Error Message:
Error from server at https://127.0.0.1:58574/collection1: Expected mime type 
application/octet-stream but got text/html.Error 
503HTTP ERROR: 503 Problem accessing 
/collection1/update. Reason: 
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg=SolrCore
 is loading,code=503} http://eclipse.org/jetty;>Powered by Jetty:// 9.3.8.v20160314 
  

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:58574/collection1: Expected mime type 
application/octet-stream but got text/html. 


Error 503 


HTTP ERROR: 503
Problem accessing /collection1/update. Reason:

{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg=SolrCore
 is loading,code=503}
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.8.v20160314



at 
__randomizedtesting.SeedInfo.seed([F3664AD702923DEB:7B32750DAC6E5013]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:574)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:895)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:858)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:873)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.del(AbstractFullDistribZkTestBase.java:835)
at 
org.apache.solr.cloud.AliasIntegrationTest.test(AliasIntegrationTest.java:71)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

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

[Policeman Jenkins Server]

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

21 tests failed.
FAILED:  org.apache.solr.cloud.BasicDistributedZk2Test.test

Error Message:
Error from server at http://127.0.0.1:64357: Error CREATEing SolrCore 
'onenodecollectioncore': Unable to create core [onenodecollectioncore] Caused 
by: Timed out getting coreNodeName for onenodecollectioncore

Stack Trace:
java.lang.AssertionError: Error from server at http://127.0.0.1:64357: Error 
CREATEing SolrCore 'onenodecollectioncore': Unable to create core 
[onenodecollectioncore] Caused by: Timed out getting coreNodeName for 
onenodecollectioncore
at 
__randomizedtesting.SeedInfo.seed([2E1D8F50143FC51A:A649B08ABAC3A8E2]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.BasicDistributedZk2Test.testNodeWithoutCollectionForwarding(BasicDistributedZk2Test.java:162)
at 
org.apache.solr.cloud.BasicDistributedZk2Test.test(BasicDistributedZk2Test.java:71)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Updated] (SOLR-9187) Export handler does not export date/tdate or boolean

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-9187:
-
Summary: Export handler does not export date/tdate or boolean  (was: Export 
handler does not export date/tdate)

> Export handler does not export date/tdate or boolean
> 
>
> Key: SOLR-9187
> URL: https://issues.apache.org/jira/browse/SOLR-9187
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>
> Since these can be DV fields it seems like it should. The first-level problem 
> is that SortingResponseWriter doesn't check for date types as a legal export 
> value. Whether there are repercussions elsewhere I don't know yet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LUCENE-7132) BooleanQuery scores can be diff for same docs+sim when using coord (disagree with Explanation which doesn't change)

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-7132.

Resolution: Fixed

Thanks everyone.

> BooleanQuery scores can be diff for same docs+sim when using coord (disagree 
> with Explanation which doesn't change)
> ---
>
> Key: LUCENE-7132
> URL: https://issues.apache.org/jira/browse/LUCENE-7132
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5
>Reporter: Ahmet Arslan
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 6.1, master (7.0)
>
> Attachments: LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, 
> LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, 
> SOLR-8884.patch, SOLR-8884.patch, debug.xml
>
>
> Some of the folks 
> [reported|http://find.searchhub.org/document/80666f5c3b86ddda] that sometimes 
> explain's score can be different than the score requested by fields 
> parameter. Interestingly, Explain's scores would create a different ranking 
> than the original result list. This is something users experience, but it 
> cannot be re-produced deterministically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7132) BooleanQuery scores can be diff for same docs+sim when using coord (disagree with Explanation which doesn't change)

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7132: BooleanQuery sometimes assigned the wrong score when ranges of 
documents had only one clause matching while other ranges had more than one 
clause matchng


> BooleanQuery scores can be diff for same docs+sim when using coord (disagree 
> with Explanation which doesn't change)
> ---
>
> Key: LUCENE-7132
> URL: https://issues.apache.org/jira/browse/LUCENE-7132
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5
>Reporter: Ahmet Arslan
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 6.1, master (7.0)
>
> Attachments: LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, 
> LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, 
> SOLR-8884.patch, SOLR-8884.patch, debug.xml
>
>
> Some of the folks 
> [reported|http://find.searchhub.org/document/80666f5c3b86ddda] that sometimes 
> explain's score can be different than the score requested by fields 
> parameter. Interestingly, Explain's scores would create a different ranking 
> than the original result list. This is something users experience, but it 
> cannot be re-produced deterministically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7132) BooleanQuery scores can be diff for same docs+sim when using coord (disagree with Explanation which doesn't change)

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7132: BooleanQuery sometimes assigned the wrong score when ranges of 
documents had only one clause matching while other ranges had more than one 
clause matchng


> BooleanQuery scores can be diff for same docs+sim when using coord (disagree 
> with Explanation which doesn't change)
> ---
>
> Key: LUCENE-7132
> URL: https://issues.apache.org/jira/browse/LUCENE-7132
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5
>Reporter: Ahmet Arslan
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 6.1, master (7.0)
>
> Attachments: LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, 
> LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, 
> SOLR-8884.patch, SOLR-8884.patch, debug.xml
>
>
> Some of the folks 
> [reported|http://find.searchhub.org/document/80666f5c3b86ddda] that sometimes 
> explain's score can be different than the score requested by fields 
> parameter. Interestingly, Explain's scores would create a different ranking 
> than the original result list. This is something users experience, but it 
> cannot be re-produced deterministically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7276) Add an optional reason to the MatchNoDocsQuery

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7276:


It definitely is odd, and I don't like it, but I don't know how else to make 
the test happy on this weird corner case.

I will put a comment attempting to explain the situation.

> Add an optional reason to the MatchNoDocsQuery
> --
>
> Key: LUCENE-7276
> URL: https://issues.apache.org/jira/browse/LUCENE-7276
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Ferenczi Jim
>Priority: Minor
>  Labels: patch
> Attachments: LUCENE-7276.patch, LUCENE-7276.patch, LUCENE-7276.patch, 
> LUCENE-7276.patch
>
>
> It's sometimes difficult to debug a query that results in a MatchNoDocsQuery. 
> The MatchNoDocsQuery is always rewritten in an empty boolean query.
> This patch adds an optional reason and implements a weight in order to keep 
> track of the reason why the query did not match any document. The reason is 
> printed on toString and when an explanation for noMatch is asked.  
> For instance the query:
> new MatchNoDocsQuery("Field not found").toString()
> => 'MatchNoDocsQuery["field 'title' not found"]'



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/837/
Java: 64bit/jdk-9-ea+121 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

20 tests failed.
FAILED:  org.apache.solr.schema.TestBulkSchemaConcurrent.test

Error Message:
[[], [], [], [["Error reading input String Can't find resource 'schema.xml' in 
classpath or '/configs/conf1', 
cwd=/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J1"]],
 []]

Stack Trace:
java.lang.AssertionError: [[], [], [], [["Error reading input String Can't find 
resource 'schema.xml' in classpath or '/configs/conf1', 
cwd=/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J1"]],
 []]
at 
__randomizedtesting.SeedInfo.seed([13E501B446D4C3CA:9BB13E6EE828AE32]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.schema.TestBulkSchemaConcurrent.test(TestBulkSchemaConcurrent.java:115)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (LUCENE-7132) BooleanQuery scores can be diff for same docs+sim when using coord (disagree with Explanation which doesn't change)

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7132:


Thanks [~jpountz] and [~hossman], I'll commit the last patch.

> BooleanQuery scores can be diff for same docs+sim when using coord (disagree 
> with Explanation which doesn't change)
> ---
>
> Key: LUCENE-7132
> URL: https://issues.apache.org/jira/browse/LUCENE-7132
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5
>Reporter: Ahmet Arslan
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 6.1, master (7.0)
>
> Attachments: LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, 
> LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, 
> SOLR-8884.patch, SOLR-8884.patch, debug.xml
>
>
> Some of the folks 
> [reported|http://find.searchhub.org/document/80666f5c3b86ddda] that sometimes 
> explain's score can be different than the score requested by fields 
> parameter. Interestingly, Explain's scores would create a different ranking 
> than the original result list. This is something users experience, but it 
> cannot be re-produced deterministically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7132) BooleanQuery scores can be diff for same docs+sim when using coord (disagree with Explanation which doesn't change)

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7132:
--

Thanks [~mikemccand] and Hoss for digging this sneaky bug! +1 to the patch

bq. I think this bug is serious enough that we should be sure to get it into 
6.1.0 ... I marked blocker.

+1

> BooleanQuery scores can be diff for same docs+sim when using coord (disagree 
> with Explanation which doesn't change)
> ---
>
> Key: LUCENE-7132
> URL: https://issues.apache.org/jira/browse/LUCENE-7132
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5
>Reporter: Ahmet Arslan
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 6.1, master (7.0)
>
> Attachments: LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, 
> LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, LUCENE-7132.patch, 
> SOLR-8884.patch, SOLR-8884.patch, debug.xml
>
>
> Some of the folks 
> [reported|http://find.searchhub.org/document/80666f5c3b86ddda] that sometimes 
> explain's score can be different than the score requested by fields 
> parameter. Interestingly, Explain's scores would create a different ranking 
> than the original result list. This is something users experience, but it 
> cannot be re-produced deterministically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7021) Leader will not publish core as active without recovering first, but never recovers

[Forest Soup (JIRA)]

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

Forest Soup commented on SOLR-7021:
---

Is there any plan to fix this? We found same log in v5.3.2 solrcloud.

> Leader will not publish core as active without recovering first, but never 
> recovers
> ---
>
> Key: SOLR-7021
> URL: https://issues.apache.org/jira/browse/SOLR-7021
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.10
>Reporter: James Hardwick
>Priority: Critical
>  Labels: recovery, solrcloud, zookeeper
>
> A little background: 1 core solr-cloud cluster across 3 nodes, each with its 
> own shard and each shard with a single replica hence each replica is itself a 
> leader. 
> For reasons we won't get into, we witnessed a shard go down in our cluster. 
> We restarted the cluster but our core/shards still did not come back up. 
> After inspecting the logs, we found this:
> {code}
> 015-01-21 15:51:56,494 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - We are http://xxx.xxx.xxx.35:8081/solr/xyzcore/ and leader is 
> http://xxx.xxx.xxx.35:8081/solr/xyzcore/
> 2015-01-21 15:51:56,496 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - No LogReplay needed for core=xyzcore baseURL=http://xxx.xxx.xxx.35:8081/solr
> 2015-01-21 15:51:56,496 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - I am the leader, no recovery necessary
> 2015-01-21 15:51:56,496 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - publishing core=xyzcore state=active collection=xyzcore
> 2015-01-21 15:51:56,497 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - numShards not found on descriptor - reading it from system property
> 2015-01-21 15:51:56,498 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - publishing core=xyzcore state=down collection=xyzcore
> 2015-01-21 15:51:56,498 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - numShards not found on descriptor - reading it from system property
> 2015-01-21 15:51:56,501 [coreZkRegister-1-thread-2] ERROR core.ZkContainer  - 
> :org.apache.solr.common.SolrException: Cannot publish state of core 'xyzcore' 
> as active without recovering first!
>   at org.apache.solr.cloud.ZkController.publish(ZkController.java:1075)
> {code}
> And at this point the necessary shards never recover correctly and hence our 
> core never returns to a functional state. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9140) Replace some state polling with CollectionStateWatchers

[ASF subversion and git services (JIRA)]

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

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

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

Revert "SOLR-9140: Replace some zk state polling with CollectionStateWatchers"

There's still some places where notifications can be missed, so I'm reverting
this until those are fixed.

This reverts commit d550b1ca43c7c523b71b4540edef217036421f9e.


> Replace some state polling with CollectionStateWatchers
> ---
>
> Key: SOLR-9140
> URL: https://issues.apache.org/jira/browse/SOLR-9140
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 6.1
>
> Attachments: SOLR-9140.patch, SOLR-9140.patch
>
>
> There are a few places in ZkController and the collection processing code 
> that directly query ZK for collection state, and then wait and poll for 
> expected state changes.  We can now replace these with 
> CollectionStateWatchers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Reopened] (SOLR-9140) Replace some state polling with CollectionStateWatchers

[Alan Woodward (JIRA)]

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

Alan Woodward reopened SOLR-9140:
-

This is causing a bunch of test failures because there are still some 
notifications that aren't being picked up by the state watcher code.  I'm going 
to revert until I've worked out where they're being dropped.

> Replace some state polling with CollectionStateWatchers
> ---
>
> Key: SOLR-9140
> URL: https://issues.apache.org/jira/browse/SOLR-9140
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 6.1
>
> Attachments: SOLR-9140.patch, SOLR-9140.patch
>
>
> There are a few places in ZkController and the collection processing code 
> that directly query ZK for collection state, and then wait and poll for 
> expected state changes.  We can now replace these with 
> CollectionStateWatchers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7316) Geo3d test failure

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7316:
-

The code looks for legality in the following way:

{code}
  // Look for coplanarity; abort if so
  for (int i = 0; i < points.size(); i++) {
final GeoPoint start = points.get(i);
final GeoPoint end = points.get(getLegalIndex(i + 1, points.size()));
// We have to find the next point that is not on the plane between 
start and end.
// If there is no such point, it's an error.
final Plane planeToFind = new Plane(start, end);
int endPointIndex = -1;
for (int j = 0; j < points.size(); j++) {
  final int index = getLegalIndex(j + i + 2, points.size());
  if (!planeToFind.evaluateIsZero(points.get(index))) {
endPointIndex = index;
break;
  }
}
if (endPointIndex == -1) {
  return false;
}
  }
{code}

This should have been sufficient to prevent the creation of the degenerate 
triangle we are seeing.  I will need to figure out why it didn't.


> Geo3d test failure
> --
>
> Key: LUCENE-7316
> URL: https://issues.apache.org/jira/browse/LUCENE-7316
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
> Attachments: LUCENE-7316.patch
>
>
> Reproducible on master with:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations 
> -Dtests.seed=EEA08DD7FAE3C688 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.directory=MMapDirectory -Dtests.locale=es 
> -Dtests.timezone=America/Manaus -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}
> Note: I was initially unable to reproduce this, until I pulled up code that 
> [~mikemccand] recently committed.  It seems possible that encoding/decoding 
> changes are triggering it.  Of specific concern is the new way 
> maximum/minimum decoded values are computed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3321 - Still Failing!

[Policeman Jenkins Server]

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

13 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

Error Message:
Error from server at http://127.0.0.1:59096/collection1: Expected mime type 
application/octet-stream but got text/html.Error 
503HTTP ERROR: 503 Problem accessing 
/collection1/update. Reason: 
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg=SolrCore
 is loading,code=503} http://eclipse.org/jetty;>Powered by Jetty:// 9.3.8.v20160314 
  

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


Error 503 


HTTP ERROR: 503
Problem accessing /collection1/update. Reason:

{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg=SolrCore
 is loading,code=503}
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.8.v20160314



at 
__randomizedtesting.SeedInfo.seed([DDBEA211FDC1830E:55EA9DCB533DEEF6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:574)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:895)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:858)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:873)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.del(AbstractFullDistribZkTestBase.java:835)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:131)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+121) - Build # 16929 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16929/
Java: 32bit/jdk-9-ea+121 -client -XX:+UseSerialGC

17 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.LeaderElectionIntegrationTest

Error Message:
19 threads leaked from SUITE scope at 
org.apache.solr.cloud.LeaderElectionIntegrationTest: 1) Thread[id=69345, 
name=zkCallback-18634-thread-2, state=TIMED_WAITING, 
group=TGRP-LeaderElectionIntegrationTest] at 
jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:230)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base@9-ea/SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base@9-ea/SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(java.base@9-ea/SynchronousQueue.java:937)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(java.base@9-ea/ThreadPoolExecutor.java:1082)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1143)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
 at java.lang.Thread.run(java.base@9-ea/Thread.java:843)2) 
Thread[id=69315, name=Thread-1223, state=WAITING, 
group=TGRP-LeaderElectionIntegrationTest] at 
java.lang.Object.wait(java.base@9-ea/Native Method) at 
java.lang.Object.wait(java.base@9-ea/Object.java:516) at 
org.apache.solr.core.CloserThread.run(CoreContainer.java:1276)3) 
Thread[id=69333, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-LeaderElectionIntegrationTest] at 
java.lang.Thread.sleep(java.base@9-ea/Native Method) at 
org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.lang.Thread.run(java.base@9-ea/Thread.java:843)4) 
Thread[id=69346, name=zkCallback-18634-thread-3, state=TIMED_WAITING, 
group=TGRP-LeaderElectionIntegrationTest] at 
jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:230)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base@9-ea/SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base@9-ea/SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(java.base@9-ea/SynchronousQueue.java:937)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(java.base@9-ea/ThreadPoolExecutor.java:1082)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1143)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
 at java.lang.Thread.run(java.base@9-ea/Thread.java:843)5) 
Thread[id=69347, name=zkCallback-18634-thread-4, state=TIMED_WAITING, 
group=TGRP-LeaderElectionIntegrationTest] at 
jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:230)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base@9-ea/SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base@9-ea/SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(java.base@9-ea/SynchronousQueue.java:937)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(java.base@9-ea/ThreadPoolExecutor.java:1082)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1143)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
 at java.lang.Thread.run(java.base@9-ea/Thread.java:843)6) 
Thread[id=69342, 
name=OverseerHdfsCoreFailoverThread-96023320106041347-127.0.0.1:7000_solr-n_00,
 state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.] at 
java.lang.Thread.sleep(java.base@9-ea/Native Method) at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137)
 at java.lang.Thread.run(java.base@9-ea/Thread.java:843)7) 
Thread[id=69314, 
name=OverseerHdfsCoreFailoverThread-96023299104047107-127.0.0.1:7000_solr-n_00,
 state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.] at 
java.lang.Thread.sleep(java.base@9-ea/Native Method) at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137)
 at java.lang.Thread.run(java.base@9-ea/Thread.java:843)8) 
Thread[id=69338, 

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_92) - Build # 231 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/231/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseParallelGC

14 tests failed.
FAILED:  org.apache.solr.cloud.BasicZkTest.testBasic

Error Message:
No registered leader was found after waiting for 3ms , collection: 
collection1 slice: shard1

Stack Trace:
org.apache.solr.common.SolrException: No registered leader was found after 
waiting for 3ms , collection: collection1 slice: shard1
at 
__randomizedtesting.SeedInfo.seed([78EC2510F215C391:D31638052DC945BF]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderRetry(ZkStateReader.java:718)
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderUrl(ZkStateReader.java:685)
at org.apache.solr.cloud.BasicZkTest.testBasic(BasicZkTest.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
Error from server at 

[JENKINS] Lucene-Artifacts-6.x - Build # 78 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Artifacts-6.x/78/

No tests ran.

Build Log:
[...truncated 8036 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-6.x/lucene/build.xml:480: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-6.x/lucene/common-build.xml:2496:
 Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-6.x/lucene/build/docs/changes/jiraVersionList.json

Total time: 4 minutes 34 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any




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

[JENKINS] Solr-Artifacts-6.x - Build # 78 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-Artifacts-6.x/78/

No tests ran.

Build Log:
[...truncated 8818 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/build.xml:520: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/build.xml:422: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/test-framework/build.xml:100:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/lucene/common-build.xml:533:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/lucene/common-build.xml:528:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/lucene/build.xml:480: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/lucene/common-build.xml:2496:
 Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to 
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/lucene/build/docs/changes/jiraVersionList.json

Total time: 8 minutes 25 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any




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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 40507 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (20.6 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 28.6 MB in 0.02 sec (1187.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 63.0 MB in 0.06 sec (1116.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 73.6 MB in 0.07 sec (1121.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6009 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6009 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 221 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (26.5 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.0.0-src.tgz...
   [smoker] 37.8 MB in 0.82 sec (46.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.tgz...
   [smoker] 132.4 MB in 2.03 sec (65.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.zip...
   [smoker] 141.0 MB in 3.26 sec (43.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]