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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter

Error Message:
Collection not found: routeFieldColl

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: routeFieldColl
at 
__randomizedtesting.SeedInfo.seed([7E4B68214CDEBB87:D67DF6FCD3BF50DD]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1139)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:822)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter(CustomCollectionTest.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

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

[Policeman Jenkins Server]

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

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! [SolrCore, 
RawDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, 
MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1019)  at 
org.apache.solr.core.SolrCore.reload(SolrCore.java:636)  at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1202)  at 
org.apache.solr.handler.IndexFetcher.lambda$reloadCore$0(IndexFetcher.java:900) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.RawDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:92)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:741)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:934)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:843)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:969)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:904)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:384)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:745)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:726)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:507)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
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.ssl.SslConnection.onFillable(SslConnection.java:202)  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.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 

[jira] [Updated] (SOLR-10796) TestPointsField: increase randomized testing of non-trivial values

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10796:
--
Attachment: SOLR-10796.patch

Patch that adds randomization everywhere. This is close to done.

There is one nocommit: {{testFloatPointFieldRangeFacet()}} fails on a 
{{docValues="true"}} field with {{facet.range.method=dv}}, but not with the 
default method using the exact same documents and query.  None of the other 
{{test\{Double,Long,Int\}PointFieldRangeFacet()}} tests fail in this way.  I'll 
investigate more next week.


> TestPointsField: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: SOLR-10796.patch
>
>
> A lot of TestPointsField code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 4 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/4/

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

Error Message:
The Monkey ran for over 45 seconds and no jetties were stopped - this is worth 
investigating!

Stack Trace:
java.lang.AssertionError: The Monkey ran for over 45 seconds and no jetties 
were stopped - this is worth investigating!
at 
__randomizedtesting.SeedInfo.seed([CAA5C5599C244612:42F1FA8332D82BEA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.apache.solr.cloud.ChaosMonkey.stopTheMonkey(ChaosMonkey.java:587)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test(ChaosMonkeySafeLeaderWithPullReplicasTest.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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] [Updated] (SOLR-9843) DocValuesNotIndexedTest failures indicating exepected documents aren't found

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-9843:
---
 Priority: Major  (was: Blocker)
Fix Version/s: (was: 6.4)
   (was: 7.0)
  Summary: DocValuesNotIndexedTest failures indicating exepected 
documents aren't found  (was: Fix up DocValuesNotIndexedTest failures)

I'm re-opening this issue since the underlying test failures are still possible 
- the existing log files attached show the same pattern as described in 
SOLR-11035, with the SolrCore reloads triggered by the Schema API usage to add 
the fields (see SOLR-11034).

I've updated the summary to note the type of failure that can .

> DocValuesNotIndexedTest failures indicating exepected documents aren't found
> 
>
> Key: SOLR-9843
> URL: https://issues.apache.org/jira/browse/SOLR-9843
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: fail.txt, shard3_replica1.txt, shard_3_searchers.txt, 
> SOLR-9843.patch, SOLR-9843.patch
>
>
> I'll have to do a few iterations on the Jenkins builds since I can't get this 
> to fail locally. Marking as "blocker" since I'll probably have to put some 
> extra code in that I want to be sure is removed before we cut any new 
> releases.



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

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

[jira] [Updated] (SOLR-11035) (at least) 2 distinct failures possible when clients attempt searches during SolrCore reload

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-11035:

Attachment: log.txt

re-attaching log.txt with ansi color markup removed. (sorry about that)

> (at least) 2 distinct failures possible when clients attempt searches during 
> SolrCore reload
> 
>
> Key: SOLR-11035
> URL: https://issues.apache.org/jira/browse/SOLR-11035
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: log.txt, log.txt, SOLR-11035.patch
>
>
> If a SolrCore is reloaded, there are (at least) 2 distinct types of failures 
> that clients may observe when executing updates + queries while the reload is 
> in progress...
> * documents may appear missing during queries
> * queries may fail with "SolrException: openNewSearcher called on closed core"
> Details to follow in comment...



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

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

[jira] [Commented] (SOLR-11035) (at least) 2 distinct failures possible when clients attempt searches during SolrCore reload

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-11035:
-

Linking SOLR-10562 and SOLR-9843

> (at least) 2 distinct failures possible when clients attempt searches during 
> SolrCore reload
> 
>
> Key: SOLR-11035
> URL: https://issues.apache.org/jira/browse/SOLR-11035
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: log.txt, SOLR-11035.patch
>
>
> If a SolrCore is reloaded, there are (at least) 2 distinct types of failures 
> that clients may observe when executing updates + queries while the reload is 
> in progress...
> * documents may appear missing during queries
> * queries may fail with "SolrException: openNewSearcher called on closed core"
> Details to follow in comment...



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

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

[jira] [Updated] (SOLR-10562) TestSolrCLIRunExample failures indicating documents just indexed are not all searchable.

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10562:

Summary: TestSolrCLIRunExample failures indicating documents just indexed 
are not all searchable.  (was: CloudSolrClient.commit can return before docs 
are searchable.)

I've update the summary of this issue to specifically address the observable 
situation noted in the issue description, and opened a new SOLR-11035 to 
address the root cause (rather then convoluting the history/descrption of this 
jira directly)


> TestSolrCLIRunExample failures indicating documents just indexed are not all 
> searchable.
> 
>
> Key: SOLR-10562
> URL: https://issues.apache.org/jira/browse/SOLR-10562
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6, 7.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: 1_1.res, 1_2.res, 2_1.res, 2_2.res, debug.patch, 
> runcli_12.log
>
>
> I've been beating the heck out of some test cases for fear that
> SOLR-10007 really messed things up and I can get a pretty regular test
> failure for TestSolrCLIRunExample.testInteractiveSolrCloudExample, but
> it doesn't make sense.
> So I went back to a revision _before_ SOLR-10007 and it still fails.
> But the failure is "impossible". I put a bunch of log.error messages
> in and, for experimental purposes a for loop in the test. Here's the
> lines that fail in the original:
> {code}
> for (idx = 0; idx < 10; ++idx) {
>  construct a SolrInputDoc and then:
>   cloudClient.add(SolrInputDoc);
> }
> cloudClient.commit();
> QueryResponse qr = cloudClient.query(new SolrQuery("str_s:a"));
> if (qr.getResults().getNumFound() != numDocs) {
>   fail("Expected "+numDocs+" to be found in the "+collectionName+
>   " collection but only found "+qr.getResults().getNumFound());
> }
> {code}
> If I put the above (not the commit, just the query and the test) in a
> loop and check the query 10 times with a 1 second sleep if the numDocs
> != getNumFound(). Quite regularly I'll see a message in the log file
> that getNumFound() != numDocs, but after a few loops getNumFound() ==
> numDocs and the test succeeds.
> cloudClient is what you'd expect:
> cloudClient = 
> getCloudSolrClient(executor.solrCloudCluster.getZkServer().getZkAddress());
> So unless I'm hallucinating, any tests that rely on
> cloudClient.commit() insuring that all docs sent to the cluster are
> searchable will potentially fail on occasion.
> I looked over the JIRAs briefly and don't see any mentions, of a
> similar problem, but I may have missed it.
> The logging I'm writing from the update handler _seems_ to show it to be 
> doing the right thing. Just late.
> I'll attach some data along with a "patch" which generates the logging 
> information. I also attempted to submit a single batch rather than 10 
> individual docs and that fails too.



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

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

[jira] [Updated] (SOLR-11035) (at least) 2 distinct failures possible when clients attempt searches during SolrCore reload

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-11035:

Attachment: SOLR-11035.patch
log.txt


This issue is the root cause of some suspicious (mostly cloud based) test 
failures that -- on the surface -- may initially seem like they are either 
'impossible' or that the commit requests done by the tests are returning before 
the newSearcher was opened (even though {{waitSearcher=true}}).

In my personal experience, the crux of the symptoms are:
* Documents missing from searches done immediately after they were 
(successfully) added+commited
* Seeds don't reproduce reliably, but fail more commonly when running many 
tests and/or CPU usage on the test machine is high.

An example of this class of test failure that initially caught my eye, and I 
could typically get to reproduce semi-frequently is 
DocValuesNotIndexedTest.testGroupingDVOnly.  Running only that test method -- 
or even that entire class -- never failed for me, but if i ran {{ant test 
-Dtests.class=\*DocValues\*}} I could usually get a consistent failure within 
~15 attempts.

One thing most of these failing tests have in common is that instead of a 
static schema, they use managed-schema and either use the Schema API to 
explicitly create the fields needed, or let the schemaless update processors 
add fields as needed.

In comparing the logs of "successful" runs vs "failure" runs, the thing that 
jumped out at me is that the failure runs contain more SolrCore "reloads" (due 
to SOLR-11034) and in every failure case i saw the "CLOSING" log message of a 
SolrCore was occuring _after_ the document adds & commit had been logged by 
that core, but _before_ the log messages from the searches that failed 
validation (meaning they were processed by the newly (re)loaded core)

As Shalin notes in SOLR-10562 (where the Congif API is used causing a core 
reload) in the process of closing the "old" core and opening the "new" core, 
there is a race condition where the "old" core will accept/log/write 
documents/commits to the index, but these will not be immediately visible to 
the SolrIndexSearcher that the "new" core is using once the hand-off is made.

I wrote the attached test class to try and demonstrate this problem in it's 
simplest form (independent of ManagedIndexSchema or SolrCloud or Config API) 
using concurrent 2 threads: one to do an "add, commit(waitSearcher), query" and 
the second to trigger a core reload.

In addition to reproducing the failure I expected (where the query result don't 
reflect the last add+commit) i was able to trigger the second type of failure 
mentioned above: queries can be routed to the "old" core after/during it's 
shutdown, causing a solr exception because the (old) core refuses to open a new 
searcher.

I tweaked my test as originally written to include a HACK making it possible to 
demonstrate both types of failures in a single run -- see the attached log for 
full details

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestReloadConcurrentAdds -Dtests.method=testConcurrent 
-Dtests.seed=5A728C1E8654399 -Dtests.slow=true -Dtests.locale=es-PA 
-Dtests.timezone=Atlantic/Faroe -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.57s | TestReloadConcurrentAdds.testConcurrent <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
query
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([5A728C1E8654399:25D4A7DB2FCE2B30]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
   [junit4]>at 
org.apache.solr.core.TestReloadConcurrentAdds.testConcurrent(TestReloadConcurrentAdds.java:103)
   [junit4]>at 
org.apache.solr.core.TestReloadConcurrentAdds.testConcurrent(TestReloadConcurrentAdds.java:49)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
   [junit4]> Caused by: org.apache.solr.common.SolrException: 
openNewSearcher called on closed core
{noformat}

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestReloadConcurrentAdds 
-Dtests.method=testConcurrentWithNewSearcherExceptionHack 
-Dtests.seed=5A728C1E8654399 -Dtests.slow=true -Dtests.locale=es-PA 
-Dtests.timezone=Atlantic/Faroe -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.81s | 
TestReloadConcurrentAdds.testConcurrentWithNewSearcherExceptionHack <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
query
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([5A728C1E8654399:1C989F4D65319F55]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
   

[jira] [Created] (SOLR-11035) (at least) 2 distinct failures possible when clients attempt searches during SolrCore reload

[Hoss Man (JIRA)]

Hoss Man created SOLR-11035:
---

 Summary: (at least) 2 distinct failures possible when clients 
attempt searches during SolrCore reload
 Key: SOLR-11035
 URL: https://issues.apache.org/jira/browse/SOLR-11035
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man



If a SolrCore is reloaded, there are (at least) 2 distinct types of failures 
that clients may observe when executing updates + queries while the reload is 
in progress...

* documents may appear missing during queries
* queries may fail with "SolrException: openNewSearcher called on closed core"

Details to follow in comment...




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

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

[jira] [Commented] (SOLR-11034) Redundent/Unneccessary SolrCore reload when ManagedIndexSchema changes are made in cloud mode

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-11034:
-


The net result of these two watchers is that depending on the order of 
execution in the distinct threads that process them, there are (at least) 3 
possible outcomes I can think of...

# ZkIndexSchemaReader watcher fires, starts & finishes creating new IndexSchema 
and sets it before the SolrCore watche fires.  Then the SolrCore watcher fires 
and does nothing because it's znode version check shows the current IndexSchema 
is not stale.
# The SolrCore watcher fires, starts & finishes reloading the core. Then the 
ZkIndexSchemaReader watcher fires and does nothing because the SolrCore is in 
the process of shutting down
#* I've never actaully observed this happening in any logs, but AFAICT it's 
theoretically possible
# Both the ZkIndexSchemaReader & SolrCore watchers fire at roughly the same 
time, While ZkIndexSchemaReader is in the process of creating a new 
IndexSchema, the SolrCore watcher checks the zknode version of the current 
IndexSchema object and decides it's stale.

It's not clear to me if/why both code paths are needed -- it seems like either:
* ZkIndexSchemaReader creating a new ManagedIndexSchema object and setting it 
on the "live" core's ManagedIndexSchemaFactory is sufficient
** in which case doing a core reload is completley unneccessary

...OR...

* changing the ManagedIndexSchema "on the fly" is *not* sufficient and doing a 
core reload is always neccessary
** in which case why do we bother having he ZkIndexSchemaReader watcher at all?
** is the existence of this watcher, and the fact that situation #1 (above) 
frequently happens causing bugs/corruption in the cores using the new schema 
w/o a full reload?



Even if both code paths are useful/needed for some indepdent reasons i don't 
understand, situation #3 above seems redundent and wasteful of CPU -- 
particularly since it seems more likely to happen when a system is under heavy 
load, and neither watcher can "finish" before the other starts.  Shouldn't the 
code in SolrCore.getConfListener's watcher to check if 
ManagedIndexSchema.getSchemaZkVersion() is stale be synchronized on the same 
getSchemaUpdateLock() that ZkIndexSchemaReader uses in order to prevent this?



> Redundent/Unneccessary SolrCore reload when ManagedIndexSchema changes are 
> made in cloud mode
> -
>
> Key: SOLR-11034
> URL: https://issues.apache.org/jira/browse/SOLR-11034
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> When using ManagedIndexSchema in cloud mode, there are 2 distinct code paths 
> that create "watchers" looking for changes to the managed-schema resouce file 
> in ZK...
> * ZkIndexSchemaReader.createSchemaWatcher
> ** sets a watcher on the managed-schema file
> ** if this watcher fires, it creates a new ManagedIndexSchema and sets it on 
> the ManagedIndexSchemaFactory for future requests
> * SolrCore.getConfListener + ZkController.registerConfListenerForCore
> ** sets a watcher on the configset dir
> ** if this watcher fires, it then checks the znode version for the 
> solrconfig.xml, configoverlay.json, and managed-schema -- if any are "stale" 
> it triggers a core reload



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

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

[jira] [Created] (SOLR-11034) Redundent/Unneccessary SolrCore reload when ManagedIndexSchema changes are made in cloud mode

[Hoss Man (JIRA)]

Hoss Man created SOLR-11034:
---

 Summary: Redundent/Unneccessary SolrCore reload when 
ManagedIndexSchema changes are made in cloud mode
 Key: SOLR-11034
 URL: https://issues.apache.org/jira/browse/SOLR-11034
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man



When using ManagedIndexSchema in cloud mode, there are 2 distinct code paths 
that create "watchers" looking for changes to the managed-schema resouce file 
in ZK...

* ZkIndexSchemaReader.createSchemaWatcher
** sets a watcher on the managed-schema file
** if this watcher fires, it creates a new ManagedIndexSchema and sets it on 
the ManagedIndexSchemaFactory for future requests
* SolrCore.getConfListener + ZkController.registerConfListenerForCore
** sets a watcher on the configset dir
** if this watcher fires, it then checks the znode version for the 
solrconfig.xml, configoverlay.json, and managed-schema -- if any are "stale" it 
triggers a core reload






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

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

[jira] [Commented] (SOLR-11003) Enabling bi-directional CDCR active-active clusters

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11003:
--

[~shalinmangar] / [~rendel] curious to hear your feedback to the approach we 
are taking here. 

> Enabling bi-directional CDCR active-active clusters
> ---
>
> Key: SOLR-11003
> URL: https://issues.apache.org/jira/browse/SOLR-11003
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
> Attachments: sample-configs.zip, SOLR-11003.patch
>
>
> The latest version of Solr CDCR across collections / clusters is in 
> active-passive format, where we can index into source collection and the 
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a  design ready to index in both collections and the 
> updates gets reflected across the collections in real-time. 
> ClusterACollectionA => ClusterBCollectionB | ClusterBCollectionB => 
> ClusterACollectionA.
> The best use-case would be to we keep indexing in ClusterACollectionA which 
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets 
> down, we point the indexer and searcher application to ClusterBCollectionB. 
> Once ClusterACollectionA is up, depending on updates count, they will be 
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and 
> keep indexing on the ClusterBCollectionB.



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

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

[jira] [Commented] (SOLR-11003) Enabling bi-directional CDCR active-active clusters

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11003:
--

Hi Amrit,

Patch is looking good!

Let's add some code comments in CDCRTransactionLog and CDCRReplicator.

For example, this change in CDCRTransactionLog is confusing till you look at 
CDCRReplicator#isTargetCluster 
{code}
if 
(cmd.getReq().getParamString().contains(CdcrUpdateProcessor.CDCR_UPDATE)) {
  codec.writeTag(JavaBinCodec.ARR, 6);
} else {
  codec.writeTag(JavaBinCodec.ARR, 5);
}
{code}


The test has adds, deleteByid and deleteByQuery.  Can we also test for in place 
updates ( I didn't see a anything triggering that code path ) 
Also it wouldn't hurt to add atomic updates to the test.

> Enabling bi-directional CDCR active-active clusters
> ---
>
> Key: SOLR-11003
> URL: https://issues.apache.org/jira/browse/SOLR-11003
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
> Attachments: sample-configs.zip, SOLR-11003.patch
>
>
> The latest version of Solr CDCR across collections / clusters is in 
> active-passive format, where we can index into source collection and the 
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a  design ready to index in both collections and the 
> updates gets reflected across the collections in real-time. 
> ClusterACollectionA => ClusterBCollectionB | ClusterBCollectionB => 
> ClusterACollectionA.
> The best use-case would be to we keep indexing in ClusterACollectionA which 
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets 
> down, we point the indexer and searcher application to ClusterBCollectionB. 
> Once ClusterACollectionA is up, depending on updates count, they will be 
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and 
> keep indexing on the ClusterBCollectionB.



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
Could not find collection : implicitcoll

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : implicitcoll
at 
__randomizedtesting.SeedInfo.seed([2241743D59F39017:48A0FA566469266F]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:247)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.TestSSLRandomization.testRandomizedSslAndClientAuth

Error Message:
Could not find collection:first_collection

Stack Trace:

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.facet.FieldFacetCloudTest

Error Message:
Could not find collection:collection1

Stack Trace:
java.lang.AssertionError: Could not find collection:collection1
at __randomizedtesting.SeedInfo.seed([64BD29E021845E6A]: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:155)
at 
org.apache.solr.analytics.facet.AbstractAnalyticsFacetCloudTest.setupCluster(AbstractAnalyticsFacetCloudTest.java:59)
at 
org.apache.solr.analytics.facet.FieldFacetCloudTest.beforeClass(FieldFacetCloudTest.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 15796 lines...]
   [junit4] Suite: org.apache.solr.analytics.facet.FieldFacetCloudTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/contrib/solr-analytics/test/J0/temp/solr.analytics.facet.FieldFacetCloudTest_64BD29E021845E6A-001/init-core-data-001
   [junit4]   2> log4j:WARN No appenders could be found for logger 
(org.apache.solr.SolrTestCaseJ4).
   [junit4]   2> log4j:WARN Please initialize the log4j system properly.
   [junit4]   2> log4j:WARN See 
http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
sim=RandomSimilarity(queryNorm=true): {}, locale=zh-SG, 
timezone=America/North_Dakota/Beulah
   [junit4]   2> NOTE: Linux 3.13.0-88-generic amd64/Oracle Corporation 
1.8.0_131 (64-bit)/cpus=4,threads=1,free=182616808,total=341835776
   [junit4]   2> NOTE: All tests run in this JVM: 
[AbstractAnalyticsFacetCloudTest, FieldFacetCloudTest]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=FieldFacetCloudTest 
-Dtests.seed=64BD29E021845E6A -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=zh-SG -Dtests.timezone=America/North_Dakota/Beulah 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.00s J0 | FieldFacetCloudTest (suite) <<<
   [junit4]> Throwable #1: java.lang.AssertionError: Could not find 
collection:collection1
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([64BD29E021845E6A]:0)
   [junit4]>at 

[JENKINS-EA] Lucene-Solr-7.x-Windows (32bit/jdk-9-ea+173) - Build # 15 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/15/
Java: 32bit/jdk-9-ea+173 -client -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([8ADD837FD715799D:E8B07D3E189B19A3]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.junit.Assert.assertNotNull(Assert.java:537)
at 
org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter(MetricsHandlerTest.java:201)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.component.InfixSuggestersTest

Error Message:
Could not remove the following files (in the order of attempts):

[jira] [Commented] (SOLR-10803) Solr should refuse to create Trie*Field instances in 7.0 indices

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10803:
-

bq. Seems like SOLR-10760 should be sufficient to have people use point fields 
by default.

That doesn't address the broader scope of concerns uwe & adrien expressed about 
what happens to people who already use Trie fields (or add them to collections 
they create with solr7) when solr8 comes around.

(Assuming SOLR-10760 makes it into 7.0) Perhaps this issue should be 
renamed/reclassified as "Mark all Trie/LegacyNumeric based fields \@deprecated 
in Solr7" -- At which point the existing checks in SolrResourceLoader will log 
a warning and we'll be free to remove them in solr8

> Solr should refuse to create Trie*Field instances in 7.0 indices
> 
>
> Key: SOLR-10803
> URL: https://issues.apache.org/jira/browse/SOLR-10803
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Adrien Grand
>Priority: Blocker
> Fix For: 7.0
>
>
> If we want to be able to remove support for legacy numerics from Solr in 8.0, 
> we need to forbid the use of Trie*Field in indices that are created on or 
> after 7.0.



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster

Error Message:
Document mismatch on target after sync expected:<2000> but was:<0>

Stack Trace:
java.lang.AssertionError: Document mismatch on target after sync 
expected:<2000> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([34A6AD1BDB494F14:E0E3E6423C1FFCEF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster(CdcrBootstrapTest.java:309)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12408 lines...]
   

[jira] [Commented] (SOLR-11025) OverseerTest.testShardLeaderChange() failures

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-11025:
---

Thanks guys!  I didn't bother adding an entry to CHANGES.txt, didn't seem 
relevant for user facing purposes.

> OverseerTest.testShardLeaderChange() failures
> -
>
> Key: SOLR-11025
> URL: https://issues.apache.org/jira/browse/SOLR-11025
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11025.patch
>
>
> Non-reproducing Jenkins failure - this test hasn't failed in Jenkins in 
> months, and suddenly several failures within days of each other:
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/18/]:
> {noformat}
> Checking out Revision 986175915927ee2bbd971340f858601c86b3c676 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=OverseerTest 
> -Dtests.method=testShardLeaderChange -Dtests.seed=995C82D4739EF7D8 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ru 
> -Dtests.timezone=Asia/Calcutta -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  223s J2 | OverseerTest.testShardLeaderChange <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Unexpected shard 
> leader coll:collection1 shard:shard1 expected: but was:
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([995C82D4739EF7D8:470F052369060229]:0)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:486)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:720)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=892, maxMBSortInHeap=5.965872045375053, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ru, timezone=Asia/Calcutta
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
> 1.8.0_131 (32-bit)/cpus=8,threads=1,free=96275160,total=293539840
>[junit4]   2> NOTE: All tests run in this JVM: [HardAutoCommitTest, 
> SimplePostToolTest, TestSolrCoreSnapshots, ReplicationFactorTest, 
> TestSolrCoreProperties, TestSha256AuthenticationProvider, 
> TestExpandComponent, TestCloudRecovery, ConfigureRecoveryStrategyTest, 
> TimeZoneUtilsTest, TestTolerantUpdateProcessorRandomCloud, 
> TestExceedMaxTermLength, PrimitiveFieldTypeTest, SolrInfoBeanTest, 
> FullSolrCloudDistribCmdsTest, UniqFieldsUpdateProcessorFactoryTest, 
> TestReplicaProperties, SolrCloudReportersTest, UnloadDistributedZkTest, 
> CleanupOldIndexTest, LeaderInitiatedRecoveryOnShardRestartTest, 
> FastVectorHighlighterTest, TestOrdValues, MinimalSchemaTest, 
> TestSubQueryTransformerCrossCore, ParsingFieldUpdateProcessorsTest, 
> BufferStoreTest, TestLegacyFieldReuse, CollectionsAPISolrJTest, 
> TestSchemalessBufferedUpdates, ConnectionManagerTest, MetricsConfigTest, 
> TestPayloadScoreQParserPlugin, TermVectorComponentDistributedTest, 
> TestLMJelinekMercerSimilarityFactory, TestFastWriter, MultiTermTest, 
> HdfsBasicDistributedZk2Test, V2StandaloneTest, DocumentBuilderTest, 
> TestMultiValuedNumericRangeQuery, AnalyticsMergeStrategyTest, 
> TestNumericTokenStream, TestFieldCacheSort, 
> TestSolrCloudWithSecureImpersonation, TestBlendedInfixSuggestions, 
> ResponseLogComponentTest, CopyFieldTest, TestAuthenticationFramework, 
> BlockJoinFacetDistribTest, TestFieldSortValues, TestJmxIntegration, 
> SolrTestCaseJ4Test, BasicAuthIntegrationTest, URLClassifyProcessorTest, 
> DateFieldTest, TestExactSharedStatsCache, TestFieldTypeCollectionResource, 
> ExplicitHLLTest, ConjunctionSolrSpellCheckerTest, 
> TestLeaderElectionWithEmptyReplica, TestReloadAndDeleteDocs, 
> ClusterStateTest, TestSQLHandler, HdfsRecoverLeaseTest, QueryEqualityTest, 
> UUIDUpdateProcessorFallbackTest, ClassificationUpdateProcessorFactoryTest, 
> DistributedSuggestComponentTest, TestHalfAndHalfDocValues, 
> ShowFileRequestHandlerTest, ExitableDirectoryReaderTest, 
> TestInfoStreamLogging, TestLocalFSCloudBackupRestore, 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest, TestSort, NumericFieldsTest, 
> DirectUpdateHandlerTest, SuggesterFSTTest, NodeMutatorTest, 
> DateMathParserTest, DistribCursorPagingTest, CircularListTest, 
> CloneFieldUpdateProcessorFactoryTest, 
> OverseerCollectionConfigSetProcessorTest, DateRangeFieldTest, 
> TestDFRSimilarityFactory, XsltUpdateRequestHandlerTest, TestConfigSetsAPI, 
> CoreMergeIndexesAdminHandlerTest, TestSerializedLuceneMatchVersion, 
> TestPrepRecovery, TestNoOpRegenerator, DistributedFacetPivotWhiteBoxTest, 
> LeaderFailoverAfterPartitionTest, TestSolrFieldCacheBean, OverseerTest]
> {noformat}
> Following is the first of 4 failures from my 

[jira] [Assigned] (SOLR-11025) OverseerTest.testShardLeaderChange() failures

[Scott Blum (JIRA)]

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

Scott Blum reassigned SOLR-11025:
-

Assignee: Scott Blum

> OverseerTest.testShardLeaderChange() failures
> -
>
> Key: SOLR-11025
> URL: https://issues.apache.org/jira/browse/SOLR-11025
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Scott Blum
> Attachments: SOLR-11025.patch
>
>
> Non-reproducing Jenkins failure - this test hasn't failed in Jenkins in 
> months, and suddenly several failures within days of each other:
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/18/]:
> {noformat}
> Checking out Revision 986175915927ee2bbd971340f858601c86b3c676 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=OverseerTest 
> -Dtests.method=testShardLeaderChange -Dtests.seed=995C82D4739EF7D8 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ru 
> -Dtests.timezone=Asia/Calcutta -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  223s J2 | OverseerTest.testShardLeaderChange <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Unexpected shard 
> leader coll:collection1 shard:shard1 expected: but was:
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([995C82D4739EF7D8:470F052369060229]:0)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:486)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:720)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=892, maxMBSortInHeap=5.965872045375053, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ru, timezone=Asia/Calcutta
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
> 1.8.0_131 (32-bit)/cpus=8,threads=1,free=96275160,total=293539840
>[junit4]   2> NOTE: All tests run in this JVM: [HardAutoCommitTest, 
> SimplePostToolTest, TestSolrCoreSnapshots, ReplicationFactorTest, 
> TestSolrCoreProperties, TestSha256AuthenticationProvider, 
> TestExpandComponent, TestCloudRecovery, ConfigureRecoveryStrategyTest, 
> TimeZoneUtilsTest, TestTolerantUpdateProcessorRandomCloud, 
> TestExceedMaxTermLength, PrimitiveFieldTypeTest, SolrInfoBeanTest, 
> FullSolrCloudDistribCmdsTest, UniqFieldsUpdateProcessorFactoryTest, 
> TestReplicaProperties, SolrCloudReportersTest, UnloadDistributedZkTest, 
> CleanupOldIndexTest, LeaderInitiatedRecoveryOnShardRestartTest, 
> FastVectorHighlighterTest, TestOrdValues, MinimalSchemaTest, 
> TestSubQueryTransformerCrossCore, ParsingFieldUpdateProcessorsTest, 
> BufferStoreTest, TestLegacyFieldReuse, CollectionsAPISolrJTest, 
> TestSchemalessBufferedUpdates, ConnectionManagerTest, MetricsConfigTest, 
> TestPayloadScoreQParserPlugin, TermVectorComponentDistributedTest, 
> TestLMJelinekMercerSimilarityFactory, TestFastWriter, MultiTermTest, 
> HdfsBasicDistributedZk2Test, V2StandaloneTest, DocumentBuilderTest, 
> TestMultiValuedNumericRangeQuery, AnalyticsMergeStrategyTest, 
> TestNumericTokenStream, TestFieldCacheSort, 
> TestSolrCloudWithSecureImpersonation, TestBlendedInfixSuggestions, 
> ResponseLogComponentTest, CopyFieldTest, TestAuthenticationFramework, 
> BlockJoinFacetDistribTest, TestFieldSortValues, TestJmxIntegration, 
> SolrTestCaseJ4Test, BasicAuthIntegrationTest, URLClassifyProcessorTest, 
> DateFieldTest, TestExactSharedStatsCache, TestFieldTypeCollectionResource, 
> ExplicitHLLTest, ConjunctionSolrSpellCheckerTest, 
> TestLeaderElectionWithEmptyReplica, TestReloadAndDeleteDocs, 
> ClusterStateTest, TestSQLHandler, HdfsRecoverLeaseTest, QueryEqualityTest, 
> UUIDUpdateProcessorFallbackTest, ClassificationUpdateProcessorFactoryTest, 
> DistributedSuggestComponentTest, TestHalfAndHalfDocValues, 
> ShowFileRequestHandlerTest, ExitableDirectoryReaderTest, 
> TestInfoStreamLogging, TestLocalFSCloudBackupRestore, 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest, TestSort, NumericFieldsTest, 
> DirectUpdateHandlerTest, SuggesterFSTTest, NodeMutatorTest, 
> DateMathParserTest, DistribCursorPagingTest, CircularListTest, 
> CloneFieldUpdateProcessorFactoryTest, 
> OverseerCollectionConfigSetProcessorTest, DateRangeFieldTest, 
> TestDFRSimilarityFactory, XsltUpdateRequestHandlerTest, TestConfigSetsAPI, 
> CoreMergeIndexesAdminHandlerTest, TestSerializedLuceneMatchVersion, 
> TestPrepRecovery, TestNoOpRegenerator, DistributedFacetPivotWhiteBoxTest, 
> LeaderFailoverAfterPartitionTest, TestSolrFieldCacheBean, OverseerTest]
> {noformat}
> Following is the first of 4 failures from my Jenkins in the last 24 hours or 
> so on branch_7_0 and branch_7x:
> {noformat}
> 

[jira] [Resolved] (SOLR-11025) OverseerTest.testShardLeaderChange() failures

[Scott Blum (JIRA)]

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

Scott Blum resolved SOLR-11025.
---
Resolution: Fixed

> OverseerTest.testShardLeaderChange() failures
> -
>
> Key: SOLR-11025
> URL: https://issues.apache.org/jira/browse/SOLR-11025
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11025.patch
>
>
> Non-reproducing Jenkins failure - this test hasn't failed in Jenkins in 
> months, and suddenly several failures within days of each other:
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/18/]:
> {noformat}
> Checking out Revision 986175915927ee2bbd971340f858601c86b3c676 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=OverseerTest 
> -Dtests.method=testShardLeaderChange -Dtests.seed=995C82D4739EF7D8 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ru 
> -Dtests.timezone=Asia/Calcutta -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  223s J2 | OverseerTest.testShardLeaderChange <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Unexpected shard 
> leader coll:collection1 shard:shard1 expected: but was:
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([995C82D4739EF7D8:470F052369060229]:0)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:486)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:720)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=892, maxMBSortInHeap=5.965872045375053, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ru, timezone=Asia/Calcutta
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
> 1.8.0_131 (32-bit)/cpus=8,threads=1,free=96275160,total=293539840
>[junit4]   2> NOTE: All tests run in this JVM: [HardAutoCommitTest, 
> SimplePostToolTest, TestSolrCoreSnapshots, ReplicationFactorTest, 
> TestSolrCoreProperties, TestSha256AuthenticationProvider, 
> TestExpandComponent, TestCloudRecovery, ConfigureRecoveryStrategyTest, 
> TimeZoneUtilsTest, TestTolerantUpdateProcessorRandomCloud, 
> TestExceedMaxTermLength, PrimitiveFieldTypeTest, SolrInfoBeanTest, 
> FullSolrCloudDistribCmdsTest, UniqFieldsUpdateProcessorFactoryTest, 
> TestReplicaProperties, SolrCloudReportersTest, UnloadDistributedZkTest, 
> CleanupOldIndexTest, LeaderInitiatedRecoveryOnShardRestartTest, 
> FastVectorHighlighterTest, TestOrdValues, MinimalSchemaTest, 
> TestSubQueryTransformerCrossCore, ParsingFieldUpdateProcessorsTest, 
> BufferStoreTest, TestLegacyFieldReuse, CollectionsAPISolrJTest, 
> TestSchemalessBufferedUpdates, ConnectionManagerTest, MetricsConfigTest, 
> TestPayloadScoreQParserPlugin, TermVectorComponentDistributedTest, 
> TestLMJelinekMercerSimilarityFactory, TestFastWriter, MultiTermTest, 
> HdfsBasicDistributedZk2Test, V2StandaloneTest, DocumentBuilderTest, 
> TestMultiValuedNumericRangeQuery, AnalyticsMergeStrategyTest, 
> TestNumericTokenStream, TestFieldCacheSort, 
> TestSolrCloudWithSecureImpersonation, TestBlendedInfixSuggestions, 
> ResponseLogComponentTest, CopyFieldTest, TestAuthenticationFramework, 
> BlockJoinFacetDistribTest, TestFieldSortValues, TestJmxIntegration, 
> SolrTestCaseJ4Test, BasicAuthIntegrationTest, URLClassifyProcessorTest, 
> DateFieldTest, TestExactSharedStatsCache, TestFieldTypeCollectionResource, 
> ExplicitHLLTest, ConjunctionSolrSpellCheckerTest, 
> TestLeaderElectionWithEmptyReplica, TestReloadAndDeleteDocs, 
> ClusterStateTest, TestSQLHandler, HdfsRecoverLeaseTest, QueryEqualityTest, 
> UUIDUpdateProcessorFallbackTest, ClassificationUpdateProcessorFactoryTest, 
> DistributedSuggestComponentTest, TestHalfAndHalfDocValues, 
> ShowFileRequestHandlerTest, ExitableDirectoryReaderTest, 
> TestInfoStreamLogging, TestLocalFSCloudBackupRestore, 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest, TestSort, NumericFieldsTest, 
> DirectUpdateHandlerTest, SuggesterFSTTest, NodeMutatorTest, 
> DateMathParserTest, DistribCursorPagingTest, CircularListTest, 
> CloneFieldUpdateProcessorFactoryTest, 
> OverseerCollectionConfigSetProcessorTest, DateRangeFieldTest, 
> TestDFRSimilarityFactory, XsltUpdateRequestHandlerTest, TestConfigSetsAPI, 
> CoreMergeIndexesAdminHandlerTest, TestSerializedLuceneMatchVersion, 
> TestPrepRecovery, TestNoOpRegenerator, DistributedFacetPivotWhiteBoxTest, 
> LeaderFailoverAfterPartitionTest, TestSolrFieldCacheBean, OverseerTest]
> {noformat}
> Following is the first of 4 failures from my Jenkins in the last 24 hours or 
> so on branch_7_0 and branch_7x:
> {noformat}
> Checking out Revision 

[jira] [Commented] (SOLR-11025) OverseerTest.testShardLeaderChange() failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11025:


Commit 6cdc0060e5c3b93f0764d7e8e441fa21931fe60d in lucene-solr's branch 
refs/heads/branch_7_0 from [~dragonsinth]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6cdc006 ]

SOLR-11025: fix OverseerTest.testShardLeaderChange() failures


> OverseerTest.testShardLeaderChange() failures
> -
>
> Key: SOLR-11025
> URL: https://issues.apache.org/jira/browse/SOLR-11025
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11025.patch
>
>
> Non-reproducing Jenkins failure - this test hasn't failed in Jenkins in 
> months, and suddenly several failures within days of each other:
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/18/]:
> {noformat}
> Checking out Revision 986175915927ee2bbd971340f858601c86b3c676 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=OverseerTest 
> -Dtests.method=testShardLeaderChange -Dtests.seed=995C82D4739EF7D8 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ru 
> -Dtests.timezone=Asia/Calcutta -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  223s J2 | OverseerTest.testShardLeaderChange <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Unexpected shard 
> leader coll:collection1 shard:shard1 expected: but was:
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([995C82D4739EF7D8:470F052369060229]:0)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:486)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:720)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=892, maxMBSortInHeap=5.965872045375053, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ru, timezone=Asia/Calcutta
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
> 1.8.0_131 (32-bit)/cpus=8,threads=1,free=96275160,total=293539840
>[junit4]   2> NOTE: All tests run in this JVM: [HardAutoCommitTest, 
> SimplePostToolTest, TestSolrCoreSnapshots, ReplicationFactorTest, 
> TestSolrCoreProperties, TestSha256AuthenticationProvider, 
> TestExpandComponent, TestCloudRecovery, ConfigureRecoveryStrategyTest, 
> TimeZoneUtilsTest, TestTolerantUpdateProcessorRandomCloud, 
> TestExceedMaxTermLength, PrimitiveFieldTypeTest, SolrInfoBeanTest, 
> FullSolrCloudDistribCmdsTest, UniqFieldsUpdateProcessorFactoryTest, 
> TestReplicaProperties, SolrCloudReportersTest, UnloadDistributedZkTest, 
> CleanupOldIndexTest, LeaderInitiatedRecoveryOnShardRestartTest, 
> FastVectorHighlighterTest, TestOrdValues, MinimalSchemaTest, 
> TestSubQueryTransformerCrossCore, ParsingFieldUpdateProcessorsTest, 
> BufferStoreTest, TestLegacyFieldReuse, CollectionsAPISolrJTest, 
> TestSchemalessBufferedUpdates, ConnectionManagerTest, MetricsConfigTest, 
> TestPayloadScoreQParserPlugin, TermVectorComponentDistributedTest, 
> TestLMJelinekMercerSimilarityFactory, TestFastWriter, MultiTermTest, 
> HdfsBasicDistributedZk2Test, V2StandaloneTest, DocumentBuilderTest, 
> TestMultiValuedNumericRangeQuery, AnalyticsMergeStrategyTest, 
> TestNumericTokenStream, TestFieldCacheSort, 
> TestSolrCloudWithSecureImpersonation, TestBlendedInfixSuggestions, 
> ResponseLogComponentTest, CopyFieldTest, TestAuthenticationFramework, 
> BlockJoinFacetDistribTest, TestFieldSortValues, TestJmxIntegration, 
> SolrTestCaseJ4Test, BasicAuthIntegrationTest, URLClassifyProcessorTest, 
> DateFieldTest, TestExactSharedStatsCache, TestFieldTypeCollectionResource, 
> ExplicitHLLTest, ConjunctionSolrSpellCheckerTest, 
> TestLeaderElectionWithEmptyReplica, TestReloadAndDeleteDocs, 
> ClusterStateTest, TestSQLHandler, HdfsRecoverLeaseTest, QueryEqualityTest, 
> UUIDUpdateProcessorFallbackTest, ClassificationUpdateProcessorFactoryTest, 
> DistributedSuggestComponentTest, TestHalfAndHalfDocValues, 
> ShowFileRequestHandlerTest, ExitableDirectoryReaderTest, 
> TestInfoStreamLogging, TestLocalFSCloudBackupRestore, 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest, TestSort, NumericFieldsTest, 
> DirectUpdateHandlerTest, SuggesterFSTTest, NodeMutatorTest, 
> DateMathParserTest, DistribCursorPagingTest, CircularListTest, 
> CloneFieldUpdateProcessorFactoryTest, 
> OverseerCollectionConfigSetProcessorTest, DateRangeFieldTest, 
> TestDFRSimilarityFactory, XsltUpdateRequestHandlerTest, TestConfigSetsAPI, 
> CoreMergeIndexesAdminHandlerTest, TestSerializedLuceneMatchVersion, 
> TestPrepRecovery, 

[jira] [Commented] (SOLR-11025) OverseerTest.testShardLeaderChange() failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11025:


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

SOLR-11025: fix OverseerTest.testShardLeaderChange() failures


> OverseerTest.testShardLeaderChange() failures
> -
>
> Key: SOLR-11025
> URL: https://issues.apache.org/jira/browse/SOLR-11025
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11025.patch
>
>
> Non-reproducing Jenkins failure - this test hasn't failed in Jenkins in 
> months, and suddenly several failures within days of each other:
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/18/]:
> {noformat}
> Checking out Revision 986175915927ee2bbd971340f858601c86b3c676 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=OverseerTest 
> -Dtests.method=testShardLeaderChange -Dtests.seed=995C82D4739EF7D8 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ru 
> -Dtests.timezone=Asia/Calcutta -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  223s J2 | OverseerTest.testShardLeaderChange <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Unexpected shard 
> leader coll:collection1 shard:shard1 expected: but was:
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([995C82D4739EF7D8:470F052369060229]:0)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:486)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:720)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=892, maxMBSortInHeap=5.965872045375053, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ru, timezone=Asia/Calcutta
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
> 1.8.0_131 (32-bit)/cpus=8,threads=1,free=96275160,total=293539840
>[junit4]   2> NOTE: All tests run in this JVM: [HardAutoCommitTest, 
> SimplePostToolTest, TestSolrCoreSnapshots, ReplicationFactorTest, 
> TestSolrCoreProperties, TestSha256AuthenticationProvider, 
> TestExpandComponent, TestCloudRecovery, ConfigureRecoveryStrategyTest, 
> TimeZoneUtilsTest, TestTolerantUpdateProcessorRandomCloud, 
> TestExceedMaxTermLength, PrimitiveFieldTypeTest, SolrInfoBeanTest, 
> FullSolrCloudDistribCmdsTest, UniqFieldsUpdateProcessorFactoryTest, 
> TestReplicaProperties, SolrCloudReportersTest, UnloadDistributedZkTest, 
> CleanupOldIndexTest, LeaderInitiatedRecoveryOnShardRestartTest, 
> FastVectorHighlighterTest, TestOrdValues, MinimalSchemaTest, 
> TestSubQueryTransformerCrossCore, ParsingFieldUpdateProcessorsTest, 
> BufferStoreTest, TestLegacyFieldReuse, CollectionsAPISolrJTest, 
> TestSchemalessBufferedUpdates, ConnectionManagerTest, MetricsConfigTest, 
> TestPayloadScoreQParserPlugin, TermVectorComponentDistributedTest, 
> TestLMJelinekMercerSimilarityFactory, TestFastWriter, MultiTermTest, 
> HdfsBasicDistributedZk2Test, V2StandaloneTest, DocumentBuilderTest, 
> TestMultiValuedNumericRangeQuery, AnalyticsMergeStrategyTest, 
> TestNumericTokenStream, TestFieldCacheSort, 
> TestSolrCloudWithSecureImpersonation, TestBlendedInfixSuggestions, 
> ResponseLogComponentTest, CopyFieldTest, TestAuthenticationFramework, 
> BlockJoinFacetDistribTest, TestFieldSortValues, TestJmxIntegration, 
> SolrTestCaseJ4Test, BasicAuthIntegrationTest, URLClassifyProcessorTest, 
> DateFieldTest, TestExactSharedStatsCache, TestFieldTypeCollectionResource, 
> ExplicitHLLTest, ConjunctionSolrSpellCheckerTest, 
> TestLeaderElectionWithEmptyReplica, TestReloadAndDeleteDocs, 
> ClusterStateTest, TestSQLHandler, HdfsRecoverLeaseTest, QueryEqualityTest, 
> UUIDUpdateProcessorFallbackTest, ClassificationUpdateProcessorFactoryTest, 
> DistributedSuggestComponentTest, TestHalfAndHalfDocValues, 
> ShowFileRequestHandlerTest, ExitableDirectoryReaderTest, 
> TestInfoStreamLogging, TestLocalFSCloudBackupRestore, 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest, TestSort, NumericFieldsTest, 
> DirectUpdateHandlerTest, SuggesterFSTTest, NodeMutatorTest, 
> DateMathParserTest, DistribCursorPagingTest, CircularListTest, 
> CloneFieldUpdateProcessorFactoryTest, 
> OverseerCollectionConfigSetProcessorTest, DateRangeFieldTest, 
> TestDFRSimilarityFactory, XsltUpdateRequestHandlerTest, TestConfigSetsAPI, 
> CoreMergeIndexesAdminHandlerTest, TestSerializedLuceneMatchVersion, 
> TestPrepRecovery, 

[jira] [Commented] (SOLR-11025) OverseerTest.testShardLeaderChange() failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11025:


Commit 5ba509dbd267d28f616d20c195b7fad70fc6064b in lucene-solr's branch 
refs/heads/branch_7x from [~dragonsinth]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5ba509d ]

SOLR-11025: fix OverseerTest.testShardLeaderChange() failures


> OverseerTest.testShardLeaderChange() failures
> -
>
> Key: SOLR-11025
> URL: https://issues.apache.org/jira/browse/SOLR-11025
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11025.patch
>
>
> Non-reproducing Jenkins failure - this test hasn't failed in Jenkins in 
> months, and suddenly several failures within days of each other:
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/18/]:
> {noformat}
> Checking out Revision 986175915927ee2bbd971340f858601c86b3c676 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=OverseerTest 
> -Dtests.method=testShardLeaderChange -Dtests.seed=995C82D4739EF7D8 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ru 
> -Dtests.timezone=Asia/Calcutta -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  223s J2 | OverseerTest.testShardLeaderChange <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Unexpected shard 
> leader coll:collection1 shard:shard1 expected: but was:
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([995C82D4739EF7D8:470F052369060229]:0)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:486)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:720)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=892, maxMBSortInHeap=5.965872045375053, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ru, timezone=Asia/Calcutta
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
> 1.8.0_131 (32-bit)/cpus=8,threads=1,free=96275160,total=293539840
>[junit4]   2> NOTE: All tests run in this JVM: [HardAutoCommitTest, 
> SimplePostToolTest, TestSolrCoreSnapshots, ReplicationFactorTest, 
> TestSolrCoreProperties, TestSha256AuthenticationProvider, 
> TestExpandComponent, TestCloudRecovery, ConfigureRecoveryStrategyTest, 
> TimeZoneUtilsTest, TestTolerantUpdateProcessorRandomCloud, 
> TestExceedMaxTermLength, PrimitiveFieldTypeTest, SolrInfoBeanTest, 
> FullSolrCloudDistribCmdsTest, UniqFieldsUpdateProcessorFactoryTest, 
> TestReplicaProperties, SolrCloudReportersTest, UnloadDistributedZkTest, 
> CleanupOldIndexTest, LeaderInitiatedRecoveryOnShardRestartTest, 
> FastVectorHighlighterTest, TestOrdValues, MinimalSchemaTest, 
> TestSubQueryTransformerCrossCore, ParsingFieldUpdateProcessorsTest, 
> BufferStoreTest, TestLegacyFieldReuse, CollectionsAPISolrJTest, 
> TestSchemalessBufferedUpdates, ConnectionManagerTest, MetricsConfigTest, 
> TestPayloadScoreQParserPlugin, TermVectorComponentDistributedTest, 
> TestLMJelinekMercerSimilarityFactory, TestFastWriter, MultiTermTest, 
> HdfsBasicDistributedZk2Test, V2StandaloneTest, DocumentBuilderTest, 
> TestMultiValuedNumericRangeQuery, AnalyticsMergeStrategyTest, 
> TestNumericTokenStream, TestFieldCacheSort, 
> TestSolrCloudWithSecureImpersonation, TestBlendedInfixSuggestions, 
> ResponseLogComponentTest, CopyFieldTest, TestAuthenticationFramework, 
> BlockJoinFacetDistribTest, TestFieldSortValues, TestJmxIntegration, 
> SolrTestCaseJ4Test, BasicAuthIntegrationTest, URLClassifyProcessorTest, 
> DateFieldTest, TestExactSharedStatsCache, TestFieldTypeCollectionResource, 
> ExplicitHLLTest, ConjunctionSolrSpellCheckerTest, 
> TestLeaderElectionWithEmptyReplica, TestReloadAndDeleteDocs, 
> ClusterStateTest, TestSQLHandler, HdfsRecoverLeaseTest, QueryEqualityTest, 
> UUIDUpdateProcessorFallbackTest, ClassificationUpdateProcessorFactoryTest, 
> DistributedSuggestComponentTest, TestHalfAndHalfDocValues, 
> ShowFileRequestHandlerTest, ExitableDirectoryReaderTest, 
> TestInfoStreamLogging, TestLocalFSCloudBackupRestore, 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest, TestSort, NumericFieldsTest, 
> DirectUpdateHandlerTest, SuggesterFSTTest, NodeMutatorTest, 
> DateMathParserTest, DistribCursorPagingTest, CircularListTest, 
> CloneFieldUpdateProcessorFactoryTest, 
> OverseerCollectionConfigSetProcessorTest, DateRangeFieldTest, 
> TestDFRSimilarityFactory, XsltUpdateRequestHandlerTest, TestConfigSetsAPI, 
> CoreMergeIndexesAdminHandlerTest, TestSerializedLuceneMatchVersion, 
> TestPrepRecovery, 

[jira] [Commented] (SOLR-11033) Move out multi language field and fieldType to a separate example

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11033:
--

Rough outline :

Create a example/multilanguage/conf folder. This could contain a bigger schema 
which has preconfigured definitions for all the languages ( including the 
contrib ones ) and the solrconfig file which has langid guessing. 

Remove all of the non english language definitions from the default configset

Taking David Smiley's suggestion on a similar config refacor Jia this could be 
broken into two commits to make it more readable in the future.

> Move out multi language field and fieldType to a separate example 
> --
>
> Key: SOLR-11033
> URL: https://issues.apache.org/jira/browse/SOLR-11033
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>
> The bulk of the schema file in the default configset has fieldType and 
> dynamic field definition for  different languages.  Based on the discussion 
> on SOLR-10967 if we move it to a separate config set and keep the default 
> configset english only then the size will be dramatically reduced and make 
> the schema file much more readable.



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

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

[jira] [Commented] (SOLR-10967) Cleanup the default configset

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-10967:
--

+1 to that. And we should probably put that in the examples folder. I created 
SOLR-11033 for it! 

> Cleanup the default configset
> -
>
> Key: SOLR-10967
> URL: https://issues.apache.org/jira/browse/SOLR-10967
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 7.0
>
> Attachments: SOLR-10967.patch, SOLR-10967.patch, SOLR-10967.patch
>
>
> The schema in the default configset is 1000 lines . We should audit it and 
> see if we can prune it a little bit. 
> Also in this Jira we should fix some of the copy editing . For example, 
> comments like these are outdated 
> {code}
>  This is the Solr schema file. This file should be named "schema.xml" and
>  should be in the conf directory under the solr home
>  (i.e. ./solr/conf/schema.xml by default) 
>  or located where the classloader for the Solr webapp can find it.
> {code}



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

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

[jira] [Created] (SOLR-11033) Move out multi language field and fieldType to a separate example

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-11033:


 Summary: Move out multi language field and fieldType to a separate 
example 
 Key: SOLR-11033
 URL: https://issues.apache.org/jira/browse/SOLR-11033
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker


The bulk of the schema file in the default configset has fieldType and dynamic 
field definition for  different languages.  Based on the discussion on 
SOLR-10967 if we move it to a separate config set and keep the default 
configset english only then the size will be dramatically reduced and make the 
schema file much more readable.



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

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

[jira] [Closed] (SOLR-11021) Remove elevate.xml from the default configs

[Varun Thacker (JIRA)]

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

Varun Thacker closed SOLR-11021.

Resolution: Fixed

Thanks Jan and Erick!

> Remove elevate.xml from the default configs
> ---
>
> Key: SOLR-11021
> URL: https://issues.apache.org/jira/browse/SOLR-11021
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 7.0
>
> Attachments: SOLR-11021.patch
>
>
> SOLR-5541 added the ability to specify id's to elevate on a per request 
> basis. We have the ability to elevate dynamically instead of a static file 
> So to make our default configset smaller and easier to understand we could 
> remove the empty elevate.xml file. 



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

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

[jira] [Commented] (SOLR-11021) Remove elevate.xml from the default configs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11021:


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

SOLR-11021: The elevate.xml config-file is now optional in the 
ElevationComponent. The default configset doesn't ship with an elevate.xml file 
anymore


> Remove elevate.xml from the default configs
> ---
>
> Key: SOLR-11021
> URL: https://issues.apache.org/jira/browse/SOLR-11021
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 7.0
>
> Attachments: SOLR-11021.patch
>
>
> SOLR-5541 added the ability to specify id's to elevate on a per request 
> basis. We have the ability to elevate dynamically instead of a static file 
> So to make our default configset smaller and easier to understand we could 
> remove the empty elevate.xml file. 



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

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

[jira] [Commented] (SOLR-10760) Remove trie field types and fields from example schemas

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-10760:


Oh, it wasn't much of criticism -- I'm all for switching to pointfields. I was 
just concerned about switching when some of the functional areas were/are not 
ready (and I hate to admit I couldn't help out here). 

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10760.patch
>
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



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

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

[jira] [Commented] (SOLR-11021) Remove elevate.xml from the default configs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11021:


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

SOLR-11021: The elevate.xml config-file is now optional in the 
ElevationComponent. The default configset doesn't ship with an elevate.xml file 
anymore


> Remove elevate.xml from the default configs
> ---
>
> Key: SOLR-11021
> URL: https://issues.apache.org/jira/browse/SOLR-11021
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 7.0
>
> Attachments: SOLR-11021.patch
>
>
> SOLR-5541 added the ability to specify id's to elevate on a per request 
> basis. We have the ability to elevate dynamically instead of a static file 
> So to make our default configset smaller and easier to understand we could 
> remove the empty elevate.xml file. 



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

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

[jira] [Commented] (SOLR-11021) Remove elevate.xml from the default configs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11021:


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

SOLR-11021: The elevate.xml config-file is now optional in the 
ElevationComponent. The default configset doesn't ship with an elevate.xml file 
anymore


> Remove elevate.xml from the default configs
> ---
>
> Key: SOLR-11021
> URL: https://issues.apache.org/jira/browse/SOLR-11021
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 7.0
>
> Attachments: SOLR-11021.patch
>
>
> SOLR-5541 added the ability to specify id's to elevate on a per request 
> basis. We have the ability to elevate dynamically instead of a static file 
> So to make our default configset smaller and easier to understand we could 
> remove the empty elevate.xml file. 



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/29/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.solr.search.TestStressLucene.testStressLuceneNRT

Error Message:
MockDirectoryWrapper: cannot close: there are still 7 open files: {_c.fdt=1, 
_d.fdt=1, _h.fdt=1, _e.fdt=1, _a.cfs=1, _g.fdt=1, _f.fdt=1}

Stack Trace:
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are still 
7 open files: {_c.fdt=1, _d.fdt=1, _h.fdt=1, _e.fdt=1, _a.cfs=1, _g.fdt=1, 
_f.fdt=1}
at 
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:841)
at 
org.apache.solr.search.TestStressLucene.testStressLuceneNRT(TestStressLucene.java:370)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: unclosed IndexInput: _e.fdt
at 
org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:732)
at 

[jira] [Updated] (SOLR-11003) Enabling bi-directional CDCR active-active clusters

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-11003:

Attachment: sample-configs.zip

> Enabling bi-directional CDCR active-active clusters
> ---
>
> Key: SOLR-11003
> URL: https://issues.apache.org/jira/browse/SOLR-11003
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
> Attachments: sample-configs.zip, SOLR-11003.patch
>
>
> The latest version of Solr CDCR across collections / clusters is in 
> active-passive format, where we can index into source collection and the 
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a  design ready to index in both collections and the 
> updates gets reflected across the collections in real-time. 
> ClusterACollectionA => ClusterBCollectionB | ClusterBCollectionB => 
> ClusterACollectionA.
> The best use-case would be to we keep indexing in ClusterACollectionA which 
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets 
> down, we point the indexer and searcher application to ClusterBCollectionB. 
> Once ClusterACollectionA is up, depending on updates count, they will be 
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and 
> keep indexing on the ClusterBCollectionB.



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

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

[jira] [Updated] (SOLR-11003) Enabling bi-directional CDCR active-active clusters

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-11003:

Attachment: (was: sample-configs.zip)

> Enabling bi-directional CDCR active-active clusters
> ---
>
> Key: SOLR-11003
> URL: https://issues.apache.org/jira/browse/SOLR-11003
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
> Attachments: sample-configs.zip, SOLR-11003.patch
>
>
> The latest version of Solr CDCR across collections / clusters is in 
> active-passive format, where we can index into source collection and the 
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a  design ready to index in both collections and the 
> updates gets reflected across the collections in real-time. 
> ClusterACollectionA => ClusterBCollectionB | ClusterBCollectionB => 
> ClusterACollectionA.
> The best use-case would be to we keep indexing in ClusterACollectionA which 
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets 
> down, we point the indexer and searcher application to ClusterBCollectionB. 
> Once ClusterACollectionA is up, depending on updates count, they will be 
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and 
> keep indexing on the ClusterBCollectionB.



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

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

[jira] [Commented] (SOLR-10760) Remove trie field types and fields from example schemas

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-10760:
-

bq. Only the implicit criticism of the whole idea in Dawid's comment

AFAIK, the specifics of that (JSON Facet support) is done?   I had thought in 
general that points support had become a blocker to 7 (thus the issue of if 
points support is good enough should be moot... 7 won't ship w/o that?)

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10760.patch
>
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



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

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

[GitHub] lucene-solr pull request #217: added initial .travis.yml

[krichter722]

GitHub user krichter722 opened a pull request:

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

added initial .travis.yml

Already reveals [build failure of Maven 
project](https://travis-ci.org/krichter722/lucene-solr/builds/251276455), so it 
seems useful to use Travis CI.

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

$ git pull https://github.com/krichter722/lucene-solr travis

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

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

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

This closes #217


commit 6dbcc1d8c759a1b0e25b7a43b66da4022142e6b0
Author: Karl-Philipp Richter 
Date:   2017-07-07T18:44:20Z

added initial .travis.yml




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (SOLR-11025) OverseerTest.testShardLeaderChange() failures

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11025:
---

bq. I've just kicked off another round with the patch applied to branch_7x

There were 0 failures on the patched branch_7x out of 200 iterations.

+1 to apply to master+branch_7x.

> OverseerTest.testShardLeaderChange() failures
> -
>
> Key: SOLR-11025
> URL: https://issues.apache.org/jira/browse/SOLR-11025
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11025.patch
>
>
> Non-reproducing Jenkins failure - this test hasn't failed in Jenkins in 
> months, and suddenly several failures within days of each other:
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/18/]:
> {noformat}
> Checking out Revision 986175915927ee2bbd971340f858601c86b3c676 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=OverseerTest 
> -Dtests.method=testShardLeaderChange -Dtests.seed=995C82D4739EF7D8 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ru 
> -Dtests.timezone=Asia/Calcutta -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  223s J2 | OverseerTest.testShardLeaderChange <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Unexpected shard 
> leader coll:collection1 shard:shard1 expected: but was:
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([995C82D4739EF7D8:470F052369060229]:0)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:486)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:720)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=892, maxMBSortInHeap=5.965872045375053, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ru, timezone=Asia/Calcutta
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
> 1.8.0_131 (32-bit)/cpus=8,threads=1,free=96275160,total=293539840
>[junit4]   2> NOTE: All tests run in this JVM: [HardAutoCommitTest, 
> SimplePostToolTest, TestSolrCoreSnapshots, ReplicationFactorTest, 
> TestSolrCoreProperties, TestSha256AuthenticationProvider, 
> TestExpandComponent, TestCloudRecovery, ConfigureRecoveryStrategyTest, 
> TimeZoneUtilsTest, TestTolerantUpdateProcessorRandomCloud, 
> TestExceedMaxTermLength, PrimitiveFieldTypeTest, SolrInfoBeanTest, 
> FullSolrCloudDistribCmdsTest, UniqFieldsUpdateProcessorFactoryTest, 
> TestReplicaProperties, SolrCloudReportersTest, UnloadDistributedZkTest, 
> CleanupOldIndexTest, LeaderInitiatedRecoveryOnShardRestartTest, 
> FastVectorHighlighterTest, TestOrdValues, MinimalSchemaTest, 
> TestSubQueryTransformerCrossCore, ParsingFieldUpdateProcessorsTest, 
> BufferStoreTest, TestLegacyFieldReuse, CollectionsAPISolrJTest, 
> TestSchemalessBufferedUpdates, ConnectionManagerTest, MetricsConfigTest, 
> TestPayloadScoreQParserPlugin, TermVectorComponentDistributedTest, 
> TestLMJelinekMercerSimilarityFactory, TestFastWriter, MultiTermTest, 
> HdfsBasicDistributedZk2Test, V2StandaloneTest, DocumentBuilderTest, 
> TestMultiValuedNumericRangeQuery, AnalyticsMergeStrategyTest, 
> TestNumericTokenStream, TestFieldCacheSort, 
> TestSolrCloudWithSecureImpersonation, TestBlendedInfixSuggestions, 
> ResponseLogComponentTest, CopyFieldTest, TestAuthenticationFramework, 
> BlockJoinFacetDistribTest, TestFieldSortValues, TestJmxIntegration, 
> SolrTestCaseJ4Test, BasicAuthIntegrationTest, URLClassifyProcessorTest, 
> DateFieldTest, TestExactSharedStatsCache, TestFieldTypeCollectionResource, 
> ExplicitHLLTest, ConjunctionSolrSpellCheckerTest, 
> TestLeaderElectionWithEmptyReplica, TestReloadAndDeleteDocs, 
> ClusterStateTest, TestSQLHandler, HdfsRecoverLeaseTest, QueryEqualityTest, 
> UUIDUpdateProcessorFallbackTest, ClassificationUpdateProcessorFactoryTest, 
> DistributedSuggestComponentTest, TestHalfAndHalfDocValues, 
> ShowFileRequestHandlerTest, ExitableDirectoryReaderTest, 
> TestInfoStreamLogging, TestLocalFSCloudBackupRestore, 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest, TestSort, NumericFieldsTest, 
> DirectUpdateHandlerTest, SuggesterFSTTest, NodeMutatorTest, 
> DateMathParserTest, DistribCursorPagingTest, CircularListTest, 
> CloneFieldUpdateProcessorFactoryTest, 
> OverseerCollectionConfigSetProcessorTest, DateRangeFieldTest, 
> TestDFRSimilarityFactory, XsltUpdateRequestHandlerTest, TestConfigSetsAPI, 
> CoreMergeIndexesAdminHandlerTest, TestSerializedLuceneMatchVersion, 
> TestPrepRecovery, TestNoOpRegenerator, DistributedFacetPivotWhiteBoxTest, 
> LeaderFailoverAfterPartitionTest, TestSolrFieldCacheBean, 

[jira] [Updated] (SOLR-11003) Enabling bi-directional CDCR active-active clusters

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-11003:

Attachment: sample-configs.zip

> Enabling bi-directional CDCR active-active clusters
> ---
>
> Key: SOLR-11003
> URL: https://issues.apache.org/jira/browse/SOLR-11003
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
> Attachments: sample-configs.zip, SOLR-11003.patch
>
>
> The latest version of Solr CDCR across collections / clusters is in 
> active-passive format, where we can index into source collection and the 
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a  design ready to index in both collections and the 
> updates gets reflected across the collections in real-time. 
> ClusterACollectionA => ClusterBCollectionB | ClusterBCollectionB => 
> ClusterACollectionA.
> The best use-case would be to we keep indexing in ClusterACollectionA which 
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets 
> down, we point the indexer and searcher application to ClusterBCollectionB. 
> Once ClusterACollectionA is up, depending on updates count, they will be 
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and 
> keep indexing on the ClusterBCollectionB.



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

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

Re: JCC Segfault on Debian 9 (stretch)

[Joshua Campbell]

Hello friends. I tracked down the problem and attached my results to
the relevant bug report. The issue is caused by using kernels after
the patches for CVE-2017-1000364. It can be worked around in a variety
of different ways until the problem is fixed in the kernel or JVM. You
can disable CVE-2017-1000364 protection with a kernel argument I think
that might work. JCC can use more stack before calling JNI_initVM,
that should also work.

HERE IS THE EXPLANATION OF WHAT IS HAPPENING:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865303=False=no#235

On Thu, Jul 6, 2017 at 3:50 PM, Joshua Campbell  wrote:
> Okay so. I built GDB 8 from source (it's new) and that doesn't have bug.
>
> In summary:
>
> Ok TO BE CLEAR, I am closer to the TRUTH than ever. Not only am I not
> stopping, I am working harder. Updates when available. Stay tuned!
>
> It turns out the JVM is crashing on the line commented with "//
> Generate SEGV" so something about Python/JNI/JCC is intefering with
> the JVM's signal handler, as this SEGV is intentional!
>
>
>
> On Thu, Jul 6, 2017 at 12:44 AM, Joshua Campbell  wrote:
>> How would they break oracle's though. It's a binary.
>>
>> On Wed, Jul 5, 2017 at 10:40 PM, Andi Vajda  wrote:
>>>
>>>
>>> > On Jul 6, 2017, at 00:03, Joshua Campbell  wrote:
>>> >
>>> > I confirmed that it crashes on multiple Debian 9 machines but it
>>> > doesn't crash on Ubuntu 16.04. This behavior is consistent regardless
>>> > of the JDK used (I tried openjdk 8, oracle 8 and openjdk 9). I am at a
>>> > loss for how to track it down further due to the (apparent) GDB bug.
>>>
>>> Hmmm, maybe JNI is broken on Debian 9 ?
>>>
>>> Andi..
>>>
>>> >
>>> >> On Wed, Jul 5, 2017 at 2:39 PM, Joshua Campbell 
>>> >> wrote:
>>> >> No, it segfaults.
>>> >>
>>> >>> On Wed, Jul 5, 2017 at 2:26 PM, Andi Vajda  wrote:
>>> >>>
>>>  On Jul 5, 2017, at 22:16, Joshua Campbell 
>>>  wrote:
>>> 
>>>  It's occuring after JCC calls JNI_CreateJavaVM
>>> 
>>>  cpp.py(529): env = initVM(os.pathsep.join(classpath) or None,
>>>  **initvm_args)
>>>  ^ last python trace before death
>>> 
>>>  Breakpoint 5, initVM (self=0x77e05048, args=0x766deac8,
>>>    kwds=0x77e00ec8) at jcc3/sources/jcc.cpp:527
>>>  527 if (JNI_CreateJavaVM(, (void **) _env,
>>>  _args) < 0)
>>>   last line of jcc.cpp before death
>>> 
>>>  (gdb) step
>>> 
>>>  Program received signal SIGSEGV, Segmentation fault.
>>>  0x7fffe43942b4 in ?? ()
>>>  (gdb)
>>> 
>>> 
>>>  AFTER fixing debians debugging symbols with ln -s
>>>  /usr/lib/debug/usr/lib/jvm/java-8-openjdk-amd64
>>>  /usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64
>>> 
>>>  Breakpoint 1, JNI_CreateJavaVM (vm=0x7fffc420,
>>>  penv=0x7fffc418,
>>>    args=0x7fffc450) at
>>>  ./src/hotspot/src/share/vm/prims/jni.cpp:5161
>>>  5161./src/hotspot/src/share/vm/prims/jni.cpp: No such file or
>>>  directory.
>>>  (gdb) s
>>>  JNI_CreateJavaVM (vm=0x7fffc420, penv=0x7fffc418,
>>>  args=0x7fffc450)
>>>    at ./src/hotspot/src/share/vm/prims/jni.cpp:5163
>>>  5163in ./src/hotspot/src/share/vm/prims/jni.cpp
>>>  (gdb)
>>>  /build/gdb-A87voC/gdb-7.12/gdb/inline-frame.c:167: internal-error:
>>>  void inline_frame_this_id(frame_info*, void**, frame_id*): Assertion
>>>  `frame_id_p (*this_id)' failed.
>>>  A problem internal to GDB has been detected,
>>>  further debugging may prove unreliable.
>>>  Quit this debugging session? (y or n) n
>>> 
>>>  This is a bug, please report it.  For instructions, see:
>>>  .
>>> 
>>>  What in the name of heck
>>> >>>
>>> >>> Does it run without gdb ?
>>> >>>
>>> >>> Andi..
>>> >>>
>>> 
>>>  On Wed, Jul 5, 2017 at 11:48 AM, Joshua Campbell
>>>   wrote:
>>> >> But you should get a better stacktrace ?
>>> >
>>> > I got the exact same stacktrace.
>>> >
>>> > $ ldd
>>> >
>>> > venv3/lib/python3.5/site-packages/JCC-3.0-py3.5-linux-x86_64.egg/libjcc3.so
>>> >   linux-vdso.so.1 (0x7ffcf4eb8000)
>>> >   libjava.so =>
>>> > /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libjava.so
>>> > (0x7f412227f000)
>>> >   libjvm.so =>
>>> > /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
>>> > (0x7f412133d000)
>>> >   libpython3.5m.so.1.0 =>
>>> > /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 (0x7f4120c3a000)
>>> >   libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>>> > (0x7f41208b8000)
>>> >   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
>>> > (0x7f41205b4000)
>>> >   

[jira] [Commented] (SOLR-11025) OverseerTest.testShardLeaderChange() failures

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-11025:
---

You da bomb [~steve_rowe]

> OverseerTest.testShardLeaderChange() failures
> -
>
> Key: SOLR-11025
> URL: https://issues.apache.org/jira/browse/SOLR-11025
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11025.patch
>
>
> Non-reproducing Jenkins failure - this test hasn't failed in Jenkins in 
> months, and suddenly several failures within days of each other:
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/18/]:
> {noformat}
> Checking out Revision 986175915927ee2bbd971340f858601c86b3c676 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=OverseerTest 
> -Dtests.method=testShardLeaderChange -Dtests.seed=995C82D4739EF7D8 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ru 
> -Dtests.timezone=Asia/Calcutta -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  223s J2 | OverseerTest.testShardLeaderChange <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Unexpected shard 
> leader coll:collection1 shard:shard1 expected: but was:
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([995C82D4739EF7D8:470F052369060229]:0)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:486)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:720)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=892, maxMBSortInHeap=5.965872045375053, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ru, timezone=Asia/Calcutta
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
> 1.8.0_131 (32-bit)/cpus=8,threads=1,free=96275160,total=293539840
>[junit4]   2> NOTE: All tests run in this JVM: [HardAutoCommitTest, 
> SimplePostToolTest, TestSolrCoreSnapshots, ReplicationFactorTest, 
> TestSolrCoreProperties, TestSha256AuthenticationProvider, 
> TestExpandComponent, TestCloudRecovery, ConfigureRecoveryStrategyTest, 
> TimeZoneUtilsTest, TestTolerantUpdateProcessorRandomCloud, 
> TestExceedMaxTermLength, PrimitiveFieldTypeTest, SolrInfoBeanTest, 
> FullSolrCloudDistribCmdsTest, UniqFieldsUpdateProcessorFactoryTest, 
> TestReplicaProperties, SolrCloudReportersTest, UnloadDistributedZkTest, 
> CleanupOldIndexTest, LeaderInitiatedRecoveryOnShardRestartTest, 
> FastVectorHighlighterTest, TestOrdValues, MinimalSchemaTest, 
> TestSubQueryTransformerCrossCore, ParsingFieldUpdateProcessorsTest, 
> BufferStoreTest, TestLegacyFieldReuse, CollectionsAPISolrJTest, 
> TestSchemalessBufferedUpdates, ConnectionManagerTest, MetricsConfigTest, 
> TestPayloadScoreQParserPlugin, TermVectorComponentDistributedTest, 
> TestLMJelinekMercerSimilarityFactory, TestFastWriter, MultiTermTest, 
> HdfsBasicDistributedZk2Test, V2StandaloneTest, DocumentBuilderTest, 
> TestMultiValuedNumericRangeQuery, AnalyticsMergeStrategyTest, 
> TestNumericTokenStream, TestFieldCacheSort, 
> TestSolrCloudWithSecureImpersonation, TestBlendedInfixSuggestions, 
> ResponseLogComponentTest, CopyFieldTest, TestAuthenticationFramework, 
> BlockJoinFacetDistribTest, TestFieldSortValues, TestJmxIntegration, 
> SolrTestCaseJ4Test, BasicAuthIntegrationTest, URLClassifyProcessorTest, 
> DateFieldTest, TestExactSharedStatsCache, TestFieldTypeCollectionResource, 
> ExplicitHLLTest, ConjunctionSolrSpellCheckerTest, 
> TestLeaderElectionWithEmptyReplica, TestReloadAndDeleteDocs, 
> ClusterStateTest, TestSQLHandler, HdfsRecoverLeaseTest, QueryEqualityTest, 
> UUIDUpdateProcessorFallbackTest, ClassificationUpdateProcessorFactoryTest, 
> DistributedSuggestComponentTest, TestHalfAndHalfDocValues, 
> ShowFileRequestHandlerTest, ExitableDirectoryReaderTest, 
> TestInfoStreamLogging, TestLocalFSCloudBackupRestore, 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest, TestSort, NumericFieldsTest, 
> DirectUpdateHandlerTest, SuggesterFSTTest, NodeMutatorTest, 
> DateMathParserTest, DistribCursorPagingTest, CircularListTest, 
> CloneFieldUpdateProcessorFactoryTest, 
> OverseerCollectionConfigSetProcessorTest, DateRangeFieldTest, 
> TestDFRSimilarityFactory, XsltUpdateRequestHandlerTest, TestConfigSetsAPI, 
> CoreMergeIndexesAdminHandlerTest, TestSerializedLuceneMatchVersion, 
> TestPrepRecovery, TestNoOpRegenerator, DistributedFacetPivotWhiteBoxTest, 
> LeaderFailoverAfterPartitionTest, TestSolrFieldCacheBean, OverseerTest]
> {noformat}
> Following is the first of 4 failures from my Jenkins in the last 24 hours or 
> so on branch_7_0 and branch_7x:
> {noformat}
> 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20083/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseG1GC

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, SolrCore, MockDirectoryWrapper, MockDirectoryWrapper, 
MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:349)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:709)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:934)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:843)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:969)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:904)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:384)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:745)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:726)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:507)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
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.ssl.SslConnection.onFillable(SslConnection.java:202)  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.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1019)  at 
org.apache.solr.core.SolrCore.reload(SolrCore.java:636)  at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1202)  at 
org.apache.solr.handler.IndexFetcher.lambda$reloadCore$0(IndexFetcher.java:900) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  

LIVINGSTONE: sha...@apache.org added you to request # ISD-38838:[ANNOUNCE] [SECURITY] CVE-2017-7660: Security Vulnerability in secure inter-node communication in Apache Solr

[jira . smtp]

Hi dev@lucene.apache.org!









sha...@apache.org has added you as a participant on a request: [ANNOUNCE] [SECURITY] CVE-2017-7660: Security Vulnerability in secure inter-node communication in Apache Solr.
You can access the request in the customer portal or reply to this email to add comments or attachments.




















This message was sent by Service Desk Integration of Email This Issue for JIRA







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

[#SQS-314-11352]: [ANNOUNCE] [SECURITY] CVE-2017-7660: Security Vulnerability in secure inter-node communication in Apache Solr

[Ahsay Support Centre]

Dear Shalin Shekhar Mangar,

Thank you! You have successfully created a ticket to Ahsay Marketing Team with the following details: 


   Ticket ID: SQS-314-11352
   Subject: Request a BIaaS Demo Account
   Department: Marketing @ Ahsay
We will get back to you very shortly by the contact method(s) you provided to us.

Kind regards,
Ahsay Marketing Team


Ahsay Systems Corporation Limited and associated companies, are members of Ahsay Backup Software Development Company Limited (HKEx stock code: 8290), specialising in global backup software development.  For details, please visit our website at http://www.ahsay.com.hk .

 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of Ahsay.

 

Please consider the environment before printing this email


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

[jira] [Comment Edited] (SOLR-11025) OverseerTest.testShardLeaderChange() failures

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-11025 at 7/7/17 6:22 PM:
---

bq. Will committing to master be sufficient a test? Or does it need to go on 7x 
and 7_0 immediately?

I beasted 200 iterations of the whole suite on branch_7x unpatched (using 
Miller's beasting script), and there were 10 failures, all of which were of 
{{.testShardLeaderChange()}}.

I've just kicked off another round with the patch applied to branch_7x, should 
take less than an hour.  I'll report back here when it's done.


was (Author: steve_rowe):
bq. Will committing to master be sufficient a test? Or does it need to go on 7x 
and 7_0 immediately?

I beasted 200 iterations of the whole suite unpatched (using Miller's beasting 
script), and there were 10 failures, all of which were of 
{{.testShardLeaderChange()}}.

I've just kicked off another round with the patch applied, should take less 
than an hour.  I'll report back here when it's done.

> OverseerTest.testShardLeaderChange() failures
> -
>
> Key: SOLR-11025
> URL: https://issues.apache.org/jira/browse/SOLR-11025
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11025.patch
>
>
> Non-reproducing Jenkins failure - this test hasn't failed in Jenkins in 
> months, and suddenly several failures within days of each other:
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/18/]:
> {noformat}
> Checking out Revision 986175915927ee2bbd971340f858601c86b3c676 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=OverseerTest 
> -Dtests.method=testShardLeaderChange -Dtests.seed=995C82D4739EF7D8 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ru 
> -Dtests.timezone=Asia/Calcutta -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  223s J2 | OverseerTest.testShardLeaderChange <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Unexpected shard 
> leader coll:collection1 shard:shard1 expected: but was:
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([995C82D4739EF7D8:470F052369060229]:0)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:486)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:720)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=892, maxMBSortInHeap=5.965872045375053, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ru, timezone=Asia/Calcutta
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
> 1.8.0_131 (32-bit)/cpus=8,threads=1,free=96275160,total=293539840
>[junit4]   2> NOTE: All tests run in this JVM: [HardAutoCommitTest, 
> SimplePostToolTest, TestSolrCoreSnapshots, ReplicationFactorTest, 
> TestSolrCoreProperties, TestSha256AuthenticationProvider, 
> TestExpandComponent, TestCloudRecovery, ConfigureRecoveryStrategyTest, 
> TimeZoneUtilsTest, TestTolerantUpdateProcessorRandomCloud, 
> TestExceedMaxTermLength, PrimitiveFieldTypeTest, SolrInfoBeanTest, 
> FullSolrCloudDistribCmdsTest, UniqFieldsUpdateProcessorFactoryTest, 
> TestReplicaProperties, SolrCloudReportersTest, UnloadDistributedZkTest, 
> CleanupOldIndexTest, LeaderInitiatedRecoveryOnShardRestartTest, 
> FastVectorHighlighterTest, TestOrdValues, MinimalSchemaTest, 
> TestSubQueryTransformerCrossCore, ParsingFieldUpdateProcessorsTest, 
> BufferStoreTest, TestLegacyFieldReuse, CollectionsAPISolrJTest, 
> TestSchemalessBufferedUpdates, ConnectionManagerTest, MetricsConfigTest, 
> TestPayloadScoreQParserPlugin, TermVectorComponentDistributedTest, 
> TestLMJelinekMercerSimilarityFactory, TestFastWriter, MultiTermTest, 
> HdfsBasicDistributedZk2Test, V2StandaloneTest, DocumentBuilderTest, 
> TestMultiValuedNumericRangeQuery, AnalyticsMergeStrategyTest, 
> TestNumericTokenStream, TestFieldCacheSort, 
> TestSolrCloudWithSecureImpersonation, TestBlendedInfixSuggestions, 
> ResponseLogComponentTest, CopyFieldTest, TestAuthenticationFramework, 
> BlockJoinFacetDistribTest, TestFieldSortValues, TestJmxIntegration, 
> SolrTestCaseJ4Test, BasicAuthIntegrationTest, URLClassifyProcessorTest, 
> DateFieldTest, TestExactSharedStatsCache, TestFieldTypeCollectionResource, 
> ExplicitHLLTest, ConjunctionSolrSpellCheckerTest, 
> TestLeaderElectionWithEmptyReplica, TestReloadAndDeleteDocs, 
> ClusterStateTest, TestSQLHandler, HdfsRecoverLeaseTest, QueryEqualityTest, 
> UUIDUpdateProcessorFallbackTest, ClassificationUpdateProcessorFactoryTest, 
> DistributedSuggestComponentTest, 

[jira] [Commented] (SOLR-11025) OverseerTest.testShardLeaderChange() failures

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11025:
---

bq. Will committing to master be sufficient a test? Or does it need to go on 7x 
and 7_0 immediately?

I beasted 200 iterations of the whole suite unpatched (using Miller's beasting 
script), and there were 10 failures, all of which were of 
{{.testShardLeaderChange()}}.

I've just kicked off another round with the patch applied, should take less 
than an hour.  I'll report back here when it's done.

> OverseerTest.testShardLeaderChange() failures
> -
>
> Key: SOLR-11025
> URL: https://issues.apache.org/jira/browse/SOLR-11025
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11025.patch
>
>
> Non-reproducing Jenkins failure - this test hasn't failed in Jenkins in 
> months, and suddenly several failures within days of each other:
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/18/]:
> {noformat}
> Checking out Revision 986175915927ee2bbd971340f858601c86b3c676 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=OverseerTest 
> -Dtests.method=testShardLeaderChange -Dtests.seed=995C82D4739EF7D8 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ru 
> -Dtests.timezone=Asia/Calcutta -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  223s J2 | OverseerTest.testShardLeaderChange <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Unexpected shard 
> leader coll:collection1 shard:shard1 expected: but was:
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([995C82D4739EF7D8:470F052369060229]:0)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:486)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:720)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=892, maxMBSortInHeap=5.965872045375053, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ru, timezone=Asia/Calcutta
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
> 1.8.0_131 (32-bit)/cpus=8,threads=1,free=96275160,total=293539840
>[junit4]   2> NOTE: All tests run in this JVM: [HardAutoCommitTest, 
> SimplePostToolTest, TestSolrCoreSnapshots, ReplicationFactorTest, 
> TestSolrCoreProperties, TestSha256AuthenticationProvider, 
> TestExpandComponent, TestCloudRecovery, ConfigureRecoveryStrategyTest, 
> TimeZoneUtilsTest, TestTolerantUpdateProcessorRandomCloud, 
> TestExceedMaxTermLength, PrimitiveFieldTypeTest, SolrInfoBeanTest, 
> FullSolrCloudDistribCmdsTest, UniqFieldsUpdateProcessorFactoryTest, 
> TestReplicaProperties, SolrCloudReportersTest, UnloadDistributedZkTest, 
> CleanupOldIndexTest, LeaderInitiatedRecoveryOnShardRestartTest, 
> FastVectorHighlighterTest, TestOrdValues, MinimalSchemaTest, 
> TestSubQueryTransformerCrossCore, ParsingFieldUpdateProcessorsTest, 
> BufferStoreTest, TestLegacyFieldReuse, CollectionsAPISolrJTest, 
> TestSchemalessBufferedUpdates, ConnectionManagerTest, MetricsConfigTest, 
> TestPayloadScoreQParserPlugin, TermVectorComponentDistributedTest, 
> TestLMJelinekMercerSimilarityFactory, TestFastWriter, MultiTermTest, 
> HdfsBasicDistributedZk2Test, V2StandaloneTest, DocumentBuilderTest, 
> TestMultiValuedNumericRangeQuery, AnalyticsMergeStrategyTest, 
> TestNumericTokenStream, TestFieldCacheSort, 
> TestSolrCloudWithSecureImpersonation, TestBlendedInfixSuggestions, 
> ResponseLogComponentTest, CopyFieldTest, TestAuthenticationFramework, 
> BlockJoinFacetDistribTest, TestFieldSortValues, TestJmxIntegration, 
> SolrTestCaseJ4Test, BasicAuthIntegrationTest, URLClassifyProcessorTest, 
> DateFieldTest, TestExactSharedStatsCache, TestFieldTypeCollectionResource, 
> ExplicitHLLTest, ConjunctionSolrSpellCheckerTest, 
> TestLeaderElectionWithEmptyReplica, TestReloadAndDeleteDocs, 
> ClusterStateTest, TestSQLHandler, HdfsRecoverLeaseTest, QueryEqualityTest, 
> UUIDUpdateProcessorFallbackTest, ClassificationUpdateProcessorFactoryTest, 
> DistributedSuggestComponentTest, TestHalfAndHalfDocValues, 
> ShowFileRequestHandlerTest, ExitableDirectoryReaderTest, 
> TestInfoStreamLogging, TestLocalFSCloudBackupRestore, 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest, TestSort, NumericFieldsTest, 
> DirectUpdateHandlerTest, SuggesterFSTTest, NodeMutatorTest, 
> DateMathParserTest, DistribCursorPagingTest, CircularListTest, 
> CloneFieldUpdateProcessorFactoryTest, 
> OverseerCollectionConfigSetProcessorTest, DateRangeFieldTest, 
> TestDFRSimilarityFactory, XsltUpdateRequestHandlerTest, 

[jira] [Updated] (SOLR-11021) Remove elevate.xml from the default configs

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11021:
-
Attachment: SOLR-11021.patch

Patch which makes the config file optional and also removes the elevate.xml 
from the default config set.

> Remove elevate.xml from the default configs
> ---
>
> Key: SOLR-11021
> URL: https://issues.apache.org/jira/browse/SOLR-11021
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 7.0
>
> Attachments: SOLR-11021.patch
>
>
> SOLR-5541 added the ability to specify id's to elevate on a per request 
> basis. We have the ability to elevate dynamically instead of a static file 
> So to make our default configset smaller and easier to understand we could 
> remove the empty elevate.xml file. 



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

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

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

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDocAbsent

Error Message:
Did not find the expected number of groups for field intGSF expected:<4> but 
was:<3>

Stack Trace:
java.lang.AssertionError: Did not find the expected number of groups for field 
intGSF expected:<4> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([E3CBA08B85F8D8DC:3D7C7B0360A99819]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDocAbsent(DocValuesNotIndexedTest.java:304)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  

[jira] [Commented] (SOLR-11025) OverseerTest.testShardLeaderChange() failures

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11025:
---

I wouldn't go to 7.0 quite yet, but master and 7x seem reasonable. 

I'll start a beasting run on my Pro with the current master code and see if I 
can get a failure too


> OverseerTest.testShardLeaderChange() failures
> -
>
> Key: SOLR-11025
> URL: https://issues.apache.org/jira/browse/SOLR-11025
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11025.patch
>
>
> Non-reproducing Jenkins failure - this test hasn't failed in Jenkins in 
> months, and suddenly several failures within days of each other:
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/18/]:
> {noformat}
> Checking out Revision 986175915927ee2bbd971340f858601c86b3c676 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=OverseerTest 
> -Dtests.method=testShardLeaderChange -Dtests.seed=995C82D4739EF7D8 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ru 
> -Dtests.timezone=Asia/Calcutta -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  223s J2 | OverseerTest.testShardLeaderChange <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Unexpected shard 
> leader coll:collection1 shard:shard1 expected: but was:
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([995C82D4739EF7D8:470F052369060229]:0)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:486)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:720)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=892, maxMBSortInHeap=5.965872045375053, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ru, timezone=Asia/Calcutta
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
> 1.8.0_131 (32-bit)/cpus=8,threads=1,free=96275160,total=293539840
>[junit4]   2> NOTE: All tests run in this JVM: [HardAutoCommitTest, 
> SimplePostToolTest, TestSolrCoreSnapshots, ReplicationFactorTest, 
> TestSolrCoreProperties, TestSha256AuthenticationProvider, 
> TestExpandComponent, TestCloudRecovery, ConfigureRecoveryStrategyTest, 
> TimeZoneUtilsTest, TestTolerantUpdateProcessorRandomCloud, 
> TestExceedMaxTermLength, PrimitiveFieldTypeTest, SolrInfoBeanTest, 
> FullSolrCloudDistribCmdsTest, UniqFieldsUpdateProcessorFactoryTest, 
> TestReplicaProperties, SolrCloudReportersTest, UnloadDistributedZkTest, 
> CleanupOldIndexTest, LeaderInitiatedRecoveryOnShardRestartTest, 
> FastVectorHighlighterTest, TestOrdValues, MinimalSchemaTest, 
> TestSubQueryTransformerCrossCore, ParsingFieldUpdateProcessorsTest, 
> BufferStoreTest, TestLegacyFieldReuse, CollectionsAPISolrJTest, 
> TestSchemalessBufferedUpdates, ConnectionManagerTest, MetricsConfigTest, 
> TestPayloadScoreQParserPlugin, TermVectorComponentDistributedTest, 
> TestLMJelinekMercerSimilarityFactory, TestFastWriter, MultiTermTest, 
> HdfsBasicDistributedZk2Test, V2StandaloneTest, DocumentBuilderTest, 
> TestMultiValuedNumericRangeQuery, AnalyticsMergeStrategyTest, 
> TestNumericTokenStream, TestFieldCacheSort, 
> TestSolrCloudWithSecureImpersonation, TestBlendedInfixSuggestions, 
> ResponseLogComponentTest, CopyFieldTest, TestAuthenticationFramework, 
> BlockJoinFacetDistribTest, TestFieldSortValues, TestJmxIntegration, 
> SolrTestCaseJ4Test, BasicAuthIntegrationTest, URLClassifyProcessorTest, 
> DateFieldTest, TestExactSharedStatsCache, TestFieldTypeCollectionResource, 
> ExplicitHLLTest, ConjunctionSolrSpellCheckerTest, 
> TestLeaderElectionWithEmptyReplica, TestReloadAndDeleteDocs, 
> ClusterStateTest, TestSQLHandler, HdfsRecoverLeaseTest, QueryEqualityTest, 
> UUIDUpdateProcessorFallbackTest, ClassificationUpdateProcessorFactoryTest, 
> DistributedSuggestComponentTest, TestHalfAndHalfDocValues, 
> ShowFileRequestHandlerTest, ExitableDirectoryReaderTest, 
> TestInfoStreamLogging, TestLocalFSCloudBackupRestore, 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest, TestSort, NumericFieldsTest, 
> DirectUpdateHandlerTest, SuggesterFSTTest, NodeMutatorTest, 
> DateMathParserTest, DistribCursorPagingTest, CircularListTest, 
> CloneFieldUpdateProcessorFactoryTest, 
> OverseerCollectionConfigSetProcessorTest, DateRangeFieldTest, 
> TestDFRSimilarityFactory, XsltUpdateRequestHandlerTest, TestConfigSetsAPI, 
> CoreMergeIndexesAdminHandlerTest, TestSerializedLuceneMatchVersion, 
> TestPrepRecovery, TestNoOpRegenerator, DistributedFacetPivotWhiteBoxTest, 
> LeaderFailoverAfterPartitionTest, TestSolrFieldCacheBean, 

[jira] [Commented] (SOLR-11021) Remove elevate.xml from the default configs

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11021:
--

bq. Perhaps link from managed-schema to ref-guide instead of to old wiki.

Do you mean references in the solrconfig.xml file ? I don't see any references 
to the wiki from managed-schema with the latest changes in SOLR-10967

> Remove elevate.xml from the default configs
> ---
>
> Key: SOLR-11021
> URL: https://issues.apache.org/jira/browse/SOLR-11021
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 7.0
>
>
> SOLR-5541 added the ability to specify id's to elevate on a per request 
> basis. We have the ability to elevate dynamically instead of a static file 
> So to make our default configset smaller and easier to understand we could 
> remove the empty elevate.xml file. 



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

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

[jira] [Commented] (SOLR-11025) OverseerTest.testShardLeaderChange() failures

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-11025:
---

Will committing to master be sufficient a test?  Or does it need to go on 7x 
and 7_0 immediately?

> OverseerTest.testShardLeaderChange() failures
> -
>
> Key: SOLR-11025
> URL: https://issues.apache.org/jira/browse/SOLR-11025
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11025.patch
>
>
> Non-reproducing Jenkins failure - this test hasn't failed in Jenkins in 
> months, and suddenly several failures within days of each other:
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/18/]:
> {noformat}
> Checking out Revision 986175915927ee2bbd971340f858601c86b3c676 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=OverseerTest 
> -Dtests.method=testShardLeaderChange -Dtests.seed=995C82D4739EF7D8 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ru 
> -Dtests.timezone=Asia/Calcutta -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  223s J2 | OverseerTest.testShardLeaderChange <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Unexpected shard 
> leader coll:collection1 shard:shard1 expected: but was:
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([995C82D4739EF7D8:470F052369060229]:0)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:486)
>[junit4]>  at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:720)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=892, maxMBSortInHeap=5.965872045375053, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ru, timezone=Asia/Calcutta
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
> 1.8.0_131 (32-bit)/cpus=8,threads=1,free=96275160,total=293539840
>[junit4]   2> NOTE: All tests run in this JVM: [HardAutoCommitTest, 
> SimplePostToolTest, TestSolrCoreSnapshots, ReplicationFactorTest, 
> TestSolrCoreProperties, TestSha256AuthenticationProvider, 
> TestExpandComponent, TestCloudRecovery, ConfigureRecoveryStrategyTest, 
> TimeZoneUtilsTest, TestTolerantUpdateProcessorRandomCloud, 
> TestExceedMaxTermLength, PrimitiveFieldTypeTest, SolrInfoBeanTest, 
> FullSolrCloudDistribCmdsTest, UniqFieldsUpdateProcessorFactoryTest, 
> TestReplicaProperties, SolrCloudReportersTest, UnloadDistributedZkTest, 
> CleanupOldIndexTest, LeaderInitiatedRecoveryOnShardRestartTest, 
> FastVectorHighlighterTest, TestOrdValues, MinimalSchemaTest, 
> TestSubQueryTransformerCrossCore, ParsingFieldUpdateProcessorsTest, 
> BufferStoreTest, TestLegacyFieldReuse, CollectionsAPISolrJTest, 
> TestSchemalessBufferedUpdates, ConnectionManagerTest, MetricsConfigTest, 
> TestPayloadScoreQParserPlugin, TermVectorComponentDistributedTest, 
> TestLMJelinekMercerSimilarityFactory, TestFastWriter, MultiTermTest, 
> HdfsBasicDistributedZk2Test, V2StandaloneTest, DocumentBuilderTest, 
> TestMultiValuedNumericRangeQuery, AnalyticsMergeStrategyTest, 
> TestNumericTokenStream, TestFieldCacheSort, 
> TestSolrCloudWithSecureImpersonation, TestBlendedInfixSuggestions, 
> ResponseLogComponentTest, CopyFieldTest, TestAuthenticationFramework, 
> BlockJoinFacetDistribTest, TestFieldSortValues, TestJmxIntegration, 
> SolrTestCaseJ4Test, BasicAuthIntegrationTest, URLClassifyProcessorTest, 
> DateFieldTest, TestExactSharedStatsCache, TestFieldTypeCollectionResource, 
> ExplicitHLLTest, ConjunctionSolrSpellCheckerTest, 
> TestLeaderElectionWithEmptyReplica, TestReloadAndDeleteDocs, 
> ClusterStateTest, TestSQLHandler, HdfsRecoverLeaseTest, QueryEqualityTest, 
> UUIDUpdateProcessorFallbackTest, ClassificationUpdateProcessorFactoryTest, 
> DistributedSuggestComponentTest, TestHalfAndHalfDocValues, 
> ShowFileRequestHandlerTest, ExitableDirectoryReaderTest, 
> TestInfoStreamLogging, TestLocalFSCloudBackupRestore, 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest, TestSort, NumericFieldsTest, 
> DirectUpdateHandlerTest, SuggesterFSTTest, NodeMutatorTest, 
> DateMathParserTest, DistribCursorPagingTest, CircularListTest, 
> CloneFieldUpdateProcessorFactoryTest, 
> OverseerCollectionConfigSetProcessorTest, DateRangeFieldTest, 
> TestDFRSimilarityFactory, XsltUpdateRequestHandlerTest, TestConfigSetsAPI, 
> CoreMergeIndexesAdminHandlerTest, TestSerializedLuceneMatchVersion, 
> TestPrepRecovery, TestNoOpRegenerator, DistributedFacetPivotWhiteBoxTest, 
> LeaderFailoverAfterPartitionTest, TestSolrFieldCacheBean, OverseerTest]
> {noformat}
> Following is the first of 4 failures from my Jenkins in the 

Re: [ANNOUNCE] [SECURITY] CVE-2017-7660: Security Vulnerability in secure inter-node communication in Apache Solr

[Ramesh Komuravelli]

Hey all, Commvault is looking for GlusterFS developers, this role is going to 
be very crucial and working closely with CTO. If anyone interested... please 
mail me.

Regards,
Ramesh K

> On 07-Jul-2017, at 7:14 PM, Shalin Shekhar Mangar  wrote:
> 
> CVE-2017-7660: Security Vulnerability in secure inter-node
> communication in Apache Solr
> 
> Severity: Important
> 
> Vendor:
> The Apache Software Foundation
> 
> Versions Affected:
> Solr 5.3 to 5.5.4
> Solr 6.0 to 6.5.1
> 
> Description:
> 
> Solr uses a PKI based mechanism to secure inter-node communication
> when security is enabled. It is possible to create a specially crafted
> node name that does not exist as part of the cluster and point it to a
> malicious node. This can trick the nodes in cluster to believe that
> the malicious node is a member of the cluster. So, if Solr users have
> enabled BasicAuth authentication mechanism using the BasicAuthPlugin
> or if the user has implemented a custom Authentication plugin, which
> does not implement either "HttpClientInterceptorPlugin" or
> "HttpClientBuilderPlugin", his/her servers are vulnerable to this
> attack. Users who only use SSL without basic authentication or those
> who use Kerberos are not affected.
> 
> Mitigation:
> 6.x users should upgrade to 6.6
> 5.x users should obtain the latest source from git and apply this patch:
> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/2f5ecbcf
> 
> Credit:
> This issue was discovered by Noble Paul of Lucidworks Inc.
> 
> References:
> https://issues.apache.org/jira/browse/SOLR-10624
> https://wiki.apache.org/solr/SolrSecurity
> 
> -- 
> The Lucene PMC
***Legal Disclaimer***
"This communication may contain confidential and privileged material for the
sole use of the intended recipient. Any unauthorized review, use or distribution
by others is strictly prohibited. If you have received the message by mistake,
please advise the sender by reply email and delete the message. Thank you."
**

Re: Release planning for 7.0

[Ishan Chattopadhyaya]

Ah, thanks for pointing it out, Erick! I forgot to push to the branch_7_0
apart from branch_7x. Done so now.

On Fri, Jul 7, 2017 at 9:27 PM, Erick Erickson 
wrote:

> Ishan:
>
> I'm a little confused. 7x? Or 7x _and_ 7.0?
>
> On Fri, Jul 7, 2017 at 3:16 AM, Ishan Chattopadhyaya
>  wrote:
> >> Hi Anshum,
> >> I'd like to have SOLR-10282 in for 7.0. It is a low impact new feature
> >> that helps admins to enable
> >> Kerberos more easily using the bin/solr script.
> >> I should be able to have it dev-complete by end of Friday. Let me know
> if
> >> you have any objections.
> >> Thanks,
> >> Ishan
> >
> > Hi Anshum,
> > I've committed it to branch_7x. In case there are any objections, I
> shall be
> > glad to roll it back from branch_7x.
> > Thanks,
> > Ishan
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-10282) bin/solr support for enabling Kerberos security

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10282:


Commit f0f87d07569058d87a2b4d44d9cbeddeeb081ac8 in lucene-solr's branch 
refs/heads/branch_7_0 from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f0f87d0 ]

SOLR-10282: bin/solr support for enabling Kerberos authentication


> bin/solr support for enabling Kerberos security
> ---
>
> Key: SOLR-10282
> URL: https://issues.apache.org/jira/browse/SOLR-10282
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Fix For: 7.0
>
> Attachments: SOLR-10282.patch, SOLR-10282.patch
>
>
> This is in the same spirit as SOLR-8440.



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

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

[jira] [Commented] (SOLR-10760) Remove trie field types and fields from example schemas

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10760:
---

bq.  is there anything else blocking this?

Only the implicit criticism of the whole idea in Dawid's comment on this issue 
( 
https://issues.apache.org/jira/browse/SOLR-10760?focusedCommentId=16027356=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16027356
 ) : we shouldn't flip the default-points-everywhere switch until we know that 
we won't screw users who depend on functionality that doesn't work with points.

Hoss, Tomás and I have been working to nail down (and address) Solr points 
deficiencies, and that process continues, hopefully reaching conclusion before 
the first 7.0 RC.  Right now I'm working on SOLR-10796, should have a roughly 
complete patch up for it today.

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10760.patch
>
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



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

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

[jira] [Resolved] (SOLR-11020) TestUseDocValuesAsStored.testRandomSingleAndMultiValued() failures

[Hoss Man (JIRA)]

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

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

> TestUseDocValuesAsStored.testRandomSingleAndMultiValued() failures
> --
>
> Key: SOLR-11020
> URL: https://issues.apache.org/jira/browse/SOLR-11020
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Hoss Man
> Fix For: 7.0, master (8.0), 7.1
>
>
> Reproducing failure from Policeman Jenkins 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20061/]:
> {noformat}
> Checking out Revision cb23fa9b4efa5fc7c17f215f507901d459e9aa6f 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestUseDocValuesAsStored 
> -Dtests.method=testRandomSingleAndMultiValued -Dtests.seed=41EB0B5C781BBEEC 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en -Dtests.timezone=CNT 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   3.97s J0 | 
> TestUseDocValuesAsStored.testRandomSingleAndMultiValued <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
> query
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([41EB0B5C781BBEEC:48B7F69D00C4AFD4]:0)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
>[junit4]>  at 
> org.apache.solr.schema.TestUseDocValuesAsStored.doTest(TestUseDocValuesAsStored.java:335)
>[junit4]>  at 
> org.apache.solr.schema.TestUseDocValuesAsStored.testRandomSingleAndMultiValued(TestUseDocValuesAsStored.java:176)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
> xpath=*[count(//arr[@name='test_fs_dvo']/float) = 5]
>[junit4]>  xml response was: 
>[junit4]> 
>[junit4]> 0 name="QTime">0 start="0"> name="test_fs_dvo">-7.5113335E32-6.931654E22-1.70372E-144.3711085E16NaNNaN
>[junit4]> 
>[junit4]>  request was:q=id:59=test_fs_dvo=xml
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=440, maxMBSortInHeap=7.286261706944515, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=en, timezone=CNT
>[junit4]   2> NOTE: Linux 4.10.0-21-generic amd64/Oracle Corporation 
> 1.8.0_131 (64-bit)/cpus=8,threads=1,free=221971640,total=518979584
> {noformat}
> Another reproducing master failure from my Jenkins (commit 
> {{d81daf54b4b567327c6ebde94b2b2eedacf19cd6}}):
> {noformat}
>   [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestUseDocValuesAsStored 
> -Dtests.method=testRandomSingleAndMultiValued -Dtests.seed=CC2360F81A4AA5F6 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Asia/Anadyr -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   2.57s | 
> TestUseDocValuesAsStored.testRandomSingleAndMultiValued <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
> query
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([CC2360F81A4AA5F6:C57F9D396295B4CE]:0)
>[junit4]>at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
>[junit4]>at 
> org.apache.solr.schema.TestUseDocValuesAsStored.doTest(TestUseDocValuesAsStored.java:335)
>[junit4]>at 
> org.apache.solr.schema.TestUseDocValuesAsStored.testRandomSingleAndMultiValued(TestUseDocValuesAsStored.java:176)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
> xpath=*[count(//arr[@name='test_fs_dvo']/float) = 3]
>[junit4]>xml response was:  encoding="UTF-8"?>
>[junit4]> 
>[junit4]> 0 name="QTime">0 start="0"> name="test_fs_dvo">-4.92691195E175.081205E19NaNNaN
>[junit4]> 
>[junit4]>request was:q=id:41=test_fs_dvo=xml
>[junit4]>at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
>[junit4]>... 41 more
>[junit4]   2> NOTE: leaving temporary files on disk at: 
> /home/sarowe/git/lucene-solr/solr/build/solr-core/test/J0/temp/solr.schema.TestUseDocValuesAsStored_CC2360F81A4AA5F6-001
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=1800, maxMBSortInHeap=7.612083635663545, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=mk-MK, 

[jira] [Resolved] (SOLR-10964) in LTRRescorer reduce SolrIndexSearcher casting

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-10964.

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

> in LTRRescorer reduce SolrIndexSearcher casting
> ---
>
> Key: SOLR-10964
> URL: https://issues.apache.org/jira/browse/SOLR-10964
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10964.patch
>
>
> If feature logging is not configured then the (cast or uncast) searcher would 
> never be used.
> Also, this would allow tests to use IndexSearcher instead of 
> SolrIndexSearcher where convenient.



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

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

[jira] [Resolved] (SOLR-10985) Clean up debug logging statements in solr-core's search package

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-10985.

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

Thanks Michael!

> Clean up debug logging statements in solr-core's search package
> ---
>
> Key: SOLR-10985
> URL: https://issues.apache.org/jira/browse/SOLR-10985
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Michael Braun
>Assignee: Christine Poerschke
>Priority: Trivial
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10985.patch, SOLR-10985.patch
>
>
> Clean up debug-level statements in solr-core's search package that are not 
> using parameterized logging and/or are manually calling toString() on method 
> arguments.



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

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

[jira] [Commented] (SOLR-10985) Clean up debug logging statements in solr-core's search package

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10985:


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

SOLR-10985: Remove unnecessary toString() calls in solr-core's search package's 
debug logging.
(Michael Braun via Christine Poerschke)


> Clean up debug logging statements in solr-core's search package
> ---
>
> Key: SOLR-10985
> URL: https://issues.apache.org/jira/browse/SOLR-10985
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Michael Braun
>Assignee: Christine Poerschke
>Priority: Trivial
> Attachments: SOLR-10985.patch, SOLR-10985.patch
>
>
> Clean up debug-level statements in solr-core's search package that are not 
> using parameterized logging and/or are manually calling toString() on method 
> arguments.



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

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

[jira] [Commented] (SOLR-10964) in LTRRescorer reduce SolrIndexSearcher casting

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10964:


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

SOLR-10964: Reduce SolrIndexSearcher casting in LTRRescorer.


> in LTRRescorer reduce SolrIndexSearcher casting
> ---
>
> Key: SOLR-10964
> URL: https://issues.apache.org/jira/browse/SOLR-10964
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10964.patch
>
>
> If feature logging is not configured then the (cast or uncast) searcher would 
> never be used.
> Also, this would allow tests to use IndexSearcher instead of 
> SolrIndexSearcher where convenient.



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

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

[jira] [Commented] (SOLR-10992) the default for stopwords should be disabled

[JIRA]

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

Jan Høydahl commented on SOLR-10992:


We could even provide a "add-multilingual-to-schema.json" that when posted to 
schema API would add in all the relevant fieldTypes and dynamic fields given a 
_default configset.

> the default for stopwords should be disabled
> 
>
> Key: SOLR-10992
> URL: https://issues.apache.org/jira/browse/SOLR-10992
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: config-api
>Affects Versions: 6.6
> Environment: All
>Reporter: Rick Leir
>Priority: Minor
>  Labels: beginner
>
> Suggest removing the stopword filter from the example configs. It is not a 
> “best practice” or even a recommended practice. 
> This was discussed in the user mailing list (link below).
> I chose the wrong component above, what should it have been?



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

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

[jira] [Commented] (SOLR-10985) Clean up debug logging statements in solr-core's search package

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10985:


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

SOLR-10985: Remove unnecessary toString() calls in solr-core's search package's 
debug logging.
(Michael Braun via Christine Poerschke)


> Clean up debug logging statements in solr-core's search package
> ---
>
> Key: SOLR-10985
> URL: https://issues.apache.org/jira/browse/SOLR-10985
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Michael Braun
>Assignee: Christine Poerschke
>Priority: Trivial
> Attachments: SOLR-10985.patch, SOLR-10985.patch
>
>
> Clean up debug-level statements in solr-core's search package that are not 
> using parameterized logging and/or are manually calling toString() on method 
> arguments.



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

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

[jira] [Commented] (SOLR-10964) in LTRRescorer reduce SolrIndexSearcher casting

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10964:


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

SOLR-10964: Reduce SolrIndexSearcher casting in LTRRescorer.


> in LTRRescorer reduce SolrIndexSearcher casting
> ---
>
> Key: SOLR-10964
> URL: https://issues.apache.org/jira/browse/SOLR-10964
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10964.patch
>
>
> If feature logging is not configured then the (cast or uncast) searcher would 
> never be used.
> Also, this would allow tests to use IndexSearcher instead of 
> SolrIndexSearcher where convenient.



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/14/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseSerialGC

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

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrIndexConfig_7697CC659D7296BF-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrIndexConfig_7697CC659D7296BF-001\init-core-data-001

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

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

at __randomizedtesting.SeedInfo.seed([7697CC659D7296BF]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12247 lines...]
   [junit4] Suite: org.apache.solr.core.TestSolrIndexConfig
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrIndexConfig_7697CC659D7296BF-001\init-core-data-001
   [junit4]   2> 1831594 WARN  
(SUITE-TestSolrIndexConfig-seed#[7697CC659D7296BF]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2
   [junit4]   2> 1831594 INFO  
(SUITE-TestSolrIndexConfig-seed#[7697CC659D7296BF]-worker) [] 
o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) 
w/NUMERIC_DOCVALUES_SYSPROP=true
   [junit4]   2> 1831594 INFO  
(SUITE-TestSolrIndexConfig-seed#[7697CC659D7296BF]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 1831594 INFO  
(SUITE-TestSolrIndexConfig-seed#[7697CC659D7296BF]-worker) [] 
o.a.s.SolrTestCaseJ4 initCore
   [junit4]   2> 1831594 INFO  
(SUITE-TestSolrIndexConfig-seed#[7697CC659D7296BF]-worker) [] 
o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths: 
[/C:/Users/jenkins/workspace/Lucene-Solr-7.x-Windows/solr/core/src/test-files/solr/collection1/lib,
 
/C:/Users/jenkins/workspace/Lucene-Solr-7.x-Windows/solr/core/src/test-files/solr/collection1/lib/classes]
   [junit4]   2> 1831625 INFO  
(SUITE-TestSolrIndexConfig-seed#[7697CC659D7296BF]-worker) [] 
o.a.s.u.SolrIndexConfig IndexWriter infoStream solr logging is enabled
   [junit4]   2> 1831625 INFO  
(SUITE-TestSolrIndexConfig-seed#[7697CC659D7296BF]-worker) [] 
o.a.s.c.SolrConfig Using Lucene MatchVersion: 7.1.0
   [junit4]   2> 1831641 INFO  
(SUITE-TestSolrIndexConfig-seed#[7697CC659D7296BF]-worker) [] 
o.a.s.s.IndexSchema [null] Schema name=test
   [junit4]   2> 1831734 INFO  
(SUITE-TestSolrIndexConfig-seed#[7697CC659D7296BF]-worker) [] 

[jira] [Resolved] (SOLR-10987) Solr Cloud overseer node becomes unreachable. Issue Started Recently

[Erick Erickson (JIRA)]

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

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

The JIRA system is for raising issues with the code, not an free support 
portal. Raising a JIRA, as a blocker etc. for what is most likely something in 
your installation for a release that is over a year old is far outside accepted 
usage. If you need help analyzing your particular installation's issues I 
suggest you engage a professional consultant.

> Solr Cloud overseer node becomes unreachable. Issue Started Recently
> 
>
> Key: SOLR-10987
> URL: https://issues.apache.org/jira/browse/SOLR-10987
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.1
> Environment: *The following is the usage on each of the Solr Nodes:*
> Tasks: 254 total,   1 running, 252 sleeping,   0 stopped,   1 zombie
> %Cpu(s):  0.4 us,  0.3 sy,  0.0 ni, 99.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 
> st
> KiB Mem : 20392276 total,  4169296 free,  2917012 used, 13305968 buff/cache
> KiB Swap:  5111804 total,  5111636 free,  168 used. 16058184 avail Mem
>   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
> 21250 solr  20   0 23.599g 1.184g 228440 S   2.0  6.1  59:55.91 java
> *Solr is running on 5 machines with similar configuration:*
> Architecture:  x86_64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Little Endian
> CPU(s):4
> On-line CPU(s) list:   0-3
> Thread(s) per core:1
> Core(s) per socket:2
> Socket(s): 2
> NUMA node(s):  1
> Vendor ID: GenuineIntel
> CPU family:6
> Model: 62
> Model name:Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
> Stepping:  4
> CPU MHz:   2799.033
> BogoMIPS:  5600.00
> Hypervisor vendor: VMware
> Virtualization type:   full
> L1d cache: 32K
> L1i cache: 32K
> L2 cache:  256K
> L3 cache:  25600K
> NUMA node0 CPU(s): 0-3
>Reporter: RAHAT BHALLA
>Priority: Blocker
>  Labels: assistance, critical, customer, impacting, issue, need, 
> production
> Attachments: solr.zip
>
>
> We host a Solr Cloud of 5 Nodes for Solr Instances and 3 Zookeeper nodes to 
> maintain the cloud. We have over 70 million docs spread across 13 collections 
> with 40K more documents being added every day almost near time within spans 
> of 5 to 6 minutes.
> The System was working as expected and as required for th elast 7 months 
> until suddenly we saw the following exception and all of our instances went 
> offline. We restarted the instances and the cloud ran smoothly for three days 
> before it came crashing down again.
> *Exception It gives before it goes down is as follows:*
> 3542285 ERROR 
> (OverseerCollectionConfigSetProcessor-98221003671470081-prod-solr-node01:9080_solr-n_000106)
>  [   ] o.a.s.c.OverseerTaskProcessor
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode 
> = ConnectionLoss for /overseer_elect/leader
> at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
> at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155)
> at 
> org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:348)
> at 
> org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:345)
> at 
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at 
> org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:345)
> at 
> org.apache.solr.cloud.OverseerTaskProcessor.amILeader(OverseerTaskProcessor.java:384)
> at 
> org.apache.solr.cloud.OverseerTaskProcessor.run(OverseerTaskProcessor.java:191)
> at java.lang.Thread.run(Unknown Source)



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

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

[jira] [Commented] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-6630:


+1 for "manual".  "explicit" doesn't really right when the route isn't 
explicitly set in the document or on the update command, and "custom" or 
"userDefined" suggest you need to configure/set something up.

> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Shawn Heisey
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
>  all my documents end up on just one of my 24 shards. What
>  might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router.  that means that
>   documents will be indexed on the shard you sent them
> to, not
>   routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
>  impression that implicit router would use a hash of the
>  uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name.  It's technically
> correct,
>   but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person.  This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead?  Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log.  Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning.  If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.



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

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

[jira] [Commented] (SOLR-10992) the default for stopwords should be disabled

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10992:
---

I do see one issue here. First let me say I'm all for removing stopwords (+1, 
just to see if it's only a plus sign in the leading position that seems to get 
stripped lately). For that matter I'm also in favor of removing all the extra 
languages etc and super-especially the things like elevate that break 
startup OK, enough ranting.

I usually recommend to clients when they upgrade that they take the configs 
from the new version and copy/paste their changes over from their old 
configuration rather than just carry their old ones forward to a new version, 
especially when they're moving to a new major version.

This is going to bite them a bit as it's likely they'll overlook something like 
removing stopwords for the fields they use "as is", which many do (text_en 
comes to mind).

That said bout the max I'd advocate is a comment in the configs or maybe the 
upgrade notes in CHANGES.txt to the effect of "compare your schema definitions 
carefully since stopwords have been removed". Well, something better than that 
but you get the idea. I suppose it's one more incentive to re-index.

> the default for stopwords should be disabled
> 
>
> Key: SOLR-10992
> URL: https://issues.apache.org/jira/browse/SOLR-10992
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: config-api
>Affects Versions: 6.6
> Environment: All
>Reporter: Rick Leir
>Priority: Minor
>  Labels: beginner
>
> Suggest removing the stopword filter from the example configs. It is not a 
> “best practice” or even a recommended practice. 
> This was discussed in the user mailing list (link below).
> I chose the wrong component above, what should it have been?



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

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

[jira] [Commented] (SOLR-10803) Solr should refuse to create Trie*Field instances in 7.0 indices

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-10803:
-

Seems like SOLR-10760 should be sufficient to have people use point fields by 
default.

> Solr should refuse to create Trie*Field instances in 7.0 indices
> 
>
> Key: SOLR-10803
> URL: https://issues.apache.org/jira/browse/SOLR-10803
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Adrien Grand
>Priority: Blocker
> Fix For: 7.0
>
>
> If we want to be able to remove support for legacy numerics from Solr in 8.0, 
> we need to forbid the use of Trie*Field in indices that are created on or 
> after 7.0.



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

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

Re: Release planning for 7.0

[Erick Erickson]

Ishan:

I'm a little confused. 7x? Or 7x _and_ 7.0?

On Fri, Jul 7, 2017 at 3:16 AM, Ishan Chattopadhyaya
 wrote:
>> Hi Anshum,
>> I'd like to have SOLR-10282 in for 7.0. It is a low impact new feature
>> that helps admins to enable
>> Kerberos more easily using the bin/solr script.
>> I should be able to have it dev-complete by end of Friday. Let me know if
>> you have any objections.
>> Thanks,
>> Ishan
>
> Hi Anshum,
> I've committed it to branch_7x. In case there are any objections, I shall be
> glad to roll it back from branch_7x.
> Thanks,
> Ishan
>

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

[jira] [Commented] (SOLR-10760) Remove trie field types and fields from example schemas

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-10760:
-

+1 to these changes... is there anything else blocking this?

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10760.patch
>
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



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

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

[jira] [Commented] (SOLR-6671) Introduce a solr.data.home as root dir for all data

[JIRA]

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

Jan Høydahl commented on SOLR-6671:
---

Shalin, can u create a new jira for the metrics and one for getDataHome? 

> Introduce a solr.data.home as root dir for all data
> ---
>
> Key: SOLR-6671
> URL: https://issues.apache.org/jira/browse/SOLR-6671
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Affects Versions: 4.10.1
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 7.0
>
> Attachments: SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch, 
> SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch, 
> SOLR-6671.patch
>
>
> Many users prefer to deploy code, config and data on separate disk locations, 
> so the default of placing the indexes under 
> {{$\{solr.solr.home\}/$\{solr.core.name\}/data}} is not always wanted.
> In a multi-core/collection system, there is not much help in the 
> {{solr.data.dir}} option, as it would set the {{dataDir}} to the same folder 
> for all collections. One workaround, if you don't want to hardcode paths in 
> your {{solrconfig.xml}}, is to specify the {{dataDir}} property in each 
> {{solr.properties}} file.
> A more elegant solution would be to introduce a new Java-option 
> {{solr.data.home}} which would be to data the same as {{solr.solr.home}} is 
> for config. If set, all collections would default their {{dataDir}} as 
> {{$\{solr.data.home\)/$\{solr.core.name\}/data}}



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

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1348 - Still unstable

[Apache Jenkins Server]

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

6 tests failed.
FAILED:  org.apache.lucene.index.TestIndexSorting.testRandom3

Error Message:
Test abandoned because suite timeout was reached.

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


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

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

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


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

Error Message:
The Monkey ran for over 45 seconds and no jetties were stopped - this is worth 
investigating!

Stack Trace:
java.lang.AssertionError: The Monkey ran for over 45 seconds and no jetties 
were stopped - this is worth investigating!
at 
__randomizedtesting.SeedInfo.seed([DB34AC9D0CDE7527:53609347A22218DF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.apache.solr.cloud.ChaosMonkey.stopTheMonkey(ChaosMonkey.java:587)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-10924) PointField multivalued docValues don't "dedup" like TrieField

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10924:


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

SOLR-10989: Fixup to correct SOLR-11020 test failures (root discrepency caused 
by SOLR-10924)

(cherry picked from commit 5d1f57f8823e5b6fec5cc617606db6b714c8aaef)


> PointField multivalued docValues don't "dedup" like TrieField
> -
>
> Key: SOLR-10924
> URL: https://issues.apache.org/jira/browse/SOLR-10924
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> As noted by Tomas in SOLR-10835, since the numeric FooPointField classes use 
> SortedNumericDocValues, the docvalues don't "dedup" when the same value 
> exists multiple times for a single document -- this is different from the 
> numeric TrieFooField classes that use SortedSetDocValues - which are by 
> definition a _set_ -- so multiple instances of the same value are 
> de-duplicated.
> This impacts things like the ExportWriter, as well as fields that 
> {{useDocValuesAsStored="true"}} if users have particular expecations when 
> converting from Trie fields to Point fields.



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

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

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-9-ea+173) - Build # 6718 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6718/
Java: 64bit/jdk-9-ea+173 -XX:-UseCompressedOops -XX:+UseParallelGC

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

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:61218/collection1
at 
__randomizedtesting.SeedInfo.seed([503CE89EF318D389:D868D7445DE4BE71]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1581)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:213)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (SOLR-11020) TestUseDocValuesAsStored.testRandomSingleAndMultiValued() failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11020:


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

SOLR-10989: Fixup to correct SOLR-11020 test failures (root discrepency caused 
by SOLR-10924)

(cherry picked from commit 5d1f57f8823e5b6fec5cc617606db6b714c8aaef)


> TestUseDocValuesAsStored.testRandomSingleAndMultiValued() failures
> --
>
> Key: SOLR-11020
> URL: https://issues.apache.org/jira/browse/SOLR-11020
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Hoss Man
>
> Reproducing failure from Policeman Jenkins 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20061/]:
> {noformat}
> Checking out Revision cb23fa9b4efa5fc7c17f215f507901d459e9aa6f 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestUseDocValuesAsStored 
> -Dtests.method=testRandomSingleAndMultiValued -Dtests.seed=41EB0B5C781BBEEC 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en -Dtests.timezone=CNT 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   3.97s J0 | 
> TestUseDocValuesAsStored.testRandomSingleAndMultiValued <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
> query
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([41EB0B5C781BBEEC:48B7F69D00C4AFD4]:0)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
>[junit4]>  at 
> org.apache.solr.schema.TestUseDocValuesAsStored.doTest(TestUseDocValuesAsStored.java:335)
>[junit4]>  at 
> org.apache.solr.schema.TestUseDocValuesAsStored.testRandomSingleAndMultiValued(TestUseDocValuesAsStored.java:176)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
> xpath=*[count(//arr[@name='test_fs_dvo']/float) = 5]
>[junit4]>  xml response was: 
>[junit4]> 
>[junit4]> 0 name="QTime">0 start="0"> name="test_fs_dvo">-7.5113335E32-6.931654E22-1.70372E-144.3711085E16NaNNaN
>[junit4]> 
>[junit4]>  request was:q=id:59=test_fs_dvo=xml
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=440, maxMBSortInHeap=7.286261706944515, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=en, timezone=CNT
>[junit4]   2> NOTE: Linux 4.10.0-21-generic amd64/Oracle Corporation 
> 1.8.0_131 (64-bit)/cpus=8,threads=1,free=221971640,total=518979584
> {noformat}
> Another reproducing master failure from my Jenkins (commit 
> {{d81daf54b4b567327c6ebde94b2b2eedacf19cd6}}):
> {noformat}
>   [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestUseDocValuesAsStored 
> -Dtests.method=testRandomSingleAndMultiValued -Dtests.seed=CC2360F81A4AA5F6 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Asia/Anadyr -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   2.57s | 
> TestUseDocValuesAsStored.testRandomSingleAndMultiValued <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
> query
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([CC2360F81A4AA5F6:C57F9D396295B4CE]:0)
>[junit4]>at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
>[junit4]>at 
> org.apache.solr.schema.TestUseDocValuesAsStored.doTest(TestUseDocValuesAsStored.java:335)
>[junit4]>at 
> org.apache.solr.schema.TestUseDocValuesAsStored.testRandomSingleAndMultiValued(TestUseDocValuesAsStored.java:176)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
> xpath=*[count(//arr[@name='test_fs_dvo']/float) = 3]
>[junit4]>xml response was:  encoding="UTF-8"?>
>[junit4]> 
>[junit4]> 0 name="QTime">0 start="0"> name="test_fs_dvo">-4.92691195E175.081205E19NaNNaN
>[junit4]> 
>[junit4]>request was:q=id:41=test_fs_dvo=xml
>[junit4]>at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
>[junit4]>... 41 more
>[junit4]   2> NOTE: leaving temporary files on disk at: 
> 

[jira] [Commented] (SOLR-10989) Randomize PointFields and general cleanup in schema files that have completley unused Trie fieldTYpes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10989:


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

SOLR-10989: Fixup to correct SOLR-11020 test failures (root discrepency caused 
by SOLR-10924)

(cherry picked from commit 5d1f57f8823e5b6fec5cc617606db6b714c8aaef)


> Randomize PointFields and general cleanup in schema files that have 
> completley unused Trie fieldTYpes
> -
>
> Key: SOLR-10989
> URL: https://issues.apache.org/jira/browse/SOLR-10989
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 7.0
>
>
> while working on parent issue i noticed a schema filed that declared some 
> TrieField fieldTypes that were completely unused by and field or dynamicField 
> declarations.  so i write a quick little perl script to find more of these, 
> manually cleaned up all the ones that seemed like no brainers, and then added 
> the points randomization to replace the remaining Trie fieldtypes (that are 
> used) in these schemas...
> * core/src/test-files/solr/collection1/conf/bad-schema-dup-fieldType.xml
> * core/src/test-files/solr/collection1/conf/schema-binaryfield.xml
> * core/src/test-files/solr/collection1/conf/schema-copyfield-test.xml
> * core/src/test-files/solr/collection1/conf/schema-customfield.xml
> * core/src/test-files/solr/collection1/conf/schema-non-stored-docvalues.xml
> * core/src/test-files/solr/collection1/conf/schema-not-required-unique-key.xml
> * core/src/test-files/solr/collection1/conf/schema-replication1.xml
> * core/src/test-files/solr/collection1/conf/schema-replication2.xml
> * core/src/test-files/solr/collection1/conf/schema-required-fields.xml
> * core/src/test-files/solr/collection1/conf/schema-reversed.xml
> * core/src/test-files/solr/collection1/conf/schema-tokenizer-test.xml
> * core/src/test-files/solr/collection1/conf/schema-version-dv.xml
> * core/src/test-files/solr/collection1/conf/schema-version-indexed.xml



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

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

[jira] [Commented] (SOLR-11020) TestUseDocValuesAsStored.testRandomSingleAndMultiValued() failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11020:


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

SOLR-10989: Fixup to correct SOLR-11020 test failures (root discrepency caused 
by SOLR-10924)

(cherry picked from commit 5d1f57f8823e5b6fec5cc617606db6b714c8aaef)


> TestUseDocValuesAsStored.testRandomSingleAndMultiValued() failures
> --
>
> Key: SOLR-11020
> URL: https://issues.apache.org/jira/browse/SOLR-11020
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Hoss Man
>
> Reproducing failure from Policeman Jenkins 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20061/]:
> {noformat}
> Checking out Revision cb23fa9b4efa5fc7c17f215f507901d459e9aa6f 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestUseDocValuesAsStored 
> -Dtests.method=testRandomSingleAndMultiValued -Dtests.seed=41EB0B5C781BBEEC 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en -Dtests.timezone=CNT 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   3.97s J0 | 
> TestUseDocValuesAsStored.testRandomSingleAndMultiValued <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
> query
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([41EB0B5C781BBEEC:48B7F69D00C4AFD4]:0)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
>[junit4]>  at 
> org.apache.solr.schema.TestUseDocValuesAsStored.doTest(TestUseDocValuesAsStored.java:335)
>[junit4]>  at 
> org.apache.solr.schema.TestUseDocValuesAsStored.testRandomSingleAndMultiValued(TestUseDocValuesAsStored.java:176)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
> xpath=*[count(//arr[@name='test_fs_dvo']/float) = 5]
>[junit4]>  xml response was: 
>[junit4]> 
>[junit4]> 0 name="QTime">0 start="0"> name="test_fs_dvo">-7.5113335E32-6.931654E22-1.70372E-144.3711085E16NaNNaN
>[junit4]> 
>[junit4]>  request was:q=id:59=test_fs_dvo=xml
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=440, maxMBSortInHeap=7.286261706944515, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=en, timezone=CNT
>[junit4]   2> NOTE: Linux 4.10.0-21-generic amd64/Oracle Corporation 
> 1.8.0_131 (64-bit)/cpus=8,threads=1,free=221971640,total=518979584
> {noformat}
> Another reproducing master failure from my Jenkins (commit 
> {{d81daf54b4b567327c6ebde94b2b2eedacf19cd6}}):
> {noformat}
>   [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestUseDocValuesAsStored 
> -Dtests.method=testRandomSingleAndMultiValued -Dtests.seed=CC2360F81A4AA5F6 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Asia/Anadyr -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   2.57s | 
> TestUseDocValuesAsStored.testRandomSingleAndMultiValued <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
> query
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([CC2360F81A4AA5F6:C57F9D396295B4CE]:0)
>[junit4]>at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
>[junit4]>at 
> org.apache.solr.schema.TestUseDocValuesAsStored.doTest(TestUseDocValuesAsStored.java:335)
>[junit4]>at 
> org.apache.solr.schema.TestUseDocValuesAsStored.testRandomSingleAndMultiValued(TestUseDocValuesAsStored.java:176)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
> xpath=*[count(//arr[@name='test_fs_dvo']/float) = 3]
>[junit4]>xml response was:  encoding="UTF-8"?>
>[junit4]> 
>[junit4]> 0 name="QTime">0 start="0"> name="test_fs_dvo">-4.92691195E175.081205E19NaNNaN
>[junit4]> 
>[junit4]>request was:q=id:41=test_fs_dvo=xml
>[junit4]>at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
>[junit4]>... 41 more
>[junit4]   2> NOTE: leaving temporary files on disk at: 
> 

[jira] [Commented] (SOLR-10924) PointField multivalued docValues don't "dedup" like TrieField

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10924:


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

SOLR-10989: Fixup to correct SOLR-11020 test failures (root discrepency caused 
by SOLR-10924)

(cherry picked from commit 5d1f57f8823e5b6fec5cc617606db6b714c8aaef)


> PointField multivalued docValues don't "dedup" like TrieField
> -
>
> Key: SOLR-10924
> URL: https://issues.apache.org/jira/browse/SOLR-10924
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> As noted by Tomas in SOLR-10835, since the numeric FooPointField classes use 
> SortedNumericDocValues, the docvalues don't "dedup" when the same value 
> exists multiple times for a single document -- this is different from the 
> numeric TrieFooField classes that use SortedSetDocValues - which are by 
> definition a _set_ -- so multiple instances of the same value are 
> de-duplicated.
> This impacts things like the ExportWriter, as well as fields that 
> {{useDocValuesAsStored="true"}} if users have particular expecations when 
> converting from Trie fields to Point fields.



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

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

[jira] [Commented] (SOLR-10989) Randomize PointFields and general cleanup in schema files that have completley unused Trie fieldTYpes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10989:


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

SOLR-10989: Fixup to correct SOLR-11020 test failures (root discrepency caused 
by SOLR-10924)

(cherry picked from commit 5d1f57f8823e5b6fec5cc617606db6b714c8aaef)


> Randomize PointFields and general cleanup in schema files that have 
> completley unused Trie fieldTYpes
> -
>
> Key: SOLR-10989
> URL: https://issues.apache.org/jira/browse/SOLR-10989
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 7.0
>
>
> while working on parent issue i noticed a schema filed that declared some 
> TrieField fieldTypes that were completely unused by and field or dynamicField 
> declarations.  so i write a quick little perl script to find more of these, 
> manually cleaned up all the ones that seemed like no brainers, and then added 
> the points randomization to replace the remaining Trie fieldtypes (that are 
> used) in these schemas...
> * core/src/test-files/solr/collection1/conf/bad-schema-dup-fieldType.xml
> * core/src/test-files/solr/collection1/conf/schema-binaryfield.xml
> * core/src/test-files/solr/collection1/conf/schema-copyfield-test.xml
> * core/src/test-files/solr/collection1/conf/schema-customfield.xml
> * core/src/test-files/solr/collection1/conf/schema-non-stored-docvalues.xml
> * core/src/test-files/solr/collection1/conf/schema-not-required-unique-key.xml
> * core/src/test-files/solr/collection1/conf/schema-replication1.xml
> * core/src/test-files/solr/collection1/conf/schema-replication2.xml
> * core/src/test-files/solr/collection1/conf/schema-required-fields.xml
> * core/src/test-files/solr/collection1/conf/schema-reversed.xml
> * core/src/test-files/solr/collection1/conf/schema-tokenizer-test.xml
> * core/src/test-files/solr/collection1/conf/schema-version-dv.xml
> * core/src/test-files/solr/collection1/conf/schema-version-indexed.xml



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

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

[jira] [Commented] (SOLR-10924) PointField multivalued docValues don't "dedup" like TrieField

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10924:


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

SOLR-10989: Fixup to correct SOLR-11020 test failures (root discrepency caused 
by SOLR-10924)


> PointField multivalued docValues don't "dedup" like TrieField
> -
>
> Key: SOLR-10924
> URL: https://issues.apache.org/jira/browse/SOLR-10924
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> As noted by Tomas in SOLR-10835, since the numeric FooPointField classes use 
> SortedNumericDocValues, the docvalues don't "dedup" when the same value 
> exists multiple times for a single document -- this is different from the 
> numeric TrieFooField classes that use SortedSetDocValues - which are by 
> definition a _set_ -- so multiple instances of the same value are 
> de-duplicated.
> This impacts things like the ExportWriter, as well as fields that 
> {{useDocValuesAsStored="true"}} if users have particular expecations when 
> converting from Trie fields to Point fields.



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

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

[jira] [Commented] (SOLR-10989) Randomize PointFields and general cleanup in schema files that have completley unused Trie fieldTYpes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10989:


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

SOLR-10989: Fixup to correct SOLR-11020 test failures (root discrepency caused 
by SOLR-10924)


> Randomize PointFields and general cleanup in schema files that have 
> completley unused Trie fieldTYpes
> -
>
> Key: SOLR-10989
> URL: https://issues.apache.org/jira/browse/SOLR-10989
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 7.0
>
>
> while working on parent issue i noticed a schema filed that declared some 
> TrieField fieldTypes that were completely unused by and field or dynamicField 
> declarations.  so i write a quick little perl script to find more of these, 
> manually cleaned up all the ones that seemed like no brainers, and then added 
> the points randomization to replace the remaining Trie fieldtypes (that are 
> used) in these schemas...
> * core/src/test-files/solr/collection1/conf/bad-schema-dup-fieldType.xml
> * core/src/test-files/solr/collection1/conf/schema-binaryfield.xml
> * core/src/test-files/solr/collection1/conf/schema-copyfield-test.xml
> * core/src/test-files/solr/collection1/conf/schema-customfield.xml
> * core/src/test-files/solr/collection1/conf/schema-non-stored-docvalues.xml
> * core/src/test-files/solr/collection1/conf/schema-not-required-unique-key.xml
> * core/src/test-files/solr/collection1/conf/schema-replication1.xml
> * core/src/test-files/solr/collection1/conf/schema-replication2.xml
> * core/src/test-files/solr/collection1/conf/schema-required-fields.xml
> * core/src/test-files/solr/collection1/conf/schema-reversed.xml
> * core/src/test-files/solr/collection1/conf/schema-tokenizer-test.xml
> * core/src/test-files/solr/collection1/conf/schema-version-dv.xml
> * core/src/test-files/solr/collection1/conf/schema-version-indexed.xml



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

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

[jira] [Commented] (SOLR-11020) TestUseDocValuesAsStored.testRandomSingleAndMultiValued() failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11020:


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

SOLR-10989: Fixup to correct SOLR-11020 test failures (root discrepency caused 
by SOLR-10924)


> TestUseDocValuesAsStored.testRandomSingleAndMultiValued() failures
> --
>
> Key: SOLR-11020
> URL: https://issues.apache.org/jira/browse/SOLR-11020
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Hoss Man
>
> Reproducing failure from Policeman Jenkins 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20061/]:
> {noformat}
> Checking out Revision cb23fa9b4efa5fc7c17f215f507901d459e9aa6f 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestUseDocValuesAsStored 
> -Dtests.method=testRandomSingleAndMultiValued -Dtests.seed=41EB0B5C781BBEEC 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en -Dtests.timezone=CNT 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   3.97s J0 | 
> TestUseDocValuesAsStored.testRandomSingleAndMultiValued <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
> query
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([41EB0B5C781BBEEC:48B7F69D00C4AFD4]:0)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
>[junit4]>  at 
> org.apache.solr.schema.TestUseDocValuesAsStored.doTest(TestUseDocValuesAsStored.java:335)
>[junit4]>  at 
> org.apache.solr.schema.TestUseDocValuesAsStored.testRandomSingleAndMultiValued(TestUseDocValuesAsStored.java:176)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
> xpath=*[count(//arr[@name='test_fs_dvo']/float) = 5]
>[junit4]>  xml response was: 
>[junit4]> 
>[junit4]> 0 name="QTime">0 start="0"> name="test_fs_dvo">-7.5113335E32-6.931654E22-1.70372E-144.3711085E16NaNNaN
>[junit4]> 
>[junit4]>  request was:q=id:59=test_fs_dvo=xml
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=440, maxMBSortInHeap=7.286261706944515, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=en, timezone=CNT
>[junit4]   2> NOTE: Linux 4.10.0-21-generic amd64/Oracle Corporation 
> 1.8.0_131 (64-bit)/cpus=8,threads=1,free=221971640,total=518979584
> {noformat}
> Another reproducing master failure from my Jenkins (commit 
> {{d81daf54b4b567327c6ebde94b2b2eedacf19cd6}}):
> {noformat}
>   [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestUseDocValuesAsStored 
> -Dtests.method=testRandomSingleAndMultiValued -Dtests.seed=CC2360F81A4AA5F6 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Asia/Anadyr -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   2.57s | 
> TestUseDocValuesAsStored.testRandomSingleAndMultiValued <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
> query
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([CC2360F81A4AA5F6:C57F9D396295B4CE]:0)
>[junit4]>at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
>[junit4]>at 
> org.apache.solr.schema.TestUseDocValuesAsStored.doTest(TestUseDocValuesAsStored.java:335)
>[junit4]>at 
> org.apache.solr.schema.TestUseDocValuesAsStored.testRandomSingleAndMultiValued(TestUseDocValuesAsStored.java:176)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
> xpath=*[count(//arr[@name='test_fs_dvo']/float) = 3]
>[junit4]>xml response was:  encoding="UTF-8"?>
>[junit4]> 
>[junit4]> 0 name="QTime">0 start="0"> name="test_fs_dvo">-4.92691195E175.081205E19NaNNaN
>[junit4]> 
>[junit4]>request was:q=id:41=test_fs_dvo=xml
>[junit4]>at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
>[junit4]>... 41 more
>[junit4]   2> NOTE: leaving temporary files on disk at: 
> /home/sarowe/git/lucene-solr/solr/build/solr-core/test/J0/temp/solr.schema.TestUseDocValuesAsStored_CC2360F81A4AA5F6-001
>[junit4] 

[jira] [Commented] (LUCENE-7888) Test{Mixed,Binary}DocValuesUpdates.testManyReopensAndFields() failures

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7888:


Also, I think the 4 non-reproducing seeds above 
(https://issues.apache.org/jira/browse/LUCENE-7888?focusedCommentId=16077449=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16077449)
 were before my last commit (7c704d5258b3be8c383ccb96bf4a30be441f091c) fixing a 
race ... so I'm hoping there are no more failures in this challenging test :)

> Test{Mixed,Binary}DocValuesUpdates.testManyReopensAndFields() failures
> --
>
> Key: LUCENE-7888
> URL: https://issues.apache.org/jira/browse/LUCENE-7888
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Fix For: 7.0
>
>
> Non-reproducing failure from 
> [https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/794/]:
> {noformat}
> Checking out Revision e8057309b90db0c79fc273e2284948b84c16ce4c 
> (refs/remotes/origin/master)
> [...]
>[smoker][junit4] Suite: 
> org.apache.lucene.index.TestMixedDocValuesUpdates
>[smoker][junit4] IGNOR/A 0.00s J0 | 
> TestMixedDocValuesUpdates.testTonsOfUpdates
>[smoker][junit4]> Assumption #1: 'nightly' test group is disabled 
> (@Nightly())
>[smoker][junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestMixedDocValuesUpdates -Dtests.method=testManyReopensAndFields 
> -Dtests.seed=69A3133AC96F545A -Dtests.multiplier=2 -Dtests.locale=es-SV 
> -Dtests.timezone=Europe/Zagreb -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[smoker][junit4] FAILURE 0.04s J0 | 
> TestMixedDocValuesUpdates.testManyReopensAndFields <<<
>[smoker][junit4]> Throwable #1: java.lang.AssertionError: invalid 
> numeric value for doc=0, field=f0, reader=_3(7.0.0):c35/1 expected:<3> but 
> was:<2>
>[smoker][junit4]>  at 
> __randomizedtesting.SeedInfo.seed([69A3133AC96F545A:5F5F7115489A3746]:0)
>[smoker][junit4]>  at 
> org.apache.lucene.index.TestMixedDocValuesUpdates.testManyReopensAndFields(TestMixedDocValuesUpdates.java:138)
>[smoker][junit4]>  at java.lang.Thread.run(Thread.java:748)
>[smoker][junit4]   2> NOTE: test params are: codec=Lucene70, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=es-SV, timezone=Europe/Zagreb
>[smoker][junit4]   2> NOTE: Linux 3.13.0-88-generic amd64/Oracle 
> Corporation 1.8.0_131 (64-bit)/cpus=4,threads=1,free=177411120,total=287309824
>[smoker][junit4]   2> NOTE: All tests run in this JVM: 
> [TestRegexpRandom, TestStandardAnalyzer, TestMmapDirectory, TestCodecs, 
> TestDocValuesQueries, TestNeverDelete, TestIndexWriterConfig, 
> TestNoDeletionPolicy, TestBooleanMinShouldMatch, TestIndexSorting, 
> TestDocValuesIndexing, TestTragicIndexWriterDeadlock, TestIntBlockPool, 
> TestBinaryTerms, TestIndexWriter, Test4GBStoredFields, TestSortedSetSelector, 
> TestAllFilesCheckIndexHeader, TestFilterCodecReader, TestCachingCollector, 
> TestNotDocIdSet, TestQueryBuilder, TestMaxTermFrequency, 
> TestForceMergeForever, TestFieldMaskingSpanQuery, TestRegExp, 
> TestPointValues, TestIndexWriterOutOfFileDescriptors, Test2BTerms, 
> TestTermsEnum, TestSloppyPhraseQuery, TestBoostQuery, TestRateLimiter, 
> TestIndexWriterExceptions, TestMultiPhraseQuery, TestSimpleSearchEquivalence, 
> TestBinaryDocValuesUpdates, TestPerSegmentDeletes, Test2BPoints, 
> TestSimpleExplanations, TestPerFieldPostingsFormat, 
> TestLucene50TermVectorsFormat, TestSingleInstanceLockFactory, 
> TestLucene50CompoundFormat, TestMaxPosition, TestTotalHitCountCollector, 
> TestConstantScoreQuery, TestWordlistLoader, TestThreadedForceMerge, 
> TestBytesRefArray, TestPointQueries, TestCharFilter, TestSimilarityProvider, 
> TestBytesStore, TestIntroSorter, TestWildcardRandom, TestSimilarity, 
> TestFieldValueQuery, TestOmitNorms, TestUnicodeUtil, TestLRUQueryCache, 
> TestTermQuery, TestInPlaceMergeSorter, TestNot, TestTopFieldCollector, 
> TestIndexWriterFromReader, TestCharArrayMap, TestUTF32ToUTF8, 
> TestDocIdsWriter, TestDocsAndPositions, TestNewestSegment, TestTerm, 
> TestCodecHoldsOpenFiles, TestPagedBytes, TestPackedInts, TestBasics, 
> TestNRTThreads, TestStressAdvance, TestSearchAfter, TestHighCompressionMode, 
> TestDocumentsWriterStallControl, TestStressIndexing, 
> TestSnapshotDeletionPolicy, TestNRTReaderWithThreads, TestTieredMergePolicy, 
> TestLevenshteinAutomata, TestWeakIdentityMap, TestRegexpRandom2, 
> TestSegmentTermDocs, TestPerFieldPostingsFormat2, TestMultiDocValues, 
> TestHugeRamFile, TestLazyProxSkipping, TestDeterminism, TestBytesRefHash, 
> TestNearSpansOrdered, TestTermRangeQuery, TestDocumentWriter, 
> TestCrashCausesCorruptIndex, 

[jira] [Commented] (LUCENE-7888) Test{Mixed,Binary}DocValuesUpdates.testManyReopensAndFields() failures

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7888:


No worries [~steve_rowe]!

> Test{Mixed,Binary}DocValuesUpdates.testManyReopensAndFields() failures
> --
>
> Key: LUCENE-7888
> URL: https://issues.apache.org/jira/browse/LUCENE-7888
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Fix For: 7.0
>
>
> Non-reproducing failure from 
> [https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/794/]:
> {noformat}
> Checking out Revision e8057309b90db0c79fc273e2284948b84c16ce4c 
> (refs/remotes/origin/master)
> [...]
>[smoker][junit4] Suite: 
> org.apache.lucene.index.TestMixedDocValuesUpdates
>[smoker][junit4] IGNOR/A 0.00s J0 | 
> TestMixedDocValuesUpdates.testTonsOfUpdates
>[smoker][junit4]> Assumption #1: 'nightly' test group is disabled 
> (@Nightly())
>[smoker][junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestMixedDocValuesUpdates -Dtests.method=testManyReopensAndFields 
> -Dtests.seed=69A3133AC96F545A -Dtests.multiplier=2 -Dtests.locale=es-SV 
> -Dtests.timezone=Europe/Zagreb -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[smoker][junit4] FAILURE 0.04s J0 | 
> TestMixedDocValuesUpdates.testManyReopensAndFields <<<
>[smoker][junit4]> Throwable #1: java.lang.AssertionError: invalid 
> numeric value for doc=0, field=f0, reader=_3(7.0.0):c35/1 expected:<3> but 
> was:<2>
>[smoker][junit4]>  at 
> __randomizedtesting.SeedInfo.seed([69A3133AC96F545A:5F5F7115489A3746]:0)
>[smoker][junit4]>  at 
> org.apache.lucene.index.TestMixedDocValuesUpdates.testManyReopensAndFields(TestMixedDocValuesUpdates.java:138)
>[smoker][junit4]>  at java.lang.Thread.run(Thread.java:748)
>[smoker][junit4]   2> NOTE: test params are: codec=Lucene70, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=es-SV, timezone=Europe/Zagreb
>[smoker][junit4]   2> NOTE: Linux 3.13.0-88-generic amd64/Oracle 
> Corporation 1.8.0_131 (64-bit)/cpus=4,threads=1,free=177411120,total=287309824
>[smoker][junit4]   2> NOTE: All tests run in this JVM: 
> [TestRegexpRandom, TestStandardAnalyzer, TestMmapDirectory, TestCodecs, 
> TestDocValuesQueries, TestNeverDelete, TestIndexWriterConfig, 
> TestNoDeletionPolicy, TestBooleanMinShouldMatch, TestIndexSorting, 
> TestDocValuesIndexing, TestTragicIndexWriterDeadlock, TestIntBlockPool, 
> TestBinaryTerms, TestIndexWriter, Test4GBStoredFields, TestSortedSetSelector, 
> TestAllFilesCheckIndexHeader, TestFilterCodecReader, TestCachingCollector, 
> TestNotDocIdSet, TestQueryBuilder, TestMaxTermFrequency, 
> TestForceMergeForever, TestFieldMaskingSpanQuery, TestRegExp, 
> TestPointValues, TestIndexWriterOutOfFileDescriptors, Test2BTerms, 
> TestTermsEnum, TestSloppyPhraseQuery, TestBoostQuery, TestRateLimiter, 
> TestIndexWriterExceptions, TestMultiPhraseQuery, TestSimpleSearchEquivalence, 
> TestBinaryDocValuesUpdates, TestPerSegmentDeletes, Test2BPoints, 
> TestSimpleExplanations, TestPerFieldPostingsFormat, 
> TestLucene50TermVectorsFormat, TestSingleInstanceLockFactory, 
> TestLucene50CompoundFormat, TestMaxPosition, TestTotalHitCountCollector, 
> TestConstantScoreQuery, TestWordlistLoader, TestThreadedForceMerge, 
> TestBytesRefArray, TestPointQueries, TestCharFilter, TestSimilarityProvider, 
> TestBytesStore, TestIntroSorter, TestWildcardRandom, TestSimilarity, 
> TestFieldValueQuery, TestOmitNorms, TestUnicodeUtil, TestLRUQueryCache, 
> TestTermQuery, TestInPlaceMergeSorter, TestNot, TestTopFieldCollector, 
> TestIndexWriterFromReader, TestCharArrayMap, TestUTF32ToUTF8, 
> TestDocIdsWriter, TestDocsAndPositions, TestNewestSegment, TestTerm, 
> TestCodecHoldsOpenFiles, TestPagedBytes, TestPackedInts, TestBasics, 
> TestNRTThreads, TestStressAdvance, TestSearchAfter, TestHighCompressionMode, 
> TestDocumentsWriterStallControl, TestStressIndexing, 
> TestSnapshotDeletionPolicy, TestNRTReaderWithThreads, TestTieredMergePolicy, 
> TestLevenshteinAutomata, TestWeakIdentityMap, TestRegexpRandom2, 
> TestSegmentTermDocs, TestPerFieldPostingsFormat2, TestMultiDocValues, 
> TestHugeRamFile, TestLazyProxSkipping, TestDeterminism, TestBytesRefHash, 
> TestNearSpansOrdered, TestTermRangeQuery, TestDocumentWriter, 
> TestCrashCausesCorruptIndex, TestLiveFieldValues, TestFuzzyQuery, 
> TestAutomatonQuery, TestMultiLevelSkipList, TestCheckIndex, TestConjunctions, 
> TestVirtualMethod, TestSearch, TestDateTools, TestDocCount, 
> TestAttributeSource, TestIsCurrent, TestIndexWriterLockRelease, 
> TestByteBlockPool, TestDemo, TestRollback, MultiCollectorTest, 
> TestSimpleAttributeImpl, 

[jira] [Commented] (LUCENE-7888) Test{Mixed,Binary}DocValuesUpdates.testManyReopensAndFields() failures

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7888:


{quote}
bq. Mike, any reason not to backport to branch_7x and branch_7_0?
OK original commit here 
(https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eaf1d45) was in 
fact before 7.0/7.x branched off, so I'm not losing my mind as much as I 
previously thought.
{quote}

Crap, sorry for wasting your time.  I think I looked at {{git log}} for one of 
those branches and didn't see your commit, and then assumed, given the close 
timing of the branches' being cut, that the commit didn't make it.  But looking 
now I see it on both branches' logs.

> Test{Mixed,Binary}DocValuesUpdates.testManyReopensAndFields() failures
> --
>
> Key: LUCENE-7888
> URL: https://issues.apache.org/jira/browse/LUCENE-7888
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Fix For: 7.0
>
>
> Non-reproducing failure from 
> [https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/794/]:
> {noformat}
> Checking out Revision e8057309b90db0c79fc273e2284948b84c16ce4c 
> (refs/remotes/origin/master)
> [...]
>[smoker][junit4] Suite: 
> org.apache.lucene.index.TestMixedDocValuesUpdates
>[smoker][junit4] IGNOR/A 0.00s J0 | 
> TestMixedDocValuesUpdates.testTonsOfUpdates
>[smoker][junit4]> Assumption #1: 'nightly' test group is disabled 
> (@Nightly())
>[smoker][junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestMixedDocValuesUpdates -Dtests.method=testManyReopensAndFields 
> -Dtests.seed=69A3133AC96F545A -Dtests.multiplier=2 -Dtests.locale=es-SV 
> -Dtests.timezone=Europe/Zagreb -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[smoker][junit4] FAILURE 0.04s J0 | 
> TestMixedDocValuesUpdates.testManyReopensAndFields <<<
>[smoker][junit4]> Throwable #1: java.lang.AssertionError: invalid 
> numeric value for doc=0, field=f0, reader=_3(7.0.0):c35/1 expected:<3> but 
> was:<2>
>[smoker][junit4]>  at 
> __randomizedtesting.SeedInfo.seed([69A3133AC96F545A:5F5F7115489A3746]:0)
>[smoker][junit4]>  at 
> org.apache.lucene.index.TestMixedDocValuesUpdates.testManyReopensAndFields(TestMixedDocValuesUpdates.java:138)
>[smoker][junit4]>  at java.lang.Thread.run(Thread.java:748)
>[smoker][junit4]   2> NOTE: test params are: codec=Lucene70, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=es-SV, timezone=Europe/Zagreb
>[smoker][junit4]   2> NOTE: Linux 3.13.0-88-generic amd64/Oracle 
> Corporation 1.8.0_131 (64-bit)/cpus=4,threads=1,free=177411120,total=287309824
>[smoker][junit4]   2> NOTE: All tests run in this JVM: 
> [TestRegexpRandom, TestStandardAnalyzer, TestMmapDirectory, TestCodecs, 
> TestDocValuesQueries, TestNeverDelete, TestIndexWriterConfig, 
> TestNoDeletionPolicy, TestBooleanMinShouldMatch, TestIndexSorting, 
> TestDocValuesIndexing, TestTragicIndexWriterDeadlock, TestIntBlockPool, 
> TestBinaryTerms, TestIndexWriter, Test4GBStoredFields, TestSortedSetSelector, 
> TestAllFilesCheckIndexHeader, TestFilterCodecReader, TestCachingCollector, 
> TestNotDocIdSet, TestQueryBuilder, TestMaxTermFrequency, 
> TestForceMergeForever, TestFieldMaskingSpanQuery, TestRegExp, 
> TestPointValues, TestIndexWriterOutOfFileDescriptors, Test2BTerms, 
> TestTermsEnum, TestSloppyPhraseQuery, TestBoostQuery, TestRateLimiter, 
> TestIndexWriterExceptions, TestMultiPhraseQuery, TestSimpleSearchEquivalence, 
> TestBinaryDocValuesUpdates, TestPerSegmentDeletes, Test2BPoints, 
> TestSimpleExplanations, TestPerFieldPostingsFormat, 
> TestLucene50TermVectorsFormat, TestSingleInstanceLockFactory, 
> TestLucene50CompoundFormat, TestMaxPosition, TestTotalHitCountCollector, 
> TestConstantScoreQuery, TestWordlistLoader, TestThreadedForceMerge, 
> TestBytesRefArray, TestPointQueries, TestCharFilter, TestSimilarityProvider, 
> TestBytesStore, TestIntroSorter, TestWildcardRandom, TestSimilarity, 
> TestFieldValueQuery, TestOmitNorms, TestUnicodeUtil, TestLRUQueryCache, 
> TestTermQuery, TestInPlaceMergeSorter, TestNot, TestTopFieldCollector, 
> TestIndexWriterFromReader, TestCharArrayMap, TestUTF32ToUTF8, 
> TestDocIdsWriter, TestDocsAndPositions, TestNewestSegment, TestTerm, 
> TestCodecHoldsOpenFiles, TestPagedBytes, TestPackedInts, TestBasics, 
> TestNRTThreads, TestStressAdvance, TestSearchAfter, TestHighCompressionMode, 
> TestDocumentsWriterStallControl, TestStressIndexing, 
> TestSnapshotDeletionPolicy, TestNRTReaderWithThreads, TestTieredMergePolicy, 
> TestLevenshteinAutomata, TestWeakIdentityMap, TestRegexpRandom2, 
> TestSegmentTermDocs, TestPerFieldPostingsFormat2, TestMultiDocValues, 
> 

[JENKINS-EA] Lucene-Solr-7.x-Linux (32bit/jdk-9-ea+175) - Build # 27 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/27/
Java: 32bit/jdk-9-ea+175 -client -XX:+UseSerialGC --illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.cloud.TestPullReplica.testKillLeader

Error Message:
Replica state not updated in cluster state null Live Nodes: 
[127.0.0.1:40993_solr, 127.0.0.1:34199_solr] Last available state: 
DocCollection(pull_replica_test_kill_leader//collections/pull_replica_test_kill_leader/state.json/6)={
   "pullReplicas":"1",   "replicationFactor":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   
"core":"pull_replica_test_kill_leader_shard1_replica_n1",   
"base_url":"http://127.0.0.1:40993/solr;,   
"node_name":"127.0.0.1:40993_solr",   "state":"down",   
"type":"NRT",   "leader":"true"}, "core_node2":{   
"core":"pull_replica_test_kill_leader_shard1_replica_p1",   
"base_url":"http://127.0.0.1:34199/solr;,   
"node_name":"127.0.0.1:34199_solr",   "state":"active",   
"type":"PULL",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"100",   "autoAddReplicas":"false",   "nrtReplicas":"1",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Replica state not updated in cluster state
null
Live Nodes: [127.0.0.1:40993_solr, 127.0.0.1:34199_solr]
Last available state: 
DocCollection(pull_replica_test_kill_leader//collections/pull_replica_test_kill_leader/state.json/6)={
  "pullReplicas":"1",
  "replicationFactor":"1",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"pull_replica_test_kill_leader_shard1_replica_n1",
  "base_url":"http://127.0.0.1:40993/solr;,
  "node_name":"127.0.0.1:40993_solr",
  "state":"down",
  "type":"NRT",
  "leader":"true"},
"core_node2":{
  "core":"pull_replica_test_kill_leader_shard1_replica_p1",
  "base_url":"http://127.0.0.1:34199/solr;,
  "node_name":"127.0.0.1:34199_solr",
  "state":"active",
  "type":"PULL",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"100",
  "autoAddReplicas":"false",
  "nrtReplicas":"1",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([7E9E97E28BB86C14:37886356E903F842]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.TestPullReplica.doTestNoLeader(TestPullReplica.java:401)
at 
org.apache.solr.cloud.TestPullReplica.testKillLeader(TestPullReplica.java:290)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 

Re: JCC Segfault on Debian 9 (stretch)

[Dirk Rothe]

I was bitten by this during jcc.initVM():
https://www.cloudlinux.com/cloudlinux-os-blog/entry/jvm-crashes-occurring-after-upgrading-to-a-kernel-with-the-fix-for-stack-clash

Maybe related...

--dirk

Am 06.07.2017, 23:50 Uhr, schrieb Joshua Campbell :


Okay so. I built GDB 8 from source (it's new) and that doesn't have bug.

In summary:

Ok TO BE CLEAR, I am closer to the TRUTH than ever. Not only am I not
stopping, I am working harder. Updates when available. Stay tuned!

It turns out the JVM is crashing on the line commented with "//
Generate SEGV" so something about Python/JNI/JCC is intefering with
the JVM's signal handler, as this SEGV is intentional!



On Thu, Jul 6, 2017 at 12:44 AM, Joshua Campbell   
wrote:

How would they break oracle's though. It's a binary.

On Wed, Jul 5, 2017 at 10:40 PM, Andi Vajda  wrote:



> On Jul 6, 2017, at 00:03, Joshua Campbell   
wrote:

>
> I confirmed that it crashes on multiple Debian 9 machines but it
> doesn't crash on Ubuntu 16.04. This behavior is consistent regardless
> of the JDK used (I tried openjdk 8, oracle 8 and openjdk 9). I am at  
a

> loss for how to track it down further due to the (apparent) GDB bug.

Hmmm, maybe JNI is broken on Debian 9 ?

Andi..

>
>> On Wed, Jul 5, 2017 at 2:39 PM, Joshua Campbell  


>> wrote:
>> No, it segfaults.
>>
>>> On Wed, Jul 5, 2017 at 2:26 PM, Andi Vajda   
wrote:

>>>
 On Jul 5, 2017, at 22:16, Joshua Campbell 
 wrote:

 It's occuring after JCC calls JNI_CreateJavaVM

 cpp.py(529): env = initVM(os.pathsep.join(classpath) or None,
 **initvm_args)
 ^ last python trace before death

 Breakpoint 5, initVM (self=0x77e05048, args=0x766deac8,
   kwds=0x77e00ec8) at jcc3/sources/jcc.cpp:527
 527 if (JNI_CreateJavaVM(, (void **) _env,
 _args) < 0)
  last line of jcc.cpp before death

 (gdb) step

 Program received signal SIGSEGV, Segmentation fault.
 0x7fffe43942b4 in ?? ()
 (gdb)


 AFTER fixing debians debugging symbols with ln -s
 /usr/lib/debug/usr/lib/jvm/java-8-openjdk-amd64
 /usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64

 Breakpoint 1, JNI_CreateJavaVM (vm=0x7fffc420,
 penv=0x7fffc418,
   args=0x7fffc450) at
 ./src/hotspot/src/share/vm/prims/jni.cpp:5161
 5161./src/hotspot/src/share/vm/prims/jni.cpp: No such file or
 directory.
 (gdb) s
 JNI_CreateJavaVM (vm=0x7fffc420, penv=0x7fffc418,
 args=0x7fffc450)
   at ./src/hotspot/src/share/vm/prims/jni.cpp:5163
 5163in ./src/hotspot/src/share/vm/prims/jni.cpp
 (gdb)
 /build/gdb-A87voC/gdb-7.12/gdb/inline-frame.c:167: internal-error:
 void inline_frame_this_id(frame_info*, void**, frame_id*):  
Assertion

 `frame_id_p (*this_id)' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) n

 This is a bug, please report it.  For instructions, see:
 .

 What in the name of heck
>>>
>>> Does it run without gdb ?
>>>
>>> Andi..
>>>

 On Wed, Jul 5, 2017 at 11:48 AM, Joshua Campbell
  wrote:
>> But you should get a better stacktrace ?
>
> I got the exact same stacktrace.
>
> $ ldd
>
>  
venv3/lib/python3.5/site-packages/JCC-3.0-py3.5-linux-x86_64.egg/libjcc3.so

>   linux-vdso.so.1 (0x7ffcf4eb8000)
>   libjava.so =>
> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libjava.so
> (0x7f412227f000)
>   libjvm.so =>
>  
/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so

> (0x7f412133d000)
>   libpython3.5m.so.1.0 =>
> /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0  
(0x7f4120c3a000)

>   libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x7f41208b8000)
>   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
> (0x7f41205b4000)
>   libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x7f412039b000)
>   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f412017e000)
>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> (0x7f411fddf000)
>   libverify.so =>
> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libverify.so
> (0x7f411fbce000)
>   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> (0x7f411f9ca000)
>   libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
> (0x7f411f7a)
>   libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
> (0x7f411f584000)
>   libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
> (0x7f411f381000)
>   

[jira] [Updated] (SOLR-10996) Implement TriggerListener API

[Andrzej Bialecki (JIRA)]

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

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

Updated patch:
* existing listener instances are reused if their config is the same
* unit test for {{HttpTriggerListener}}

I think this is ready.

> Implement TriggerListener API
> -
>
> Key: SOLR-10996
> URL: https://issues.apache.org/jira/browse/SOLR-10996
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Attachments: SOLR-10996.patch, SOLR-10996.patch, SOLR-10996.patch
>
>
> SOLR-10340 added API for configuring trigger listeners. This issue is about 
> adding hooks in the framework for calling the listeners and providing a 
> couple implementations (HTTP callback, logging).



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

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

[jira] [Updated] (SOLR-10624) Security Vulnerability in secure inter-node communication in Apache Solr

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10624:
-
Security: Public  (was: Private (Security Issue))

Making the issue public since the fix has been released in 6.6 and the public 
announcement completed.

> Security Vulnerability in secure inter-node communication in Apache Solr
> 
>
> Key: SOLR-10624
> URL: https://issues.apache.org/jira/browse/SOLR-10624
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security, SolrCloud
>Affects Versions: 5.3, 5.5.4, 6.5, 6.5.1
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Critical
> Fix For: 5.5.5, 6.6, 7.0
>
>
> Solr uses a PKI based mechanism to secure inter-node communication
> when security is enabled.  It is possible to fake it by cleverly
> constructing  a node name that does not exist and pointing to the
> attackers machine. This means, the system is only as secure as an
> unprotected Solr while the user believes it is secure.
> who is affected?
> This feature was introduced in SOLR-7849 (Solr 5.3). So, every release
> after 5.3 is vulnerable if they use this feature. Systems using
> BasicAuth are affected and any custom authentication implementations
> using this feature may also be vulnerable. However, Kerberos users are
> unaffected.
> What is the fix?
> The fix includes checking if the node name is actually a member of the
> live_nodes set.



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

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

[jira] [Resolved] (SOLR-10624) Security Vulnerability in secure inter-node communication in Apache Solr

[Shalin Shekhar Mangar (JIRA)]

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

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

> Security Vulnerability in secure inter-node communication in Apache Solr
> 
>
> Key: SOLR-10624
> URL: https://issues.apache.org/jira/browse/SOLR-10624
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security, SolrCloud
>Affects Versions: 5.3, 5.5.4, 6.5, 6.5.1
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Critical
> Fix For: 5.5.5, 7.0, 6.6
>
>
> Solr uses a PKI based mechanism to secure inter-node communication
> when security is enabled.  It is possible to fake it by cleverly
> constructing  a node name that does not exist and pointing to the
> attackers machine. This means, the system is only as secure as an
> unprotected Solr while the user believes it is secure.
> who is affected?
> This feature was introduced in SOLR-7849 (Solr 5.3). So, every release
> after 5.3 is vulnerable if they use this feature. Systems using
> BasicAuth are affected and any custom authentication implementations
> using this feature may also be vulnerable. However, Kerberos users are
> unaffected.
> What is the fix?
> The fix includes checking if the node name is actually a member of the
> live_nodes set.



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

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

[ANNOUNCE] [SECURITY] CVE-2017-7660: Security Vulnerability in secure inter-node communication in Apache Solr

[Shalin Shekhar Mangar]

CVE-2017-7660: Security Vulnerability in secure inter-node
communication in Apache Solr

Severity: Important

Vendor:
The Apache Software Foundation

Versions Affected:
Solr 5.3 to 5.5.4
Solr 6.0 to 6.5.1

Description:

Solr uses a PKI based mechanism to secure inter-node communication
when security is enabled. It is possible to create a specially crafted
node name that does not exist as part of the cluster and point it to a
malicious node. This can trick the nodes in cluster to believe that
the malicious node is a member of the cluster. So, if Solr users have
enabled BasicAuth authentication mechanism using the BasicAuthPlugin
or if the user has implemented a custom Authentication plugin, which
does not implement either "HttpClientInterceptorPlugin" or
"HttpClientBuilderPlugin", his/her servers are vulnerable to this
attack. Users who only use SSL without basic authentication or those
who use Kerberos are not affected.

Mitigation:
6.x users should upgrade to 6.6
5.x users should obtain the latest source from git and apply this patch:
http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/2f5ecbcf

Credit:
This issue was discovered by Noble Paul of Lucidworks Inc.

References:
https://issues.apache.org/jira/browse/SOLR-10624
https://wiki.apache.org/solr/SolrSecurity

-- 
The Lucene PMC

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

[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks

[Vivek Narang (JIRA)]

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

Vivek Narang commented on SOLR-10317:
-

Hi, [~michael.sun] Thanks. I will look into it soon. Regards.

> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> SOLR-10317.patch, SOLR-10317.patch, solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



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

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

[jira] [Commented] (SOLR-6671) Introduce a solr.data.home as root dir for all data

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-6671:
-

The totalSpace and usableSpace reported by Metrics API are still based on 
coreRootDirectory (which is used as the instance dir for individual cores). So 
we should expose the data home's disk metrics as well. We can introduce new 
metrics such as dataHomeTotalSpace and dataHomeUsableSpace? Also, it'd be great 
if there was a method one could call to get the data home without needing a 
CoreDescriptor first.

> Introduce a solr.data.home as root dir for all data
> ---
>
> Key: SOLR-6671
> URL: https://issues.apache.org/jira/browse/SOLR-6671
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Affects Versions: 4.10.1
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 7.0
>
> Attachments: SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch, 
> SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch, 
> SOLR-6671.patch
>
>
> Many users prefer to deploy code, config and data on separate disk locations, 
> so the default of placing the indexes under 
> {{$\{solr.solr.home\}/$\{solr.core.name\}/data}} is not always wanted.
> In a multi-core/collection system, there is not much help in the 
> {{solr.data.dir}} option, as it would set the {{dataDir}} to the same folder 
> for all collections. One workaround, if you don't want to hardcode paths in 
> your {{solrconfig.xml}}, is to specify the {{dataDir}} property in each 
> {{solr.properties}} file.
> A more elegant solution would be to introduce a new Java-option 
> {{solr.data.home}} which would be to data the same as {{solr.solr.home}} is 
> for config. If set, all collections would default their {{dataDir}} as 
> {{$\{solr.data.home\)/$\{solr.core.name\}/data}}



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

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

[jira] [Commented] (SOLR-10996) Implement TriggerListener API

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-10996:
--

bq. I don't think this would work well, because the init method in some cases 
may have a substantial overhead (eg. creating a client, establishing 
connections, etc)

Okay, I see your point.

> Implement TriggerListener API
> -
>
> Key: SOLR-10996
> URL: https://issues.apache.org/jira/browse/SOLR-10996
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Attachments: SOLR-10996.patch, SOLR-10996.patch
>
>
> SOLR-10340 added API for configuring trigger listeners. This issue is about 
> adding hooks in the framework for calling the listeners and providing a 
> couple implementations (HTTP callback, logging).



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
Could not find collection : addReplicaColl

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : addReplicaColl
at 
__randomizedtesting.SeedInfo.seed([72D5A91AC721AA4D:E175FE3C4929E19C]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:247)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.addReplicaTest(CollectionsAPIDistributedZkTest.java:606)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCreationAndDeletion

Error Message:


Stack Trace:
java.lang.AssertionError
  

[jira] [Commented] (SOLR-11032) Update solrj tutorial

[Karl Richter (JIRA)]

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

Karl Richter commented on SOLR-11032:
-

> And we should probably move it to the ref-guide too. Or would the SolrJ 
> tutorial work better as a GitHub repo with multiple examples that you could 
> run, study, modify, copy/paste?

Can't it be both? Maintaining documentation resources outside the code is 
painful (and maybe therefore didn't happen for 5 years in this afaik), so it 
should be easy to contribute and there's no easier way than PRs. However, if 
it's a plain project that one has to build with tools with different 
installation routines on different OS (which is what a GitHub tutorial is in my 
understanding), then maintenance need and user frustration might increase. 
Consequently, an automatically built and updated version in form of HTML should 
be provided in the ref-guide and the maintenance occur on GitHub.

> Update solrj tutorial
> -
>
> Key: SOLR-11032
> URL: https://issues.apache.org/jira/browse/SOLR-11032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, SolrJ, website
>Reporter: Karl Richter
>
> The [solrj tutorial](https://wiki.apache.org/solr/Solrj) has the following 
> issues:
>   * It refers to 1.4.0 whereas the current release is 6.x, some classes are 
> deprecated or no longer exist.
>   * Document-object-binding is a crucial feature [which should be working in 
> the meantime](https://issues.apache.org/jira/browse/SOLR-1945) and thus 
> should be covered in the tutorial.



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

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

[jira] [Commented] (SOLR-11032) Update solrj tutorial

[JIRA]

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

Jan Høydahl commented on SOLR-11032:


And we should probably move it to the ref-guide too. Or would the SolrJ 
tutorial work better as a GitHub repo with multiple examples that you could 
run, study, modify, copy/paste?

> Update solrj tutorial
> -
>
> Key: SOLR-11032
> URL: https://issues.apache.org/jira/browse/SOLR-11032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, SolrJ, website
>Reporter: Karl Richter
>
> The [solrj tutorial](https://wiki.apache.org/solr/Solrj) has the following 
> issues:
>   * It refers to 1.4.0 whereas the current release is 6.x, some classes are 
> deprecated or no longer exist.
>   * Document-object-binding is a crucial feature [which should be working in 
> the meantime](https://issues.apache.org/jira/browse/SOLR-1945) and thus 
> should be covered in the tutorial.



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

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

Re: Release planning for 7.0

[Ishan Chattopadhyaya]

> Hi Anshum,
> I'd like to have SOLR-10282 in for 7.0. It is a low impact new feature
that helps admins to enable
> Kerberos more easily using the bin/solr script.
> I should be able to have it dev-complete by end of Friday. Let me know if
you have any objections.
> Thanks,
> Ishan

Hi Anshum,
I've committed it to branch_7x. In case there are any objections, I shall
be glad to roll it back from branch_7x.
Thanks,
Ishan

[jira] [Commented] (LUCENE-7823) Have a naive bayes classifier which uses plain BM25 scores instead of plain frequencies

[ASF subversion and git services (JIRA)]

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

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

Commit 25229f21ec7b7d79c9fd7408e88290de29065672 in lucene-solr's branch 
refs/heads/branch_7_0 from [~teofili]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=25229f2 ]

LUCENE-7823, LUCENE-7838 - added missing entires in changes.txt

(cherry picked from commit 8ccb61c)


> Have a naive bayes classifier which uses plain BM25 scores instead of plain 
> frequencies
> ---
>
> Key: LUCENE-7823
> URL: https://issues.apache.org/jira/browse/LUCENE-7823
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/classification
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: 7.0
>
>
> {{SimpleNaiveBayesClassifier}} users term frequencies with add one smoothing 
> to calculate likelihood and just tf for prior. Given Lucene has switched to 
> BM25 it would be better to have a different impl which uses BM25 
> scoring as a probability measure of both prior and likelihood.



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

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