[jira] [Commented] (SOLR-5872) Eliminate overseer queue

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5872:
---

bq. Hello, we are currently trying to do a deploy of around 200 collections

With which version?

> Eliminate overseer queue 
> -
>
> Key: SOLR-5872
> URL: https://issues.apache.org/jira/browse/SOLR-5872
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> The overseer queue is one of the busiest points in the entire system. The 
> raison d'être of the queue is
>  * Provide batching of operations for the main clusterstate,json so that 
> state updates are minimized 
> * Avoid race conditions and ensure order
> Now , as we move the individual collection states out of the main 
> clusterstate.json, the batching is not useful anymore.
> Race conditions can easily be solved by using a compare and set in Zookeeper. 
> The proposed solution  is , whenever an operation is required to be performed 
> on the clusterstate, the same thread (and of course the same JVM)
>  # read the fresh state and version of zk node  
>  # construct the new state 
>  # perform a compare and set
>  # if compare and set fails go to step 1
> This should be limited to all operations performed on external collections 
> because batching would be required for others 



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

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

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

[Policeman Jenkins Server]

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

6 tests failed.
FAILED:  
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter

Error Message:
Collection not found: withShardField

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

[jira] [Updated] (SOLR-8045) Deploy V2 API at /v2 instead of /solr/v2

[Noble Paul (JIRA)]

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

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

> Deploy V2 API at /v2 instead of /solr/v2
> 
>
> Key: SOLR-8045
> URL: https://issues.apache.org/jira/browse/SOLR-8045
> Project: Solr
>  Issue Type: Wish
>Reporter: Noble Paul
>Assignee: Cao Manh Dat
> Fix For: 6.0
>
> Attachments: SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch, 
> SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch
>
>
> This does not mean that the path to access Solr will be changed. All paths 
> will remain as is and would behave exactly the same



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

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1257 - Unstable

[Apache Jenkins Server]

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

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

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.HdfsTransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)  
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94)  at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:109)
  at sun.reflect.GeneratedConstructorAccessor144.newInstance(Unknown Source)  
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)  at 
org.apache.solr.core.SolrCore.createInstance(SolrCore.java:759)  at 
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:821)  at 
org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1072)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:937)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:829)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:949)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:582)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [HdfsTransactionLog]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.HdfsTransactionLog
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94)
at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:109)
at sun.reflect.GeneratedConstructorAccessor144.newInstance(Unknown 
Source)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:759)
at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:821)
at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1072)
at org.apache.solr.core.SolrCore.(SolrCore.java:937)
at org.apache.solr.core.SolrCore.(SolrCore.java:829)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:949)
at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:582)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


at __randomizedtesting.SeedInfo.seed([21000C06FCF76FA8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:302)
at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[jira] [Updated] (SOLR-8045) Deploy V2 API at /v2 instead of /solr/v2

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-8045:
-
Summary: Deploy V2 API at /v2 instead of /solr/v2  (was: Deploy Solr in 
ROOT (/) path )

> Deploy V2 API at /v2 instead of /solr/v2
> 
>
> Key: SOLR-8045
> URL: https://issues.apache.org/jira/browse/SOLR-8045
> Project: Solr
>  Issue Type: Wish
>Reporter: Noble Paul
>Assignee: Cao Manh Dat
> Fix For: 6.0
>
> Attachments: SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch, 
> SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch
>
>
> This does not mean that the path to access Solr will be changed. All paths 
> will remain as is and would behave exactly the same



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

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

[jira] [Commented] (SOLR-5872) Eliminate overseer queue

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-5872:
--

it's time to split the "state" from "state.json" into a separate file. 
replica-status.json

{code}
{
// 0:DOWN
// 1: ACTIVE
// 2: RECOVERING

"replica1": 1
"replica2": 1
}
{code}

So every core watches 2 files instead of one and 99% of changes happen to the 
replica-status.json

This can help us scale to a very large no:of of shards

> Eliminate overseer queue 
> -
>
> Key: SOLR-5872
> URL: https://issues.apache.org/jira/browse/SOLR-5872
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> The overseer queue is one of the busiest points in the entire system. The 
> raison d'être of the queue is
>  * Provide batching of operations for the main clusterstate,json so that 
> state updates are minimized 
> * Avoid race conditions and ensure order
> Now , as we move the individual collection states out of the main 
> clusterstate.json, the batching is not useful anymore.
> Race conditions can easily be solved by using a compare and set in Zookeeper. 
> The proposed solution  is , whenever an operation is required to be performed 
> on the clusterstate, the same thread (and of course the same JVM)
>  # read the fresh state and version of zk node  
>  # construct the new state 
>  # perform a compare and set
>  # if compare and set fails go to step 1
> This should be limited to all operations performed on external collections 
> because batching would be required for others 



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

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

[jira] [Updated] (SOLR-10244) TestCoreDiscovery fails if you run it as root.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-10244:
---
Summary: TestCoreDiscovery fails if you run it as root.  (was: TestConfig 
and TestCoreDiscovery fail if you run them as root.)

> TestCoreDiscovery fails if you run it as root.
> --
>
> Key: SOLR-10244
> URL: https://issues.apache.org/jira/browse/SOLR-10244
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>




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

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

[jira] [Commented] (SOLR-10032) Create report to assess Solr test quality at a commit point.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10032:


I've got a few issue to look into, but when I'm done I'll run a new report and 
work on removing any tests failing over 5% of the time.

> Create report to assess Solr test quality at a commit point.
> 
>
> Key: SOLR-10032
> URL: https://issues.apache.org/jira/browse/SOLR-10032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: Lucene-Solr Master Test Beast Results 
> 01-24-2017-9899cbd031dc3fc37a384b1f9e2b379e90a9a3a6 Level Medium- Running 30 
> iterations, 12 at a time .pdf, Lucene-Solr Master Test Beasults 
> 02-01-2017-bbc455de195c83d9f807980b510fa46018f33b1b Level Medium- Running 30 
> iterations, 10 at a time.pdf, Lucene-Solr Master Test Beasults 
> 02-08-2017-6696eafaae18948c2891ce758c7a2ec09873dab8 Level Medium+- Running 30 
> iterations, 10 at a time, 8 cores.pdf, Lucene-Solr Master Test Beasults 
> 02-14-2017- Level Medium+-a1f114f70f3800292c25be08213edf39b3e37f6a Running 30 
> iterations, 10 at a time, 8 cores.pdf, Lucene-Solr Master Test Beasults 
> 02%2F17%2F2017-19c8ec2bf1882bed1bb34d0b55198d03f2018838 Level Hard Running 
> 100 iterations, 12 at a time, 8 cores.pdf
>
>
> We have many Jenkins instances blasting tests, some official, some policeman, 
> I and others have or had their own, and the email trail proves the power of 
> the Jenkins cluster to find test fails.
> However, I still have a very hard time with some basic questions:
> what tests are flakey right now? which test fails actually affect devs most? 
> did I break it? was that test already flakey? is that test still flakey? what 
> are our worst tests right now? is that test getting better or worse?
> We really need a way to see exactly what tests are the problem, not because 
> of OS or environmental issues, but more basic test quality issues. Which 
> tests are flakey and how flakey are they at any point in time.
> Reports:
> https://drive.google.com/drive/folders/0ByYyjsrbz7-qa2dOaU1UZDdRVzg?usp=sharing
> 01/24/2017 - 
> https://docs.google.com/spreadsheets/d/1JySta2j2s7A_p16wA1UO-l6c4GsUHBIb4FONS2EzW9k/edit?usp=sharing
> 02/01/2017 - 
> https://docs.google.com/spreadsheets/d/1FndoyHmihaOVL2o_Zns5alpNdAJlNsEwQVoJ4XDWj3c/edit?usp=sharing
> 02/08/2017 - 
> https://docs.google.com/spreadsheets/d/1N6RxH4Edd7ldRIaVfin0si-uSLGyowQi8-7mcux27S0/edit?usp=sharing
> 02/14/2017 - 
> https://docs.google.com/spreadsheets/d/1eZ9_ds_0XyqsKKp8xkmESrcMZRP85jTxSKkNwgtcUn0/edit?usp=sharing
> 02/17/2017 - 
> https://docs.google.com/spreadsheets/d/1LEPvXbsoHtKfIcZCJZ3_P6OHp7S5g2HP2OJgU6B2sAg/edit?usp=sharing



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

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

[jira] [Created] (SOLR-10244) TestConfig and TestCoreDiscovery fail if you run them as root.

[Mark Miller (JIRA)]

Mark Miller created SOLR-10244:
--

 Summary: TestConfig and TestCoreDiscovery fail if you run them as 
root.
 Key: SOLR-10244
 URL: https://issues.apache.org/jira/browse/SOLR-10244
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mark Miller
Assignee: Mark Miller






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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/711/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenRenew

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

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<403>
at 
__randomizedtesting.SeedInfo.seed([4A2C8E19EED5E8D9:7DB77A07D619357D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.renewDelegationToken(TestDelegationWithHadoopAuth.java:118)
at 
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.verifyDelegationTokenRenew(TestDelegationWithHadoopAuth.java:302)
at 
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenRenew(TestDelegationWithHadoopAuth.java:319)
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 

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

[Policeman Jenkins Server]

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

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

Error Message:
Could not get expected value  'X val changed' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"", "path":"/test1", "httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":"X val"},  
from server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val changed' for 
path 'x' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":"X val"},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([7A648EFA2966723C:A229A3ADDEBBD79C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:249)
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 

Re: Google Summer Of Code (I am thinking of mentoring)

[Erick Erickson]

By all means, go ahead. IMO the important part is to get new folks
involved. The specific details can be worked out

Solr is expanding so fast that the more the merrier...

Erick

On Tue, Mar 7, 2017 at 4:27 PM, Alexandre Rafalovitch
 wrote:
> ASF is in the GSC this year again.  They are now looking for
> committer-access mentors. The announcement went through the Apache
> Community list.
>
> I would like to mentor a student with focus on onboarding activities,
> maybe generating some better examples, looking at downstream Apache
> projects using Solr and helping them to move to Solr 6, things like
> that.
>
> Is that a good/bad idea? I know it is a burden time-wise, but I'll
> give it a try. Stack Overflow may suffer a bit during that period, but
> çe la vie :-)
>
> Any feedback would be welcome, this would be my first time as GSOC mentor.
>
> Regards,
>Alex.
> 
> http://www.solr-start.com/ - Resources for Solr users, new and experienced
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Commented] (LUCENE-5143) rm or formalize dealing with "general" KEYS files in our dist dir

[JIRA]

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

Jan Høydahl commented on LUCENE-5143:
-

So what do people think about the README.html changes?

I think perhaps we should use the KEYS files from the sub folders (solr/KEYS, 
java/KEYS, pylucene/KEYS) and remove the topmost one? Or should solr/lucene 
instead share the one topmost /KEYS file?

Regarding the buildAndPushRelease changes, I think there should also be an 
offline mode that will either skip verification or verify against a local dist 
checkout.

So the next step would be to commit these patches and then commit a 
consolidated KEYS file (or two identical in java/ and solr/).

> rm or formalize dealing with "general" KEYS files in our dist dir
> -
>
> Key: LUCENE-5143
> URL: https://issues.apache.org/jira/browse/LUCENE-5143
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
> Attachments: LUCENE-5143.patch, LUCENE-5143_READMEs.patch
>
>
> At some point in the past, we started creating a snapshots of KEYS (taken 
> from the auto-generated data from id.apache.org) in the release dir of each 
> release...
> http://www.apache.org/dist/lucene/solr/4.4.0/KEYS
> http://www.apache.org/dist/lucene/java/4.4.0/KEYS
> http://archive.apache.org/dist/lucene/java/4.3.0/KEYS
> http://archive.apache.org/dist/lucene/solr/4.3.0/KEYS
> etc...
> But we also still have some "general" KEYS files...
> https://www.apache.org/dist/lucene/KEYS
> https://www.apache.org/dist/lucene/java/KEYS
> https://www.apache.org/dist/lucene/solr/KEYS
> ...which (as i discovered when i went to add my key to them today) are stale 
> and don't seem to be getting updated.
> I vaguely remember someone (rmuir?) explaining to me at one point the reason 
> we started creating a fresh copy of KEYS in each release dir, but i no longer 
> remember what they said, and i can't find any mention of a reason in any of 
> the release docs, or in any sort of comment in buildAndPushRelease.py
> we probably do one of the following:
>  * remove these "general" KEYS files
>  * add a disclaimer to the top of these files that they are legacy files for 
> verifying old releases and are no longer used for new releases
>  * ensure these files are up to date stop generating per-release KEYS file 
> copies
>  * update our release process to ensure that the general files get updated on 
> each release as well



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

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

[jira] [Commented] (SOLR-10237) Poly-Fields should error if subfield has docValues=true

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-10237:
--

bq. I think this is the path forward.
I'll upload a patch shortly
bq. I'm wondering if we may want to deprecate/remove the singular 
{{SchemaField.createField}} and simply have all field types do their logic in 
one method {{createFields}}
I think that would make sense, at least the reason for which both were created 
separately is not being used:

{code:java}
  /**
   * If true, then use {@link #createFields(Object, float)}, else use {@link 
#createField} to save an extra allocation
   * @return true if this field is a poly field
   */
  public boolean isPolyField(){
return type.isPolyField();
  }
{code}
There are a couple of calls to {{createField(...)}} that should be replaced 
though, I didn't look into them in detail.

bq.  Perhaps further, it might accept the Lucene {{Document}} as a destination 
to thus avoid some needless {{Field[]}} creation
Maybe... I'm not totally sold. I think there are valid use cases for wanting to 
modify the returned list before adding it to the {{Document}}

bq. I'm bumping into this a bit as I contemplate a TextField that can 
optionally put it's stored value embedded in a separate (compressed) 
BinaryDocValuesField – SOLR-10117.
Not sure I follow, how would this refactor help?

> Poly-Fields should error if subfield has docValues=true
> ---
>
> Key: SOLR-10237
> URL: https://issues.apache.org/jira/browse/SOLR-10237
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-10237.patch
>
>
> DocValues aren’t really supported in poly-fields at this point, but they 
> don’t complain if the schema definition of the subfield has docValues=true. 
> This leaves the index in an inconsistent state, since the SchemaField has 
> docValues=true but there are no DV for the field.
> Since this breaks compatibility, I think we should just emit a warning unless 
> the subfield is an instance of {{PointType}}. With 
> {{\[Int/Long/Float/Double/Date\]PointType}} subfields, this is particularly 
> important, since they use {{IndexOrDocValuesQuery}}, that would return 
> incorrect results.



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

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

Google Summer Of Code (I am thinking of mentoring)

[Alexandre Rafalovitch]

ASF is in the GSC this year again.  They are now looking for
committer-access mentors. The announcement went through the Apache
Community list.

I would like to mentor a student with focus on onboarding activities,
maybe generating some better examples, looking at downstream Apache
projects using Solr and helping them to move to Solr 6, things like
that.

Is that a good/bad idea? I know it is a burden time-wise, but I'll
give it a try. Stack Overflow may suffer a bit during that period, but
çe la vie :-)

Any feedback would be welcome, this would be my first time as GSOC mentor.

Regards,
   Alex.

http://www.solr-start.com/ - Resources for Solr users, new and experienced

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

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

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-10210 at 3/7/17 11:25 PM:
---

Thanks Hoss for this Uber-Issue :-)

I know the HADOOP-11123 stuff, I was already involved in the sun.misc.Cleaner 
part (also known as MMapDirectory unmapping on our side..., see HADOOP-12760).


was (Author: thetaphi):
Thanks Hoss for this Uber-Issue :-)

I know the HADOOP-11123 stuff, I was already involved in the sun.misc.Cleaner 
part (also known as MMapDirectory unmapping on our side...).

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



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

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

Re: SImilarity between Terms

[nh]

Hi
could you plz tell me how I can calculate the relevance of a doc to the
query with a combination of cosine similarity AND position of the words?



--
View this message in context: 
http://lucene.472066.n3.nabble.com/SImilarity-between-Terms-tp566603p4323903.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

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

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

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-10210:
--

Thanks Hoss for this Uber-Issue :-)

I know the HADOOP-11123 stuff, I was already involved in the sun.misc.Cleaner 
part (also known as MMapDirectory unmapping on our side...).

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



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

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

[jira] [Commented] (SOLR-10059) In SolrCloud, every fq added via is computed twice.

[Marc Morissette (JIRA)]

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

Marc Morissette commented on SOLR-10059:


[~hossman] It might be that existing parameters are not descriptive enough to 
handle every use case. We could add a new parameter to CommonParams: 
"handler.chain" or "distrib.call.stack" or something similar. It would be a 
comma delimited list of all the handlers that were involved in a distributed 
operation and that have forwarded their parameters to the current 
RequestHandler. A handler would be identified by Collection or Core Name 
followed by /RequestHandler. e.g. 
distrib.call.stack=MyCollection/MyHandler,MyCollection2/MyHandler2,... 
RequestHandlerBase could use this parameter to determine whether defaults, 
appends and initParams were already applied by the same handler up the chain.

It would not handle the case of appends in initParams that apply to different 
handlers in the same call chain but I would assume this rarely occurs in 
practice.

I'd rather not add more parameters to Solr given how messy the current 
parameter namespace already is but I don't see a better solution. What do you 
think? 

> In SolrCloud, every fq added via  is computed twice.
> 
>
> Key: SOLR-10059
> URL: https://issues.apache.org/jira/browse/SOLR-10059
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.4.0
>Reporter: Marc Morissette
>  Labels: performance
>
> While researching another issue, I noticed that parameters appended to a 
> query via SearchHandler's  are added to the query twice 
> in SolrCloud: once on the aggregator and again on the shard.
> The FacetComponent corrects this automatically by removing duplicates. Field 
> queries added in this fashion are however computed twice and that hinders 
> performance on filter queries that aren't simple bitsets such as those 
> produced by the CollapsingQueryParser.
> To reproduce the issue, simply test this handler on a large enough 
> collection, then replace "appends" with "defaults". You'll notice significant 
> performance improvements.
> {code}
> 
> 
> {!collapse field=routingKey hint=top_fc}
> 
> 
> {code}



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

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

[JENKINS-EA] Lucene-Solr-6.4-Linux (32bit/jdk-9-ea+159) - Build # 152 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Linux/152/
Java: 32bit/jdk-9-ea+159 -client -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingSorting

Error Message:
Should have exactly 4 documents returned expected:<4> but was:<3>

Stack Trace:
java.lang.AssertionError: Should have exactly 4 documents returned expected:<4> 
but was:<3>
at 
__randomizedtesting.SeedInfo.seed([8AA110EC2738523F:949918E45B93E8BF]: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.checkSortOrder(DocValuesNotIndexedTest.java:259)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingSorting(DocValuesNotIndexedTest.java:244)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:547)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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:367)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 

[JENKINS] Lucene-Solr-NightlyTests-6.4 - Build # 24 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/24/

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

Error Message:
Captured an uncaught exception in thread: Thread[id=51604, name=Thread-48985, 
state=RUNNABLE, group=TGRP-TestDistributedSearch]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=51604, name=Thread-48985, state=RUNNABLE, 
group=TGRP-TestDistributedSearch]
at 
__randomizedtesting.SeedInfo.seed([7C43ECEAAECF9795:F417D3300033FA6D]:0)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:41281/oci/qv/collection1: 
java.lang.NullPointerException
at 
org.apache.solr.search.grouping.distributed.responseprocessor.StoredFieldsShardResponseProcessor.process(StoredFieldsShardResponseProcessor.java:41)
at 
org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:757)
at 
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:740)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:428)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:166)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2299)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:296)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:110)
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:462)
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.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:745)

at __randomizedtesting.SeedInfo.seed([7C43ECEAAECF9795]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:610)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.TestDistributedSearch$1.run(TestDistributedSearch.java:1116)


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

Error Message:
document count mismatch.  control=9682 sum(shards)=9693 cloudClient=9693

Stack Trace:
java.lang.AssertionError: document count mismatch.  control=9682 
sum(shards)=9693 cloudClient=9693
at 

[jira] [Updated] (SOLR-8052) Tests using MiniKDC do not work with Java 9 Jigsaw

[Hoss Man (JIRA)]

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

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

updated patch, some small cleanups

> Tests using MiniKDC do not work with Java 9 Jigsaw
> --
>
> Key: SOLR-8052
> URL: https://issues.apache.org/jira/browse/SOLR-8052
> Project: Solr
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: 5.3
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: SOLR-8052.patch, SOLR-8052.patch
>
>
> As described in my status update yesterday, there are some problems in 
> dependencies shipped with Solr that don't work with Java 9 Jigsaw builds.
> org.apache.solr.cloud.SaslZkACLProviderTest.testSaslZkACLProvider
> {noformat}
>[junit4]> Throwable #1: java.lang.RuntimeException: 
> java.lang.IllegalAccessException: Class org.apache.hadoop.minikdc.MiniKdc can 
> not access a member of class sun.security.krb5.Config (module 
> java.security.jgss) with modifiers "public static", module java.security.jgss 
> does not export sun.security.krb5 to 
>[junit4]>at 
> org.apache.solr.cloud.SaslZkACLProviderTest$SaslZkTestServer.run(SaslZkACLProviderTest.java:211)
>[junit4]>at 
> org.apache.solr.cloud.SaslZkACLProviderTest.setUp(SaslZkACLProviderTest.java:81)
>[junit4]>at java.lang.Thread.run(java.base@9.0/Thread.java:746)
>[junit4]> Caused by: java.lang.IllegalAccessException: Class 
> org.apache.hadoop.minikdc.MiniKdc can not access a member of class 
> sun.security.krb5.Config (module java.security.jgss) with modifiers "public 
> static", module java.security.jgss does not export sun.security.krb5 to 
> 
>[junit4]>at 
> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(java.base@9.0/AccessibleObject.java:384)
>[junit4]>at 
> java.lang.reflect.AccessibleObject.checkAccess(java.base@9.0/AccessibleObject.java:376)
>[junit4]>at 
> org.apache.hadoop.minikdc.MiniKdc.initKDCServer(MiniKdc.java:478)
>[junit4]>at 
> org.apache.hadoop.minikdc.MiniKdc.start(MiniKdc.java:320)
>[junit4]>at 
> org.apache.solr.cloud.SaslZkACLProviderTest$SaslZkTestServer.run(SaslZkACLProviderTest.java:204)
>[junit4]>... 38 moreThrowable #2: 
> java.lang.NullPointerException
>[junit4]>at 
> org.apache.solr.cloud.ZkTestServer$ZKServerMain.shutdown(ZkTestServer.java:334)
>[junit4]>at 
> org.apache.solr.cloud.ZkTestServer.shutdown(ZkTestServer.java:526)
>[junit4]>at 
> org.apache.solr.cloud.SaslZkACLProviderTest$SaslZkTestServer.shutdown(SaslZkACLProviderTest.java:218)
>[junit4]>at 
> org.apache.solr.cloud.SaslZkACLProviderTest.tearDown(SaslZkACLProviderTest.java:116)
>[junit4]>at java.lang.Thread.run(java.base@9.0/Thread.java:746)
> {noformat}
> This is really bad, bad, bad! All security related stuff should never ever be 
> reflected on!
> So we have to open issue in MiniKdc project so they remove the "hacks". 
> Elasticsearch had
> similar problems with Amazon's AWS API. The worked around with a funny hack 
> in their SecurityPolicy
> (https://github.com/elastic/elasticsearch/pull/13538). But as Solr does not 
> run with SecurityManager
> in production, there is no way to do that. 
> We should report issue on the MiniKdc project, so they fix their code and 
> remove the really bad reflection on Java's internal classes.
> FYI, my 
> [conclusion|http://mail-archives.apache.org/mod_mbox/lucene-dev/201509.mbox/%3C014801d0ee23%245c8f5df0%2415ae19d0%24%40thetaphi.de%3E]
>  from yesterday.



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

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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, 
TransactionLog, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:852)  at 
org.apache.solr.core.SolrCore.reload(SolrCore.java:638)  at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1138)  at 
org.apache.solr.core.SolrCore.lambda$getConfListener$6(SolrCore.java:2923)  at 
org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225)
  at java.lang.Thread.run(Thread.java:745)  
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:347)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:98)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:727)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:913)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:829)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:949)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:885)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:88)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:370)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:388)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:747)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:728)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:509)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)
  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.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:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 

[jira] [Commented] (SOLR-10237) Poly-Fields should error if subfield has docValues=true

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10237:
-

Oh I see; thanks for the explanation.

bq. Another option is to start supporting DV in the coordinates by creating the 
DV fields when requested, they could be used as you said when ValueSource is 
needed, probably inheriting the configuration (docValues=true/false) from the 
PointType field?

I think this is the path forward.  Doing anything else is worse -- why 
_shouldn't_ we let users use DocValues for purposes that DocValues were created 
for?

As a related aside... I'm wondering if we may want to deprecate/remove the 
singular {{SchemaField.createField}} and simply have all field types do their 
logic in one method {{createFields}}.  Perhaps further, it might accept the 
Lucene {{Document}} as a destination to thus avoid some needless {{Field[]}} 
creation.  If you agree, the method might then be named {{addFieldsToDoc}}.  
I'm bumping into this a bit as I contemplate a TextField that can optionally 
put it's stored value embedded in a separate (compressed) BinaryDocValuesField 
-- SOLR-10117.

> Poly-Fields should error if subfield has docValues=true
> ---
>
> Key: SOLR-10237
> URL: https://issues.apache.org/jira/browse/SOLR-10237
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-10237.patch
>
>
> DocValues aren’t really supported in poly-fields at this point, but they 
> don’t complain if the schema definition of the subfield has docValues=true. 
> This leaves the index in an inconsistent state, since the SchemaField has 
> docValues=true but there are no DV for the field.
> Since this breaks compatibility, I think we should just emit a warning unless 
> the subfield is an instance of {{PointType}}. With 
> {{\[Int/Long/Float/Double/Date\]PointType}} subfields, this is particularly 
> important, since they use {{IndexOrDocValuesQuery}}, that would return 
> incorrect results.



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

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

[jira] [Created] (SOLR-10243) Fix TestExtractionDateUtil.testParseDate sporadic failures

[David Smiley (JIRA)]

David Smiley created SOLR-10243:
---

 Summary: Fix TestExtractionDateUtil.testParseDate sporadic failures
 Key: SOLR-10243
 URL: https://issues.apache.org/jira/browse/SOLR-10243
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: David Smiley


Jenkins test failure:
{{ant test  -Dtestcase=TestExtractionDateUtil -Dtests.method=testParseDate 
-Dtests.seed=B72AC4792F31F74B -Dtests.slow=true -Dtests.locale=lv 
-Dtests.timezone=America/Metlakatla -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8}}   It reproduces on 6x for me but not master.

I reviewed this briefly and there seems to be a locale assumption in the test.

1 tests failed.
FAILED:  org.apache.solr.handler.extraction.TestExtractionDateUtil.testParseDate

Error Message:
Incorrect parsed timestamp: 1226583351000 != 1226579751000 (Thu Nov 13 04:35:51 
AKST 2008)

Stack Trace:
java.lang.AssertionError: Incorrect parsed timestamp: 1226583351000 != 
1226579751000 (Thu Nov 13 04:35:51 AKST 2008)
at 
__randomizedtesting.SeedInfo.seed([B72AC4792F31F74B:FD33BC4C549880FE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.extraction.TestExtractionDateUtil.assertParsedDate(TestExtractionDateUtil.java:59)
at 
org.apache.solr.handler.extraction.TestExtractionDateUtil.testParseDate(TestExtractionDateUtil.java:54)



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

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

[jira] [Commented] (SOLR-10242) Cores created by Solr RESTORE end up with stale searches after indexing

[John Marquiss (JIRA)]

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

John Marquiss commented on SOLR-10242:
--

I ran another simple test that I should have done earlier...

1) Restore
2) Restart Solr
3) Index new documents
4) Search - get expected count

This test passes... It looks like the problem is only with the initial searcher 
the restore command creates on the new collection.

> Cores created by Solr RESTORE end up with stale searches after indexing
> ---
>
> Key: SOLR-10242
> URL: https://issues.apache.org/jira/browse/SOLR-10242
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore, search
>Affects Versions: 6.3
> Environment: Behavior observed on both Linux and Windows:
> Linux version 3.10.0-327.36.3.el7.x86_64 
> (mockbu...@x86-037.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red 
> Hat 4.8.5-4) (GCC) ) #1 SMP Thu Oct 20 04:56:07 EDT 2016
> java version "1.8.0_77"
> Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
> Windows 10 Enterprise Version 1607 Build 14393.693
> java version "1.8.0_121"
> Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
>Reporter: John Marquiss
>
> Index files created by the Solr RESTORE feature are placed in a directory 
> with a name like "restore.20170307173236270" instead of the standard "index" 
> directory. This seems to break Solr's ability to detect index changes leading 
> to stale searchers on the restored cores.
> Detailed information including steps to replicate can be found in this 
> solr-user mail thread. [http://markmail.org/message/wsm56jgbh53fx24u]



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

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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 43380 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.5
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden class/interface use: java.util.logging.Logger [Use 
slf4j classes instead]
[forbidden-apis]   in 
org.apache.solr.handler.dataimport.TestJdbcDataSource$MockDriver 
(TestJdbcDataSource.java, method declaration of 'getParentLogger()')
[forbidden-apis] Scanned 188 (and 532 related) class file(s) for forbidden API 
invocations (in 0.15s), 1 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build.xml:387: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/common-build.xml:476: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/common-build.xml:527: Check 
for forbidden API calls failed, see log.

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



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

[jira] [Commented] (SOLR-10241) Add a configset for "classic" schema.xml.

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10241:
-

I sympathize with our users on this matter; there are various feature gaps that 
stand in the way of managed schema being the one best way to do things 
([~noble.paul] [~varunthacker] and I recently white-boarded the remaining 
ones).  Since that ideal reality isn't here today, I wish we had a better 
out-of-the-box experience for users that want to use classic schema.  

* Perhaps one approach is for bin/solr to automate conversion from managed 
schema to classic, provided the user adds an option?
* I kinda dread yet another config around here to maintain; but I certainly 
won't stand in anyone's way from doing so if that's how Erick (or whoever) puts 
forth their time to help users.  It's possibly the easiest (least work) path in 
the short term, but with longer term annoyances.
* I wish the current config mechanism was more universal to both: edit a 
schema.xml if you want, or purely use schema API if you want to do that.  I 
understand that we don't want Solr to clobber a user's changes, and so that 
concern led to where we are today.  One possible way to do this would be for 
the schema.xml file to contain an embedded hash of the schema (less the hash 
itself of course). It'd be optional and maybe have an explicit value a user 
could provide to give Solr permission to overwrite it (i.e. in no event should 
users calculate the hash themselves).  It would only be verified when an API 
based change attempts to overwrite a config.

> Add a configset for "classic" schema.xml.
> -
>
> Key: SOLR-10241
> URL: https://issues.apache.org/jira/browse/SOLR-10241
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>
> There are a number of questions on the user's list about hand-editing the 
> managed-schema files. I think there's also confusion about the fact that the 
> classic schema is still possible (yes, I know there's documentation, but)
> WDYT about creating a new configset that uses classic schema factory? And 
> perhaps make it pretty minimal? Just a few useful field types (text_en, the 
> primitive ones, maybe with a couple with stopword files in the lang subdir). 
> Just enough to show a good structure... 
> Straw man candidates to remove:
> schema
> > most/all of the language variants
> > dynamic fields (maybe leave one in a comment)
> > copyField directives (maybe leave one in a comment)
> > ???
> solrconfig
> > clustering, 
> > most if not all of the language variants (maybe include one or two in 
> > comments). 
> > QEV. 
> > Take out anything that requires adding  directives
> > browse request handler
> > ???
> Maybe put in a comment where to find the examples (e.g. one of the existing 
> config sets).
> That said, how this squares with simplifying/cleaning up current configsets 
> is a good question.
> (from on offline conversation) There are already at least 2 issues about 
> cleaning up the existing ones, so this is the same behavior that gets us into 
> this - we can’t agree on what good examples are so we just throw another one 
> into the pile



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

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

[jira] [Commented] (SOLR-10237) Poly-Fields should error if subfield has docValues=true

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-10237:
--

bq. {{solr.PointType}} (an x,y generic spatial field) supports DocValues in its 
coordinate fields so they can be used in ValueSource/"function queries"
I don't believe it does. When a PointType field is created it calls 
{{SchemaField.createField(...)}} on it coordinates, instead of 
{{SchemaField.createField**s**(...)}}. The first one of those only creates the 
"Index field", and doesn't create the DocValues field:
{code:java}
  @Override
  public List createFields(SchemaField field, Object value, 
float boost) {
String externalVal = value.toString();
String[] point = parseCommaSeparatedList(externalVal, dimension);

// TODO: this doesn't currently support polyFields as sub-field types
List f = new ArrayList<>(dimension+1);

if (field.indexed()) {
  for (int i=0; i Poly-Fields should error if subfield has docValues=true
> ---
>
> Key: SOLR-10237
> URL: https://issues.apache.org/jira/browse/SOLR-10237
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-10237.patch
>
>
> DocValues aren’t really supported in poly-fields at this point, but they 
> don’t complain if the schema definition of the subfield has docValues=true. 
> This leaves the index in an inconsistent state, since the SchemaField has 
> docValues=true but there are no DV for the field.
> Since this breaks compatibility, I think we should just emit a warning unless 
> the subfield is an instance of {{PointType}}. With 
> {{\[Int/Long/Float/Double/Date\]PointType}} subfields, this is particularly 
> important, since they use {{IndexOrDocValuesQuery}}, that would return 
> incorrect results.



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

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

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_121) - Build # 768 - Failure!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.lucene.store.TestRAFDirectory

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\misc\test\J1\temp\lucene.store.TestRAFDirectory_F21268B05B24362A-001\testThreadSafety-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\misc\test\J1\temp\lucene.store.TestRAFDirectory_F21268B05B24362A-001\testThreadSafety-001

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\misc\test\J1\temp\lucene.store.TestRAFDirectory_F21268B05B24362A-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\misc\test\J1\temp\lucene.store.TestRAFDirectory_F21268B05B24362A-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\misc\test\J1\temp\lucene.store.TestRAFDirectory_F21268B05B24362A-001\testThreadSafety-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\misc\test\J1\temp\lucene.store.TestRAFDirectory_F21268B05B24362A-001\testThreadSafety-001
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\misc\test\J1\temp\lucene.store.TestRAFDirectory_F21268B05B24362A-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\misc\test\J1\temp\lucene.store.TestRAFDirectory_F21268B05B24362A-001

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




Build Log:
[...truncated 7734 lines...]
   [junit4] Suite: org.apache.lucene.store.TestRAFDirectory
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): {}, 
docValues:{}, maxPointsInLeafNode=1867, maxMBSortInHeap=5.594630573602334, 
sim=RandomSimilarity(queryNorm=false,coord=crazy): {}, locale=ar-SD, 
timezone=GMT
   [junit4]   2> NOTE: Windows 10 10.0 amd64/Oracle Corporation 1.8.0_121 
(64-bit)/cpus=3,threads=1,free=48144992,total=64880640
   [junit4]   2> NOTE: All tests run in this JVM: [TestNumericTerms32, 
TestPKIndexSplitter, TestRAFDirectory]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRAFDirectory 
-Dtests.seed=F21268B05B24362A -Dtests.slow=true -Dtests.locale=ar-SD 
-Dtests.timezone=GMT -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.00s J1 | TestRAFDirectory (suite) <<<
   [junit4]> Throwable #1: java.io.IOException: Could not remove the 
following files (in the order of attempts):
   [junit4]>
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\misc\test\J1\temp\lucene.store.TestRAFDirectory_F21268B05B24362A-001\testThreadSafety-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\misc\test\J1\temp\lucene.store.TestRAFDirectory_F21268B05B24362A-001\testThreadSafety-001
   [junit4]>
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\misc\test\J1\temp\lucene.store.TestRAFDirectory_F21268B05B24362A-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\misc\test\J1\temp\lucene.store.TestRAFDirectory_F21268B05B24362A-001
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([F21268B05B24362A]:0)
   [junit4]>at org.apache.lucene.util.IOUtils.rm(IOUtils.java:323)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4] Completed [5/24 (1!)] on J1 in 2.81s, 44 tests, 1 error <<< 
FAILURES!

[jira] [Commented] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10235:


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

SOLR-10235: fix precommit


> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>  Labels: java9
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch, SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

[jira] [Commented] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10235:


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

SOLR-10235: fix precommit


> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>  Labels: java9
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch, SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

[jira] [Resolved] (SOLR-9857) Collect aggregated metrics from replicas in shard leader

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-9857.
-
   Resolution: Fixed
Fix Version/s: master (7.0)

This functionality was implemented as a part of SOLR-9858.

> Collect aggregated metrics from replicas in shard leader
> 
>
> Key: SOLR-9857
> URL: https://issues.apache.org/jira/browse/SOLR-9857
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: master (7.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-9857.patch, SOLR-9857.patch
>
>
> Shard leaders can collect metrics from replicas in order to learn about their 
> load and the progress of replication. These per-replica metrics need to be 
> aggregated (if possible) in order to report cluster-wide per-shard metrics.



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

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

[jira] [Commented] (SOLR-9858) Collect aggregated metrics from nodes and shard leaders in overseer

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9858: Collect aggregated metrics from nodes and shard leaders in overseer.


> Collect aggregated metrics from nodes and shard leaders in overseer
> ---
>
> Key: SOLR-9858
> URL: https://issues.apache.org/jira/browse/SOLR-9858
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: master (7.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-9858.patch, SOLR-9858.patch, SOLR-9858.patch
>
>
> Overseer can collect metrics from Solr nodes and shard leaders in order to 
> have a notion of the indexing / query / replication / system load on each 
> node, shard and its replicas. This information then can be used for cluster 
> (auto)scaling.



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

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

[jira] [Resolved] (SOLR-9858) Collect aggregated metrics from nodes and shard leaders in overseer

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-9858.
-
   Resolution: Fixed
Fix Version/s: master (7.0)

> Collect aggregated metrics from nodes and shard leaders in overseer
> ---
>
> Key: SOLR-9858
> URL: https://issues.apache.org/jira/browse/SOLR-9858
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: master (7.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-9858.patch, SOLR-9858.patch, SOLR-9858.patch
>
>
> Overseer can collect metrics from Solr nodes and shard leaders in order to 
> have a notion of the indexing / query / replication / system load on each 
> node, shard and its replicas. This information then can be used for cluster 
> (auto)scaling.



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

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

[jira] [Commented] (SOLR-10079) TestInPlaceUpdates(Distrib|Standalone) failures

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10079:
-

Another failure, non-reproducible:
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19121/
{code}
 java.lang.AssertionError: Repeated retry for 'set' results against client: 
org.apache.solr.client.solrj.impl.HttpSolrClient@17a2792 (leader); Never got 
numFound=447; results=> {numFound=0,start=0,docs=[]}
at 
__randomizedtesting.SeedInfo.seed([2326B2BC5ACAB4FF:AB728D66F436D907]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.assertDocIdsAndValuesAgainstAllClients(TestInPlaceUpdatesDistrib.java:424)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.docValuesUpdateTest(TestInPlaceUpdatesDistrib.java:361)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:157)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{code}

> TestInPlaceUpdates(Distrib|Standalone) failures
> ---
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10079.patch, stdout
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
> reproduces for me:
> {noformat}
> Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
> -Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 
> 79], now: [78, 78, 78]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:543)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
> id=PostingsFormat(name=Asserting), 
> id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
> docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
> id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
> title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
> id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
>  inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
> inplace_updatable_int=DocValuesFormat(name=Direct), 
> inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=sr-Latn-RS, 
> timezone=America/Grand_Turk
>[junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=12,threads=1,free=107734480,total=518979584
> {noformat}



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

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

[jira] [Commented] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-10235:
--

Oh yeah. Sorry, I'll fix.

> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>  Labels: java9
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch, SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

[jira] [Commented] (SOLR-10237) Poly-Fields should error if subfield has docValues=true

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10237:
-

I'm trying to understand the problem here.  {{solr.PointType}} (an x,y generic 
spatial field) supports DocValues in its coordinate fields so they can be used 
in ValueSource/"function queries"; or am I wrong here?

> Poly-Fields should error if subfield has docValues=true
> ---
>
> Key: SOLR-10237
> URL: https://issues.apache.org/jira/browse/SOLR-10237
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-10237.patch
>
>
> DocValues aren’t really supported in poly-fields at this point, but they 
> don’t complain if the schema definition of the subfield has docValues=true. 
> This leaves the index in an inconsistent state, since the SchemaField has 
> docValues=true but there are no DV for the field.
> Since this breaks compatibility, I think we should just emit a warning unless 
> the subfield is an instance of {{PointType}}. With 
> {{\[Int/Long/Float/Double/Date\]PointType}} subfields, this is particularly 
> important, since they use {{IndexOrDocValuesQuery}}, that would return 
> incorrect results.



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

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

Re: possible regression replacing PayloadTermQuery with PayloadScoreQuery in lucene 6.

[Alan Woodward]

Hi, I don’t think this was an intentional change, and it looks as though it 
would be a fairly easy thing to fix - do you want to open an issue?

Alan Woodward
www.flax.co.uk


> On 7 Mar 2017, at 17:19, Nathan Gass  wrote:
> 
> Hello
> 
> I'm using PayloadTermQuery and MaxPayloadFunction together with a custom 
> similarity which provided a default value for terms without payloads. The 
> scorePayload of my custom similarity got called for every term (with or 
> without payload) and the resulting score used the maximum of all returned 
> values.
> 
> When switching to PayloadScoreQuery in lucene 6, this behavior changed. 
> scorePayload only gets called for terms with payloads and terms without 
> payloads get ignored for the MaxPayloadFunction. Is this change intentional? 
> If not I'm happy to create an issue and try to make a patch.
> 
> Would there be some other way to achieve my goal? I'd rather not add a 
> payload for every term (I'm using delimited_payload_filter in elasticsearch 
> and therefore currently do not need any custom analysis plugins).
> 
> Greetings
> Nathan Gass
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

[jira] [Updated] (SOLR-10039) LatLonPointSpatialField

[David Smiley (JIRA)]

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

David Smiley updated SOLR-10039:

Attachment: SOLR_10039_LatLonPointSpatialField.patch

I've got another patch revision here.  Essentially I noticed/forgot about 
Lucene's {{IndexOrDocValuesQuery}} which in turn made me also realize this 
field could support queries even if it has only docValues.  So I added both.  I 
also expanded the testing to include some variations.

> LatLonPointSpatialField
> ---
>
> Key: SOLR-10039
> URL: https://issues.apache.org/jira/browse/SOLR-10039
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_10039_LatLonPointSpatialField.patch, 
> SOLR_10039_LatLonPointSpatialField.patch, 
> SOLR_10039_LatLonPointSpatialField.patch, 
> SOLR_10039_LatLonPointSpatialField.patch
>
>
> The fastest and most efficient spatial field for point data in Lucene/Solr is 
> {{LatLonPoint}} in Lucene's sandbox module.  I'll include 
> {{LatLonDocValuesField}} with this even though it's a separate class.  
> LatLonPoint is based on the Points API, using a BKD index.  It's multi-valued 
> capable.  LatLonDocValuesField is based on sorted numeric DocValues, and thus 
> is also multi-valued capable (a big deal as the existing Solr ones either 
> aren't or do poorly at it).  Note that this feature is limited to a 
> latitude/longitude spherical world model.  And furthermore the precision is 
> at about a centimeter -- less precise than the other spatial fields but 
> nonetheless plenty good for most applications.  Last but not least, this 
> capability natively supports polygons, albeit those that don't wrap the 
> dateline or a pole.
> I propose a {{LatLonPointSpatialField}} which uses this.  Patch & details 
> forthcoming...
> This development was funded by the Harvard Center for Geographic Analysis as 
> part of the HHypermap project



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

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

[jira] [Commented] (SOLR-10241) Add a configset for "classic" schema.xml.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10241:
---

>From the user's list, points to clarify in the ref guide:

I would second that guide could be clearer on that. I read and reread several 
times trying to get my head around the schema.xml/managed-schema bit. I came 
away from first cursory reading with the idea that managed-schema was mostly 
for schema-less mode and only after some stuff ups and puzzling over comments 
in the basic-config schema file itself did I go back for more careful re-read. 
I am still not sure that I have got all the nuances. My understanding is:

If you don’t want ability to edit it via admin UI or config api, rename to 
schema.xml. Unclear whether you have to make changes to other configs to do 
this. Also unclear to me whether there was any upside at all to using 
schema.xml? Why degrade functionality? Does the capacity for schema.xml only 
exist for backward compatibility?

If you want to run schema-less, you have to use managed-schema? (I didn’t 
delve too deep into this).

In the end, I used basic-config to create core and then hacked managed-schema 
from there.


I would have to say the "basic-config" seems distinctly more than basic. It is 
still a huge file. I thought perhaps I could delete every unused field type, 
but worried there were some "system" dependencies. Ie if you want *target type 
wildcard queries do you need to have text_general_reverse and a copy to it? If 
you always explicitly set only defined fields in a custom indexer, then can you 
dump the whole dynamic fields bit?

> Add a configset for "classic" schema.xml.
> -
>
> Key: SOLR-10241
> URL: https://issues.apache.org/jira/browse/SOLR-10241
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>
> There are a number of questions on the user's list about hand-editing the 
> managed-schema files. I think there's also confusion about the fact that the 
> classic schema is still possible (yes, I know there's documentation, but)
> WDYT about creating a new configset that uses classic schema factory? And 
> perhaps make it pretty minimal? Just a few useful field types (text_en, the 
> primitive ones, maybe with a couple with stopword files in the lang subdir). 
> Just enough to show a good structure... 
> Straw man candidates to remove:
> schema
> > most/all of the language variants
> > dynamic fields (maybe leave one in a comment)
> > copyField directives (maybe leave one in a comment)
> > ???
> solrconfig
> > clustering, 
> > most if not all of the language variants (maybe include one or two in 
> > comments). 
> > QEV. 
> > Take out anything that requires adding  directives
> > browse request handler
> > ???
> Maybe put in a comment where to find the examples (e.g. one of the existing 
> config sets).
> That said, how this squares with simplifying/cleaning up current configsets 
> is a good question.
> (from on offline conversation) There are already at least 2 issues about 
> cleaning up the existing ones, so this is the same behavior that gets us into 
> this - we can’t agree on what good examples are so we just throw another one 
> into the pile



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+159) - Build # 19121 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19121/
Java: 32bit/jdk-9-ea+159 -server -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest: 1) Thread[id=6475, 
name=qtp14165423-6475, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9-ea/java.lang.Object.wait(Native Method) at 
app//org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient.waitForEmptyQueue(ConcurrentUpdateSolrClient.java:657)
 at 
app//org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient.blockUntilFinished(ConcurrentUpdateSolrClient.java:589)
 at 
app//org.apache.solr.update.StreamingSolrClients.blockUntilFinished(StreamingSolrClients.java:91)
 at 
app//org.apache.solr.update.SolrCmdDistributor.blockAndDoRetries(SolrCmdDistributor.java:243)
 at 
app//org.apache.solr.update.SolrCmdDistributor.finish(SolrCmdDistributor.java:95)
 at 
app//org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:844)
 at 
app//org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1919)
 at 
app//org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:182)
 at 
app//org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
 at 
app//org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
 at app//org.apache.solr.core.SolrCore.execute(SolrCore.java:2423)  
   at app//org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:722)  
   at app//org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:528) 
at 
app//org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)
 at 
app//org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)
 at 
app//org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
 at 
app//org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
 at 
app//org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
 at 
app//org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
at 
app//org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
 at 
app//org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
 at 
app//org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
   at 
app//org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
 at 
app//org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
 at 
app//org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
 at 
app//org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)
 at 
app//org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
 at app//org.eclipse.jetty.server.Server.handle(Server.java:534)
 at app//org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  
   at 
app//org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
 at 
app//org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
 at 
app//org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) 
at 
app//org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
 at 
app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
 at 
app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
 at 
app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
 at java.base@9-ea/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest: 
   1) Thread[id=6475, name=qtp14165423-6475, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest]
at java.base@9-ea/java.lang.Object.wait(Native Method)
at 
app//org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient.waitForEmptyQueue(ConcurrentUpdateSolrClient.java:657)
at 

[jira] [Commented] (SOLR-10241) Add a configset for "classic" schema.xml.

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-10241:
--

This all depends on what you want to achieve and work backwards from it. The 
scenario is that somebody does not want managed schema? Why? For security? They 
can lock it down. For legacy reasons? Then they already know enough Solr. 
Because many tutorials on the web still talk about old-style? Maybe there is a 
need for "upgrade" manual page or blog post.

It may be that we really should just do a manual page that is dedicated to this 
topic and its trade-off. And mention it in the config file. Or we could do a 
minimal example.

But the right way to think about it - I feel - would be backwards from the 
typical scenario.



> Add a configset for "classic" schema.xml.
> -
>
> Key: SOLR-10241
> URL: https://issues.apache.org/jira/browse/SOLR-10241
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>
> There are a number of questions on the user's list about hand-editing the 
> managed-schema files. I think there's also confusion about the fact that the 
> classic schema is still possible (yes, I know there's documentation, but)
> WDYT about creating a new configset that uses classic schema factory? And 
> perhaps make it pretty minimal? Just a few useful field types (text_en, the 
> primitive ones, maybe with a couple with stopword files in the lang subdir). 
> Just enough to show a good structure... 
> Straw man candidates to remove:
> schema
> > most/all of the language variants
> > dynamic fields (maybe leave one in a comment)
> > copyField directives (maybe leave one in a comment)
> > ???
> solrconfig
> > clustering, 
> > most if not all of the language variants (maybe include one or two in 
> > comments). 
> > QEV. 
> > Take out anything that requires adding  directives
> > browse request handler
> > ???
> Maybe put in a comment where to find the examples (e.g. one of the existing 
> config sets).
> That said, how this squares with simplifying/cleaning up current configsets 
> is a good question.
> (from on offline conversation) There are already at least 2 issues about 
> cleaning up the existing ones, so this is the same behavior that gets us into 
> this - we can’t agree on what good examples are so we just throw another one 
> into the pile



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

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

[jira] [Commented] (SOLR-10241) Add a configset for "classic" schema.xml.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10241:
---

I've been having second thoughts about a "classic" configset, but I can go 
either way on that. Would it do to have a better comment in, say, basic configs 
that had the classic schema factory ready? Something like "replace the managed 
schema with this"?

that's separate from the kitchen sink bits which could also be moved out of 
basic_configs.



> Add a configset for "classic" schema.xml.
> -
>
> Key: SOLR-10241
> URL: https://issues.apache.org/jira/browse/SOLR-10241
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>
> There are a number of questions on the user's list about hand-editing the 
> managed-schema files. I think there's also confusion about the fact that the 
> classic schema is still possible (yes, I know there's documentation, but)
> WDYT about creating a new configset that uses classic schema factory? And 
> perhaps make it pretty minimal? Just a few useful field types (text_en, the 
> primitive ones, maybe with a couple with stopword files in the lang subdir). 
> Just enough to show a good structure... 
> Straw man candidates to remove:
> schema
> > most/all of the language variants
> > dynamic fields (maybe leave one in a comment)
> > copyField directives (maybe leave one in a comment)
> > ???
> solrconfig
> > clustering, 
> > most if not all of the language variants (maybe include one or two in 
> > comments). 
> > QEV. 
> > Take out anything that requires adding  directives
> > browse request handler
> > ???
> Maybe put in a comment where to find the examples (e.g. one of the existing 
> config sets).
> That said, how this squares with simplifying/cleaning up current configsets 
> is a good question.
> (from on offline conversation) There are already at least 2 issues about 
> cleaning up the existing ones, so this is the same behavior that gets us into 
> this - we can’t agree on what good examples are so we just throw another one 
> into the pile



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

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

[jira] [Resolved] (LUCENE-7718) buildAndPushRelease.py script should refer to working tree instead of directory

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya resolved LUCENE-7718.
--
   Resolution: Fixed
 Assignee: Ishan Chattopadhyaya
Fix Version/s: 6.4.2
   master (7.0)
   branch_6x

> buildAndPushRelease.py script should refer to working tree instead of 
> directory
> ---
>
> Key: LUCENE-7718
> URL: https://issues.apache.org/jira/browse/LUCENE-7718
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
> Fix For: branch_6x, master (7.0), 6.4.2
>
>
> As per this commit,
> https://github.com/git/git/commit/2a0e6cdedab306eccbd297c051035c13d0266343
> the git status no longer reports:
> bq. nothing to commit, working directory clean
> but reports:
> bq. nothing to commit, working tree clean



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

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

[jira] [Commented] (LUCENE-7718) buildAndPushRelease.py script should refer to working tree instead of directory

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7718: buildAndPushRelease.py script should refer to working tree instead 
of directory


> buildAndPushRelease.py script should refer to working tree instead of 
> directory
> ---
>
> Key: LUCENE-7718
> URL: https://issues.apache.org/jira/browse/LUCENE-7718
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
>
> As per this commit,
> https://github.com/git/git/commit/2a0e6cdedab306eccbd297c051035c13d0266343
> the git status no longer reports:
> bq. nothing to commit, working directory clean
> but reports:
> bq. nothing to commit, working tree clean



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

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

[jira] [Commented] (LUCENE-7718) buildAndPushRelease.py script should refer to working tree instead of directory

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7718: buildAndPushRelease.py script should refer to working tree instead 
of directory


> buildAndPushRelease.py script should refer to working tree instead of 
> directory
> ---
>
> Key: LUCENE-7718
> URL: https://issues.apache.org/jira/browse/LUCENE-7718
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
>
> As per this commit,
> https://github.com/git/git/commit/2a0e6cdedab306eccbd297c051035c13d0266343
> the git status no longer reports:
> bq. nothing to commit, working directory clean
> but reports:
> bq. nothing to commit, working tree clean



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

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

[jira] [Commented] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-10235:
-

I haven't looked too closely at this patch, but for the DriverImpl for SolrJ 
JDBC we had to add a suppress annotation.

https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/io/sql/DriverImpl.java#L97

{code}
  @SuppressForbidden(reason="Required by jdbc")
  public Logger getParentLogger() {
return null;
  }
{code}

> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>  Labels: java9
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch, SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

[jira] [Commented] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-10235:
-

I have this commit locally. {{precommit}} just failed to me
{quote}
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.5
[forbidden-apis] Reading API signatures: 
/Users/khludnevm/lucene-solr/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/Users/khludnevm/lucene-solr/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/Users/khludnevm/lucene-solr/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden class/interface use: java.util.logging.Logger [Use 
slf4j classes instead]
[forbidden-apis]   in 
org.apache.solr.handler.dataimport.TestJdbcDataSource$MockDriver 
(TestJdbcDataSource.java, method declaration of 'getParentLogger()')
{quote}
beware

> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>  Labels: java9
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch, SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

[jira] [Commented] (SOLR-10200) Streaming Expressions should work in non-SolrCloud mode

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10200:
---

I'm currently considering the best options for testing the shards parameters. 
The next patch will include tests for the SignificantTermsStream with the 
shards parameter.

Once the test plan is worked out then this approach can be replicated for all 
the stream sources.

> Streaming Expressions should work in non-SolrCloud mode
> ---
>
> Key: SOLR-10200
> URL: https://issues.apache.org/jira/browse/SOLR-10200
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-10200.patch
>
>
> Currently Streaming Expressions select shards using an internal ZooKeeper 
> client. This ticket will allow stream sources to except a *shards* parameter 
> so that non-SolrCloud deployments can set the shards manually.
> The shards parameters will be added as http parameters in the following 
> format:
> collectionA.shards=url1,url1,...=url1,url2...
> The /stream handler will then add the shards to the StreamContext so all 
> stream sources can check to see if their collection has the shards set 
> manually.



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

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

[jira] [Updated] (SOLR-10200) Streaming Expressions should work in non-SolrCloud mode

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10200:
--
Description: 
Currently Streaming Expressions select shards using an internal ZooKeeper 
client. This ticket will allow stream sources to except a *shards* parameter so 
that non-SolrCloud deployments can set the shards manually.

The shards parameters will be added as http parameters in the following format:

collectionA.shards=url1,url1,...=url1,url2...

The /stream handler will then add the shards to the StreamContext so all stream 
sources can check to see if their collection has the shards set manually.




  was:
Currently Streaming Expressions select shards using an internal ZooKeeper 
client. This ticket will allow stream sources to except a *shards* parameter so 
that non-SolrCloud deployments can set the shards manually.

The shards parameters will be added as http parameters in the following format:

collectionA.shards=url1,url1,...=url1,url2...

The /stream handler with then add the shards to the StreamContext so all stream 
sources can check to see if their collection has the shards set manually.





> Streaming Expressions should work in non-SolrCloud mode
> ---
>
> Key: SOLR-10200
> URL: https://issues.apache.org/jira/browse/SOLR-10200
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-10200.patch
>
>
> Currently Streaming Expressions select shards using an internal ZooKeeper 
> client. This ticket will allow stream sources to except a *shards* parameter 
> so that non-SolrCloud deployments can set the shards manually.
> The shards parameters will be added as http parameters in the following 
> format:
> collectionA.shards=url1,url1,...=url1,url2...
> The /stream handler will then add the shards to the StreamContext so all 
> stream sources can check to see if their collection has the shards set 
> manually.



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

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

[ANNOUNCE] Apache Solr 6.4.2 released

[Ishan Chattopadhyaya]

7 March 2017, Apache Solr 6.4.2 available

Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted search and analytics, rich document
parsing, geospatial search, extensive REST APIs as well as parallel SQL.
Solr is enterprise grade, secure and highly scalable, providing fault
tolerant distributed search and indexing, and powers the search and
navigation features of many of the world's largest internet sites.

Solr 6.4.2 is available for immediate download at:

   -

   http://lucene.apache.org/solr/mirrors-solr-latest-redir.html

Please read CHANGES.txt for a full list of new features and changes:

   -

   https://lucene.apache.org/solr/6_4_2/changes/Changes.html

Solr 6.4.2 contains 4 bug fixes since the 6.4.1 release:

   -

   Serious performance degradation in Solr 6.4 due to the metrics
   collection. IndexWriter metrics collection turned off by default, directory
   level metrics collection completely removed (until a better design is
   found)
   -

   Transaction log replay can hit an NullPointerException due to new
   Metrics code
   -

   NullPointerException in CloudSolrClient when reading stale alias
   -

   UnifiedHighlighter and PostingsHighlighter bug in PrefixQuery and
   TermRangeQuery for multi-byte text

Further details of changes are available in the change log available at:
http://lucene.apache.org/solr/6_4_2/changes/Changes.html

Please report any feedback to the mailing lists (
http://lucene.apache.org/solr/discussion.html)
Note: The Apache Software Foundation uses an extensive mirroring network
for distributing releases. It is possible that the mirror you are using may
not have replicated the release yet. If that is the case, please try
another mirror. This also applies to Maven access.

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_121) - Build # 6437 - Failure!

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
null
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/6)={
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"MissingSegmentRecoveryTest_shard1_replica2",
  "base_url":"http://127.0.0.1:61798/solr;,
  "node_name":"127.0.0.1:61798_solr",
  "state":"active",
  "leader":"true"},
"core_node2":{
  "core":"MissingSegmentRecoveryTest_shard1_replica1",
  "base_url":"http://127.0.0.1:61801/solr;,
  "node_name":"127.0.0.1:61801_solr",
  "state":"down",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([3FA7A1A8C09E6730:6FF239AB99BFD12D]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:265)
at 
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 

[ANNOUNCE] Apache Lucene 6.4.2 released

[Ishan Chattopadhyaya]

7 March 2017, Apache Lucene™ 6.4.2 available

The Lucene PMC is pleased to announce the release of Apache Lucene 6.4.2

Apache Lucene is a high-performance, full-featured text search engine library
written entirely in Java. It is a technology suitable for nearly any
application that requires full-text search, especially cross-platform.

This release contains 1 bug fix since the 6.4.1 release:

   -

   CommonGramsQueryFilter was producing a disconnected token graph, messing
   up phrase queries during query parsing

The release is available for immediate download at:

   -

   http://www.apache.org/dyn/closer.lua/lucene/java/6.4.2

Please read CHANGES.txt for a full list of new features and changes:

   -

   https://lucene.apache.org/core/6_4_2/changes/Changes.html

Please report any feedback to the mailing lists (
http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases. It is possible that the mirror you are using may not
have replicated the release yet. If that is the case, please try another
mirror. This also goes for Maven access.

[jira] [Created] (SOLR-10242) Cores created by Solr RESTORE end up with stale searches after indexing

[John Marquiss (JIRA)]

John Marquiss created SOLR-10242:


 Summary: Cores created by Solr RESTORE end up with stale searches 
after indexing
 Key: SOLR-10242
 URL: https://issues.apache.org/jira/browse/SOLR-10242
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Backup/Restore, search
Affects Versions: 6.3
 Environment: Behavior observed on both Linux and Windows:
Linux version 3.10.0-327.36.3.el7.x86_64 
(mockbu...@x86-037.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red 
Hat 4.8.5-4) (GCC) ) #1 SMP Thu Oct 20 04:56:07 EDT 2016
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

Windows 10 Enterprise Version 1607 Build 14393.693
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

Reporter: John Marquiss


Index files created by the Solr RESTORE feature are placed in a directory with 
a name like "restore.20170307173236270" instead of the standard "index" 
directory. This seems to break Solr's ability to detect index changes leading 
to stale searchers on the restored cores.

Detailed information including steps to replicate can be found in this 
solr-user mail thread. [http://markmail.org/message/wsm56jgbh53fx24u]



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

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

[jira] [Updated] (SOLR-10200) Streaming Expressions should uses the shards parameter if present

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10200:
--
Attachment: SOLR-10200.patch

Initial patch that allows the SignificantTermsStream to work with the shards 
parameter. The TupleStream abstract class now has static methods for handing 
the shard URL selection.

> Streaming Expressions should uses the shards parameter if present
> -
>
> Key: SOLR-10200
> URL: https://issues.apache.org/jira/browse/SOLR-10200
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-10200.patch
>
>
> Currently Streaming Expressions select shards using an internal ZooKeeper 
> client. This ticket will allow stream sources to except a *shards* parameter 
> so that non-SolrCloud deployments can set the shards manually.
> The shards parameters will be added as http parameters in the following 
> format:
> collectionA.shards=url1,url1,...=url1,url2...
> The /stream handler with then add the shards to the StreamContext so all 
> stream sources can check to see if their collection has the shards set 
> manually.



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

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

[jira] [Updated] (SOLR-10200) Streaming Expressions should work in non-SolrCloud mode

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10200:
--
Summary: Streaming Expressions should work in non-SolrCloud mode  (was: 
Streaming Expressions should uses the shards parameter if present)

> Streaming Expressions should work in non-SolrCloud mode
> ---
>
> Key: SOLR-10200
> URL: https://issues.apache.org/jira/browse/SOLR-10200
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-10200.patch
>
>
> Currently Streaming Expressions select shards using an internal ZooKeeper 
> client. This ticket will allow stream sources to except a *shards* parameter 
> so that non-SolrCloud deployments can set the shards manually.
> The shards parameters will be added as http parameters in the following 
> format:
> collectionA.shards=url1,url1,...=url1,url2...
> The /stream handler with then add the shards to the StreamContext so all 
> stream sources can check to see if their collection has the shards set 
> manually.



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

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

[jira] [Commented] (SOLR-10241) Add a configset for "classic" schema.xml.

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-10241:
--

Not a bad idea. In my mind it all depends on having a kitchen-sink schema from 
which things can be copied. If that exists and explains the cross-dependencies 
(e.g. this field definition is used in solrconfig.xml because of), then we 
can simplify other things quite a lot.

So, to me, we kind of need an umbrella issue to hash out what "kitchen sink" 
could look like and then what that means going downstream. And - of course - 
people willing to think about it in details, which is actually the bigger 
problem.

> Add a configset for "classic" schema.xml.
> -
>
> Key: SOLR-10241
> URL: https://issues.apache.org/jira/browse/SOLR-10241
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>
> There are a number of questions on the user's list about hand-editing the 
> managed-schema files. I think there's also confusion about the fact that the 
> classic schema is still possible (yes, I know there's documentation, but)
> WDYT about creating a new configset that uses classic schema factory? And 
> perhaps make it pretty minimal? Just a few useful field types (text_en, the 
> primitive ones, maybe with a couple with stopword files in the lang subdir). 
> Just enough to show a good structure... 
> Straw man candidates to remove:
> schema
> > most/all of the language variants
> > dynamic fields (maybe leave one in a comment)
> > copyField directives (maybe leave one in a comment)
> > ???
> solrconfig
> > clustering, 
> > most if not all of the language variants (maybe include one or two in 
> > comments). 
> > QEV. 
> > Take out anything that requires adding  directives
> > browse request handler
> > ???
> Maybe put in a comment where to find the examples (e.g. one of the existing 
> config sets).
> That said, how this squares with simplifying/cleaning up current configsets 
> is a good question.
> (from on offline conversation) There are already at least 2 issues about 
> cleaning up the existing ones, so this is the same behavior that gets us into 
> this - we can’t agree on what good examples are so we just throw another one 
> into the pile



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

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

[jira] [Created] (SOLR-10241) Add a configset for "classic" schema.xml.

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-10241:
-

 Summary: Add a configset for "classic" schema.xml.
 Key: SOLR-10241
 URL: https://issues.apache.org/jira/browse/SOLR-10241
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson


There are a number of questions on the user's list about hand-editing the 
managed-schema files. I think there's also confusion about the fact that the 
classic schema is still possible (yes, I know there's documentation, but)

WDYT about creating a new configset that uses classic schema factory? And 
perhaps make it pretty minimal? Just a few useful field types (text_en, the 
primitive ones, maybe with a couple with stopword files in the lang subdir). 
Just enough to show a good structure... 

Straw man candidates to remove:
schema
> most/all of the language variants
> dynamic fields (maybe leave one in a comment)
> copyField directives (maybe leave one in a comment)
> ???
solrconfig
> clustering, 
> most if not all of the language variants (maybe include one or two in 
> comments). 
> QEV. 
> Take out anything that requires adding  directives
> browse request handler
> ???

Maybe put in a comment where to find the examples (e.g. one of the existing 
config sets).

That said, how this squares with simplifying/cleaning up current configsets is 
a good question.

(from on offline conversation) There are already at least 2 issues about 
cleaning up the existing ones, so this is the same behavior that gets us into 
this - we can’t agree on what good examples are so we just throw another one 
into the pile



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

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

[jira] [Commented] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10235:


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

SOLR-10235: Fix DIH's TestJdbcDataSource to work with Java 9 and other Java 
runtimes that do not use the same DriverManager implementation like Oracle's 
original one


> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: java9
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch, SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

[jira] [Resolved] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved SOLR-10235.
--
   Resolution: Fixed
 Assignee: Uwe Schindler
Fix Version/s: master (7.0)
   6.5

> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>  Labels: java9
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch, SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

[jira] [Commented] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10235:


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

SOLR-10235: Fix DIH's TestJdbcDataSource to work with Java 9 and other Java 
runtimes that do not use the same DriverManager implementation like Oracle's 
original one


> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: java9
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch, SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

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

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: Document mismatch on target after sync 
expected:<2000> but was:<1000>
at 
__randomizedtesting.SeedInfo.seed([48351F47AE662088:91634E83AD0233C2]: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.testBootstrapWithSourceCluster(CdcrBootstrapTest.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12520 lines...]
   [junit4] Suite: 

[jira] [Commented] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10235:
-

+1

> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: java9
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch, SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

[jira] [Updated] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-10235:
-
Attachment: SOLR-10235.patch

New patch.

> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: java9
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch, SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

[jira] [Commented] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10235:
-

bq.  I can add a note to the Javadocs why it is not a mock, but the purpose of 
this class is identical to the other "mock" classes in this package (there is a 
mock JNDI Data Source that behaves similar).

My point is that in _this_ test class (TestJdbcDataSource) the new 
{{MockDriver}} class is the only "mock" class we explicitly define - all other 
code in this test uses Mockito based mocks, so it would be easy for someone 
down the road to look at this class and think "this MockDriver class looks like 
cruft we can replace with another one line Mockito call" ... basically i'm just 
suggesting that virtually the same verbage from the 
{{testRetrieveFromDriverManager}} method should be in  {{MockDriver}}'s 
javadocs.

bq. I disagree with that, sorry. As there can be more than one driver installed 
in the system, ...

AUGH! ... yoy are completely correct, i wasn't thinking holisticly about the 
DriverManager as a whole ... agreed, ignore that suggestion completley.

> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: java9
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

[jira] [Commented] (SOLR-8906) Make transient core cache pluggable.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8906:
--

bq:  why do we want to unload a core?

Well, I know of at least one situation where people have implemented 
auto-scaling that can do things like:
> split an index in the background. More generally maintain indexes of size no 
> larger than X. Then move one or more of the splits "someplace else".
> move a core's index to SSD while it's hot.
> re-partition user's data based on some heuristics without downtime.
> any situation where a core is manipulated outside Solr and still needs to 
> service requests in the mean time.

So I do wonder if we can stand the question on its head. Rather than think of 
it as the transient cores being an afterthought, what if we move _all_ core 
management to a plugin? NOTE: this is _really_ fuzzy ATM, just askin'.

Then we wouldn't have the distinction _in solr_ of "transient", "lazy loading", 
"regular" deeply embedded in the CoreContainer & etc. code. Even in the case 
where we open/close the heavyweight objects rather than load/unload cores, we 
still have to maintain lists of what cores have searchers already open and the 
like, similar to what happens in transient cores. Does it make any sense to 
think of moving all core management to a (suitably modified) transient core 
plugin? Then the default implementation we provide would just manage the 
heavyweight objects rather than load/unload cores and others could do as they 
wished.

Going forward, when everything is SolrCloud, there would be a degenerate case 
of leader-only collections that could essentially be treated as we do the 
current standalone code I'd guess.

bq: lazy cores itself is a vestige a of the old master-slave model

Not at all sure I agree. Even when SolrCloud rules the world, there'll always 
be edge cases where some organization pushes the limit. I don't want to keep 
Solr from evolving just to accommodate these edge cases, but I also don't want 
to prematurely decide _for_ them that "we can do it better". 'cause we can't in 
situation N+1.

Oh, and let's keep a distinction between "lazy" and "transient" cores. "lazy" 
just means it isn't loaded until it's called for, it can be permanent after 
that. "transient" is the whole cache-and-load/unload-when-needed bit. Don't 
quite know how those will reconcile going forward, but the idea of 
opening/closing heavyweight objects is still "lazy" cores in some sense.



> Make transient core cache pluggable.
> 
>
> Key: SOLR-8906
> URL: https://issues.apache.org/jira/browse/SOLR-8906
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>
> The current Lazy Core stuff is pretty deeply intertwined in CoreContainer. 
> Adding and removing active cores is based on a simple LRU mechanism, but 
> keeping the right cores in the right internal structures involves a lot of 
> attention to locking various objects to update internal structures. This 
> makes it difficult/dangerous to use any other caching algorithms.
> Any single age-out algorithm will have non-optimal access patterns, so making 
> this pluggable would allow better algorithms to be substituted in those cases.
> If we ever extend transient cores to SolrCloud, we need to have load/unload 
> decisions that are cloud-aware rather then entirely local so in that sense 
> this is would lay some groundwork if we ever want to go there.
> So I'm going to try to hack together a PoC. Any ideas on the most sensible 
> pattern for this gratefully received.



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

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

[jira] [Comment Edited] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-10235 at 3/7/17 5:31 PM:
--

bq. 1) the javadocs for MockDriver should explain the purpose of this class 
given how much of the rest of the outer class uses Mockito.

The Javadocs already say that this is a simple Driver rimplementation, that 
returns a mock connection for any url that equals MY_JDBC_URL. I can add a note 
to the Javadocs why it is not a mock, but the purpose of this class is 
identical to the other "mock" classes in this package (there is a mock JNDI 
Data Source that behaves similar).

bq. 2) I don't like that you're shadowing the variable named {{driver}} ... at 
first glance this could confuse people skimming code who have already seen the 
class level {{driver}} variable ... better to use {{mockDriver}} or 
{{fixedClassDriver}} or something like that.

oh sorry, will fix that. The original code used driver so I kept that. FYI: The 
problem with Java 9 was not the class name! I analyzed Java 9's DriverManager: 
The problem was caused by another workflow used internally when trying to find 
the right driver. If you use a "Mock" Driver implementation (as Mockito class), 
it requires that JDBC runtime calls the methods in same order, which is not 
defined in the spec. Because of that you have to implement a "real" driver 
allowing several ways to get a connection, a mock is not enough. This "real" 
driver must be prepared that the runtime may call methods in different order or 
suddenly use different methods like "acceptURL" for the purpose of looking up 
the correct driver. It must also interact in a sane way with other drivers 
registered in the runtime. As the driver is JVM-Global, a mock is too risky.

bq. 3) rather then returning null, I suggest {{MockDriver.connect(...)}} throw 
a {{new SQLException("attempted to use this driver with bogus url")}} if 
{{acceptsURL(...)}} is false -- so if the day comes when someone breaks the 
code, they'll have a decent error msg to identify the bug instead of an NPE.

I disagree with that, sorry. As there can be more than one driver installed in 
the system, DriverManager will ask all of them one after each other until one 
of them does *not* return null. The NPE is according to JDBC spec: it tells 
DriverManager to use next driver (RTFM). If all Drivers return null, 
DriverManager will finally say: "invalid URL". For historical reasons, 
DriverManager will not use the {{acceptsURL()}}, because older JDBC drivers may 
not implement that method and only return null.


was (Author: thetaphi):
bq. 1) the javadocs for MockDriver should explain the purpose of this class 
given how much of the rest of the outer class uses Mockito.

The Javadocs already say that this is a simple Driver rimplementation, that 
returns a mock connection for any url that equals MY_JDBC_URL. I can add a note 
to the Javadocs why it is not a mock, but the purpose of this class is 
identical to the other "mock" classes in this package (there is a mock JNDI 
Data Source that behaves similar).

bq. 2) I don't like that you're shadowing the variable named {{driver}} ... at 
first glance this could confuse people skimming code who have already seen the 
class level {{driver}} variable ... better to use {{mockDriver}} or 
{{fixedClassDriver}} or something like that.

oh sorry, will revert that. The original code used driver so I kept that. The 
problem here was not the class name, I analyzed Java 9. The problem was caused 
by another workflow used internally when trying to find the right driver. If 
you use a "Mock" Driver implementation (as Mockito class), it requires that 
JDBC calls the methods in same order, which is undefined in the spec. Because 
of that you have to implement a "real" driver, a mock is not enough. Thois 
"real" driver must be prepared that the runtime may call methods in different 
order or suddenly use different methods like "acceptURL" for the purpose of 
looking up a driver.

bq. 3) rather then returning null, I suggest {{MockDriver.connect(...)}} throw 
a {{new SQLException("attempted to use this driver with bogus url")}} if 
{{acceptsURL(...)}} is false -- so if the day comes when someone breaks the 
code, they'll have a decent error msg to identify the bug instead of an NPE.

I disagree with that, sorry. As there can be more than one driver installed in 
the system, DriverManager will ask all of them one after each other until one 
of them does *not* return null. The NPE is according to JDBC spec: it tells 
DriverManager to use next driver (RTFM). If all Drivers return null, 
DriverManager will finally say: "invalid URL". For historical reasons, 
DriverManager will not use the {{acceptsURL()}}, because older JDBC drivers may 
not implement that method and only return null.

> fix last TestJdbcDataSource 

[jira] [Commented] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-10235:
--

bq. 1) the javadocs for MockDriver should explain the purpose of this class 
given how much of the rest of the outer class uses Mockito.

The Javadocs already say that this is a simple Driver rimplementation, that 
returns a mock connection for any url that equals MY_JDBC_URL. I can add a note 
to the Javadocs why it is not a mock, but the purpose of this class is 
identical to the other "mock" classes in this package (there is a mock JNDI 
Data Source that behaves similar).

bq. 2) I don't like that you're shadowing the variable named {{driver}} ... at 
first glance this could confuse people skimming code who have already seen the 
class level {{driver}} variable ... better to use {{mockDriver}} or 
{{fixedClassDriver}} or something like that.

oh sorry, will revert that. The original code used driver so I kept that. The 
problem here was not the class name, I analyzed Java 9. The problem was caused 
by another workflow used internally when trying to find the right driver. If 
you use a "Mock" Driver implementation (as Mockito class), it requires that 
JDBC calls the methods in same order, which is undefined in the spec. Because 
of that you have to implement a "real" driver, a mock is not enough. Thois 
"real" driver must be prepared that the runtime may call methods in different 
order or suddenly use different methods like "acceptURL" for the purpose of 
looking up a driver.

bq. 3) rather then returning null, I suggest {{MockDriver.connect(...)}} throw 
a {{new SQLException("attempted to use this driver with bogus url")}} if 
{{acceptsURL(...)}} is false -- so if the day comes when someone breaks the 
code, they'll have a decent error msg to identify the bug instead of an NPE.

I disagree with that, sorry. As there can be more than one driver installed in 
the system, DriverManager will ask all of them one after each other until one 
of them does *not* return null. The NPE is according to JDBC spec: it tells 
DriverManager to use next driver (RTFM). If all Drivers return null, 
DriverManager will finally say: "invalid URL". For historical reasons, 
DriverManager will not use the {{acceptsURL()}}, because older JDBC drivers may 
not implement that method and only return null.

> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: java9
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

possible regression replacing PayloadTermQuery with PayloadScoreQuery in lucene 6.

[Nathan Gass]

Hello

I'm using PayloadTermQuery and MaxPayloadFunction together with a custom 
similarity which provided a default value for terms without payloads. The 
scorePayload of my custom similarity got called for every term (with or without 
payload) and the resulting score used the maximum of all returned values.

When switching to PayloadScoreQuery in lucene 6, this behavior changed. 
scorePayload only gets called for terms with payloads and terms without 
payloads get ignored for the MaxPayloadFunction. Is this change intentional? If 
not I'm happy to create an issue and try to make a patch.

Would there be some other way to achieve my goal? I'd rather not add a payload 
for every term (I'm using delimited_payload_filter in elasticsearch and 
therefore currently do not need any custom analysis plugins).

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

[jira] [Commented] (SOLR-10235) fix last TestJdbcDataSource / mock issue with java9

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10235:
-

Uwe: i like this approach, three nits...

1) the javadocs for MockDriver should explain the purpose of this class given 
how much of the rest of the outer class uses Mockito.

2) I don't like that you're shadowing the variable named {{driver}} ... at 
first glance this could confuse people skimming code who have already seen the 
class level {{driver}} variable ... better to use {{mockDriver}} or 
{{fixedClassDriver}} or something like that.

3) rather then returning null, I suggest {{MockDriver.connect(...)}} throw a 
{{new SQLException("attempted to use this driver with bogus url")}} if 
{{acceptsURL(...)}} is false -- so if the day comes when someone breaks the 
code, they'll have a decent error msg to identify the bug instead of an NPE.

> fix last TestJdbcDataSource / mock issue with java9
> ---
>
> Key: SOLR-10235
> URL: https://issues.apache.org/jira/browse/SOLR-10235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: java9
> Attachments: SOLR-10235.patch, SOLR-10235.patch, SOLR-10235.patch, 
> SOLR-10235.patch
>
>
> The way TestJdbcDataSource was converted to use Mockito in SOLR-9966 still 
> left one outstanding test that was incompatible with Java9: 
> {{testRetrieveFromDriverManager()}} 
> The way this test worked with mock classes was also sketchy, but under java9 
> (even with Mockito) the attempt at using class names to resolve things in the 
> standard SQL DriverManager isn't viable.
> It seems like any easy fix is to create _real_ class (with a real/fixed 
> classname) that acts as a wrapper around a mockito "Driver" instance just for 
> the purposes of checking that the DriverManaer related code is working 
> properly.



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

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

[jira] [Resolved] (SOLR-10226) JMX metric avgTimePerRequest broken

[Andrzej Bialecki (JIRA)]

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

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

> JMX metric avgTimePerRequest broken
> ---
>
> Key: SOLR-10226
> URL: https://issues.apache.org/jira/browse/SOLR-10226
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10226.patch, SOLR-10226.patch
>
>
> JMX Metric avgTimePerRequest (of 
> org.apache.solr.handler.component.SearchHandler) doesn't appear to behave 
> correctly anymore. It was a cumulative value in pre-6.4 versions. Since 
> totalTime metric was removed (which was a base for monitoring calculations), 
> avgTimePerRequest seems like possible alternative to calculate "time spent in 
> requests since last measurement", but it behaves strangely after 6.4.
> I did a simple test on gettingstarted collection (just unpacked the Solr 
> 6.4.1 version and started it with "bin/solr start -e cloud -noprompt"). The 
> query I used was:
> http://localhost:8983/solr/gettingstarted/select?indent=on=*:*=json
> I run it 30 times in a row (with approx 1 sec between executions).
> At the same time I was looking (with jconsole) at bean 
> solr/gettingstarted_shard2_replica2:type=/select,id=org.apache.solr.handler.component.SearchHandler
> Here is how metric was changing over time (first number is "requests" metric, 
> second number is "avgTimePerRequest"):
> 10   6.6033
> 12   5.9557
> 13   0.9015---> 13th req would need negative duration if this was 
> cumulative
> 15   6.7315
> 16   7.4873
> 17   0.8458---> same case with 17th request
> 23   6.1076
> At the same time bean 
> solr/gettingstarted_shard1_replica2:type=/select,id=org.apache.solr.handler.component.SearchHandler
>   also showed strange values:
> 65.13482
> 810.5694
> 90.504
> 10  0.344
> 12  8.8121
> 18  3.3531
> CC [~ab]



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

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

[jira] [Commented] (SOLR-10226) JMX metric avgTimePerRequest broken

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10226:


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

SOLR-10226 JMX metric avgTimePerRequest broken.


> JMX metric avgTimePerRequest broken
> ---
>
> Key: SOLR-10226
> URL: https://issues.apache.org/jira/browse/SOLR-10226
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10226.patch, SOLR-10226.patch
>
>
> JMX Metric avgTimePerRequest (of 
> org.apache.solr.handler.component.SearchHandler) doesn't appear to behave 
> correctly anymore. It was a cumulative value in pre-6.4 versions. Since 
> totalTime metric was removed (which was a base for monitoring calculations), 
> avgTimePerRequest seems like possible alternative to calculate "time spent in 
> requests since last measurement", but it behaves strangely after 6.4.
> I did a simple test on gettingstarted collection (just unpacked the Solr 
> 6.4.1 version and started it with "bin/solr start -e cloud -noprompt"). The 
> query I used was:
> http://localhost:8983/solr/gettingstarted/select?indent=on=*:*=json
> I run it 30 times in a row (with approx 1 sec between executions).
> At the same time I was looking (with jconsole) at bean 
> solr/gettingstarted_shard2_replica2:type=/select,id=org.apache.solr.handler.component.SearchHandler
> Here is how metric was changing over time (first number is "requests" metric, 
> second number is "avgTimePerRequest"):
> 10   6.6033
> 12   5.9557
> 13   0.9015---> 13th req would need negative duration if this was 
> cumulative
> 15   6.7315
> 16   7.4873
> 17   0.8458---> same case with 17th request
> 23   6.1076
> At the same time bean 
> solr/gettingstarted_shard1_replica2:type=/select,id=org.apache.solr.handler.component.SearchHandler
>   also showed strange values:
> 65.13482
> 810.5694
> 90.504
> 10  0.344
> 12  8.8121
> 18  3.3531
> CC [~ab]



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

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

[jira] [Commented] (SOLR-10226) JMX metric avgTimePerRequest broken

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10226:


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

SOLR-10226 JMX metric avgTimePerRequest broken.


> JMX metric avgTimePerRequest broken
> ---
>
> Key: SOLR-10226
> URL: https://issues.apache.org/jira/browse/SOLR-10226
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10226.patch, SOLR-10226.patch
>
>
> JMX Metric avgTimePerRequest (of 
> org.apache.solr.handler.component.SearchHandler) doesn't appear to behave 
> correctly anymore. It was a cumulative value in pre-6.4 versions. Since 
> totalTime metric was removed (which was a base for monitoring calculations), 
> avgTimePerRequest seems like possible alternative to calculate "time spent in 
> requests since last measurement", but it behaves strangely after 6.4.
> I did a simple test on gettingstarted collection (just unpacked the Solr 
> 6.4.1 version and started it with "bin/solr start -e cloud -noprompt"). The 
> query I used was:
> http://localhost:8983/solr/gettingstarted/select?indent=on=*:*=json
> I run it 30 times in a row (with approx 1 sec between executions).
> At the same time I was looking (with jconsole) at bean 
> solr/gettingstarted_shard2_replica2:type=/select,id=org.apache.solr.handler.component.SearchHandler
> Here is how metric was changing over time (first number is "requests" metric, 
> second number is "avgTimePerRequest"):
> 10   6.6033
> 12   5.9557
> 13   0.9015---> 13th req would need negative duration if this was 
> cumulative
> 15   6.7315
> 16   7.4873
> 17   0.8458---> same case with 17th request
> 23   6.1076
> At the same time bean 
> solr/gettingstarted_shard1_replica2:type=/select,id=org.apache.solr.handler.component.SearchHandler
>   also showed strange values:
> 65.13482
> 810.5694
> 90.504
> 10  0.344
> 12  8.8121
> 18  3.3531
> CC [~ab]



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

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

[jira] [Commented] (SOLR-10178) TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-10178:


bq. ... Still, I'm unhappy about having to hack this way; ...

I think it would be fair to consider your solution not as a 'hack' but as a 
temporary 'pragmatic solution' since with SOLR-8668 (when we get to it, 
hopefully before and in time for the 7.0.0 release)  the non-factory code paths 
will go away and with it the 'hack' will go away too.

> TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x
> ---
>
> Key: SOLR-10178
> URL: https://issues.apache.org/jira/browse/SOLR-10178
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Fix For: master (7.0), branch_6x
>
>
> TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
> assert in-place updates.
> Towards that, NoMergePolicy is best suited and working fine on master (by 
> defining it using NoMergePolicyFactory).
> This doesn't work with just the MergePolicy 
> (systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
> and doesn't have a constructor. Setting only a NoMergePolicyFactory 
> (systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
> falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
> NoMergePolicy[Factory].
> Here's the corresponding test failure: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19012/
> -Seems to me that SOLR-8668 needs to be backported to branch_6x for this test 
> to work, or some other stopgap hack needs to be put in place to make it work 
> before SOLR-8668 is backported. [~cpoerschke], WDYT?-
> Edit: This is also valid for master. ^



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

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

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

[Apache Jenkins Server]

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

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

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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
SolrCore, 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:347)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:98)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:727)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:912)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:829)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:937)  at 
org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:1308)  at 
org.apache.solr.core.TestCoreDiscovery.testTooManyTransientCores(TestCoreDiscovery.java:211)
  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)

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter

Error Message:
Collection not found: withShardField

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

[jira] [Resolved] (SOLR-10178) TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya resolved SOLR-10178.
-
   Resolution: Fixed
 Assignee: Ishan Chattopadhyaya
Fix Version/s: master (7.0)
   branch_6x

> TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x
> ---
>
> Key: SOLR-10178
> URL: https://issues.apache.org/jira/browse/SOLR-10178
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Fix For: branch_6x, master (7.0)
>
>
> TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
> assert in-place updates.
> Towards that, NoMergePolicy is best suited and working fine on master (by 
> defining it using NoMergePolicyFactory).
> This doesn't work with just the MergePolicy 
> (systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
> and doesn't have a constructor. Setting only a NoMergePolicyFactory 
> (systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
> falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
> NoMergePolicy[Factory].
> Here's the corresponding test failure: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19012/
> -Seems to me that SOLR-8668 needs to be backported to branch_6x for this test 
> to work, or some other stopgap hack needs to be put in place to make it work 
> before SOLR-8668 is backported. [~cpoerschke], WDYT?-
> Edit: This is also valid for master. ^



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

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

[jira] [Updated] (SOLR-10239) MOVEREPLICA API

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-10239:

Issue Type: Sub-task  (was: New Feature)
Parent: SOLR-9735

> MOVEREPLICA API
> ---
>
> Key: SOLR-10239
> URL: https://issues.apache.org/jira/browse/SOLR-10239
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> To move a replica from a node to another node, there should be an API 
> command. This should be better than having to do ADDREPLICA and DELETEREPLICA.



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

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

[jira] [Commented] (SOLR-10178) TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10178:


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

SOLR-10178, SOLR-10079: Force tests to always use NoMergePolicy, also assert 
that it was used


> TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x
> ---
>
> Key: SOLR-10178
> URL: https://issues.apache.org/jira/browse/SOLR-10178
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
> assert in-place updates.
> Towards that, NoMergePolicy is best suited and working fine on master (by 
> defining it using NoMergePolicyFactory).
> This doesn't work with just the MergePolicy 
> (systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
> and doesn't have a constructor. Setting only a NoMergePolicyFactory 
> (systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
> falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
> NoMergePolicy[Factory].
> Here's the corresponding test failure: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19012/
> -Seems to me that SOLR-8668 needs to be backported to branch_6x for this test 
> to work, or some other stopgap hack needs to be put in place to make it work 
> before SOLR-8668 is backported. [~cpoerschke], WDYT?-
> Edit: This is also valid for master. ^



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

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

[jira] [Commented] (SOLR-10079) TestInPlaceUpdates(Distrib|Standalone) failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10079:


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

SOLR-10178, SOLR-10079: Force tests to always use NoMergePolicy, also assert 
that it was used


> TestInPlaceUpdates(Distrib|Standalone) failures
> ---
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10079.patch, stdout
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
> reproduces for me:
> {noformat}
> Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
> -Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 
> 79], now: [78, 78, 78]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:543)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
> id=PostingsFormat(name=Asserting), 
> id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
> docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
> id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
> title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
> id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
>  inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
> inplace_updatable_int=DocValuesFormat(name=Direct), 
> inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=sr-Latn-RS, 
> timezone=America/Grand_Turk
>[junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=12,threads=1,free=107734480,total=518979584
> {noformat}



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

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

[jira] [Created] (SOLR-10239) MOVEREPLICA API

[Ishan Chattopadhyaya (JIRA)]

Ishan Chattopadhyaya created SOLR-10239:
---

 Summary: MOVEREPLICA API
 Key: SOLR-10239
 URL: https://issues.apache.org/jira/browse/SOLR-10239
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Ishan Chattopadhyaya


To move a replica from a node to another node, there should be an API command. 
This should be better than having to do ADDREPLICA and DELETEREPLICA.



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

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

[jira] [Updated] (SOLR-10226) JMX metric avgTimePerRequest broken

[Andrzej Bialecki (JIRA)]

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

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

> JMX metric avgTimePerRequest broken
> ---
>
> Key: SOLR-10226
> URL: https://issues.apache.org/jira/browse/SOLR-10226
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10226.patch, SOLR-10226.patch
>
>
> JMX Metric avgTimePerRequest (of 
> org.apache.solr.handler.component.SearchHandler) doesn't appear to behave 
> correctly anymore. It was a cumulative value in pre-6.4 versions. Since 
> totalTime metric was removed (which was a base for monitoring calculations), 
> avgTimePerRequest seems like possible alternative to calculate "time spent in 
> requests since last measurement", but it behaves strangely after 6.4.
> I did a simple test on gettingstarted collection (just unpacked the Solr 
> 6.4.1 version and started it with "bin/solr start -e cloud -noprompt"). The 
> query I used was:
> http://localhost:8983/solr/gettingstarted/select?indent=on=*:*=json
> I run it 30 times in a row (with approx 1 sec between executions).
> At the same time I was looking (with jconsole) at bean 
> solr/gettingstarted_shard2_replica2:type=/select,id=org.apache.solr.handler.component.SearchHandler
> Here is how metric was changing over time (first number is "requests" metric, 
> second number is "avgTimePerRequest"):
> 10   6.6033
> 12   5.9557
> 13   0.9015---> 13th req would need negative duration if this was 
> cumulative
> 15   6.7315
> 16   7.4873
> 17   0.8458---> same case with 17th request
> 23   6.1076
> At the same time bean 
> solr/gettingstarted_shard1_replica2:type=/select,id=org.apache.solr.handler.component.SearchHandler
>   also showed strange values:
> 65.13482
> 810.5694
> 90.504
> 10  0.344
> 12  8.8121
> 18  3.3531
> CC [~ab]



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

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

[jira] [Commented] (SOLR-10178) TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10178:


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

SOLR-10178, SOLR-10079: Force tests to always use NoMergePolicy, also assert 
that it was used


> TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x
> ---
>
> Key: SOLR-10178
> URL: https://issues.apache.org/jira/browse/SOLR-10178
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
> assert in-place updates.
> Towards that, NoMergePolicy is best suited and working fine on master (by 
> defining it using NoMergePolicyFactory).
> This doesn't work with just the MergePolicy 
> (systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
> and doesn't have a constructor. Setting only a NoMergePolicyFactory 
> (systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
> falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
> NoMergePolicy[Factory].
> Here's the corresponding test failure: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19012/
> -Seems to me that SOLR-8668 needs to be backported to branch_6x for this test 
> to work, or some other stopgap hack needs to be put in place to make it work 
> before SOLR-8668 is backported. [~cpoerschke], WDYT?-
> Edit: This is also valid for master. ^



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

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

[jira] [Commented] (SOLR-10079) TestInPlaceUpdates(Distrib|Standalone) failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10079:


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

SOLR-10178, SOLR-10079: Force tests to always use NoMergePolicy, also assert 
that it was used


> TestInPlaceUpdates(Distrib|Standalone) failures
> ---
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10079.patch, stdout
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
> reproduces for me:
> {noformat}
> Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
> -Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 
> 79], now: [78, 78, 78]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:543)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
> id=PostingsFormat(name=Asserting), 
> id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
> docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
> id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
> title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
> id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
>  inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
> inplace_updatable_int=DocValuesFormat(name=Direct), 
> inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=sr-Latn-RS, 
> timezone=America/Grand_Turk
>[junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=12,threads=1,free=107734480,total=518979584
> {noformat}



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

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

[jira] [Updated] (SOLR-10226) JMX metric avgTimePerRequest broken

[Andrzej Bialecki (JIRA)]

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

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

Fixed totalTime conversion so that it's expressed in ms. If there are no 
objections I'll commit this shortly.

> JMX metric avgTimePerRequest broken
> ---
>
> Key: SOLR-10226
> URL: https://issues.apache.org/jira/browse/SOLR-10226
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
> Attachments: SOLR-10226.patch, SOLR-10226.patch
>
>
> JMX Metric avgTimePerRequest (of 
> org.apache.solr.handler.component.SearchHandler) doesn't appear to behave 
> correctly anymore. It was a cumulative value in pre-6.4 versions. Since 
> totalTime metric was removed (which was a base for monitoring calculations), 
> avgTimePerRequest seems like possible alternative to calculate "time spent in 
> requests since last measurement", but it behaves strangely after 6.4.
> I did a simple test on gettingstarted collection (just unpacked the Solr 
> 6.4.1 version and started it with "bin/solr start -e cloud -noprompt"). The 
> query I used was:
> http://localhost:8983/solr/gettingstarted/select?indent=on=*:*=json
> I run it 30 times in a row (with approx 1 sec between executions).
> At the same time I was looking (with jconsole) at bean 
> solr/gettingstarted_shard2_replica2:type=/select,id=org.apache.solr.handler.component.SearchHandler
> Here is how metric was changing over time (first number is "requests" metric, 
> second number is "avgTimePerRequest"):
> 10   6.6033
> 12   5.9557
> 13   0.9015---> 13th req would need negative duration if this was 
> cumulative
> 15   6.7315
> 16   7.4873
> 17   0.8458---> same case with 17th request
> 23   6.1076
> At the same time bean 
> solr/gettingstarted_shard1_replica2:type=/select,id=org.apache.solr.handler.component.SearchHandler
>   also showed strange values:
> 65.13482
> 810.5694
> 90.504
> 10  0.344
> 12  8.8121
> 18  3.3531
> CC [~ab]



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

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

[jira] [Comment Edited] (SOLR-10178) TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-10178 at 3/7/17 1:27 PM:
-

Indeed, this was same as in master as well.

I realized that the following would always use a MergePolicyFactory:

{code}

systemSetPropertySolrTestsMergePolicyFactory(NoMergePolicyFactory.class.getName());
System.setProperty(SYSTEM_PROPERTY_SOLR_TESTS_USEMERGEPOLICYFACTORY, 
"true");
System.setProperty(SYSTEM_PROPERTY_SOLR_TESTS_USEMERGEPOLICY, "false");
{code}

It seems that doing this is the only way to always use the 
NoMergePolicyFactory, since we cannot use NoMergePolicy. This hack is at least 
better than "skip the troublesome code" using assumeFalse. Still, I'm unhappy 
about having to hack this way; but unfortunately, I don't have time to dive 
deeper right now.


was (Author: ichattopadhyaya):
Indeed, this was same as in master as well.

I realized that the following would always use a MergePolicyFactory:

{code}

systemSetPropertySolrTestsMergePolicyFactory(NoMergePolicyFactory.class.getName());
System.setProperty(SYSTEM_PROPERTY_SOLR_TESTS_USEMERGEPOLICYFACTORY, 
"true");
System.setProperty(SYSTEM_PROPERTY_SOLR_TESTS_USEMERGEPOLICY, "false");
{code}

It seems that doing this is the only way to always use the 
NoMergePolicyFactory, since we cannot use NoMergePolicy.

> TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x
> ---
>
> Key: SOLR-10178
> URL: https://issues.apache.org/jira/browse/SOLR-10178
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
> assert in-place updates.
> Towards that, NoMergePolicy is best suited and working fine on master (by 
> defining it using NoMergePolicyFactory).
> This doesn't work with just the MergePolicy 
> (systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
> and doesn't have a constructor. Setting only a NoMergePolicyFactory 
> (systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
> falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
> NoMergePolicy[Factory].
> Here's the corresponding test failure: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19012/
> -Seems to me that SOLR-8668 needs to be backported to branch_6x for this test 
> to work, or some other stopgap hack needs to be put in place to make it work 
> before SOLR-8668 is backported. [~cpoerschke], WDYT?-
> Edit: This is also valid for master. ^



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

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

[jira] [Updated] (SOLR-10178) TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-10178:

Description: 
TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
assert in-place updates.

Towards that, NoMergePolicy is best suited and working fine on master (by 
defining it using NoMergePolicyFactory).

This doesn't work with just the MergePolicy 
(systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
and doesn't have a constructor. Setting only a NoMergePolicyFactory 
(systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
NoMergePolicy[Factory].

Here's the corresponding test failure: 
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19012/

-Seems to me that SOLR-8668 needs to be backported to branch_6x for this test 
to work, or some other stopgap hack needs to be put in place to make it work 
before SOLR-8668 is backported. [~cpoerschke], WDYT?-
Edit: This is also valid for master. ^

  was:
TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
assert in-place updates.

Towards that, NoMergePolicy is best suited and working fine on master (by 
defining it using NoMergePolicyFactory).

This doesn't work with just the MergePolicy 
(systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
and doesn't have a constructor. Setting only a NoMergePolicyFactory 
(systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
NoMergePolicy[Factory].

Here's the corresponding test failure: 
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19012/

Seems to me that SOLR-8668 needs to be backported to branch_6x for this test to 
work, or some other stopgap hack needs to be put in place to make it work 
before SOLR-8668 is backported. [~cpoerschke], WDYT?


> TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x
> ---
>
> Key: SOLR-10178
> URL: https://issues.apache.org/jira/browse/SOLR-10178
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
> assert in-place updates.
> Towards that, NoMergePolicy is best suited and working fine on master (by 
> defining it using NoMergePolicyFactory).
> This doesn't work with just the MergePolicy 
> (systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
> and doesn't have a constructor. Setting only a NoMergePolicyFactory 
> (systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
> falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
> NoMergePolicy[Factory].
> Here's the corresponding test failure: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19012/
> -Seems to me that SOLR-8668 needs to be backported to branch_6x for this test 
> to work, or some other stopgap hack needs to be put in place to make it work 
> before SOLR-8668 is backported. [~cpoerschke], WDYT?-
> Edit: This is also valid for master. ^



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

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

[jira] [Updated] (SOLR-9858) Collect aggregated metrics from nodes and shard leaders in overseer

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-9858:

Attachment: SOLR-9858.patch

Final patch. This fixes all issues pointed out in the last review. If there are 
no objections I'd like to commit this shortly.

> Collect aggregated metrics from nodes and shard leaders in overseer
> ---
>
> Key: SOLR-9858
> URL: https://issues.apache.org/jira/browse/SOLR-9858
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: master (7.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Attachments: SOLR-9858.patch, SOLR-9858.patch, SOLR-9858.patch
>
>
> Overseer can collect metrics from Solr nodes and shard leaders in order to 
> have a notion of the indexing / query / replication / system load on each 
> node, shard and its replicas. This information then can be used for cluster 
> (auto)scaling.



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

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

[jira] [Commented] (SOLR-10178) TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10178:
-

Indeed, this was same as in master as well.

I realized that the following would always use a MergePolicyFactory:

{code}

systemSetPropertySolrTestsMergePolicyFactory(NoMergePolicyFactory.class.getName());
System.setProperty(SYSTEM_PROPERTY_SOLR_TESTS_USEMERGEPOLICYFACTORY, 
"true");
System.setProperty(SYSTEM_PROPERTY_SOLR_TESTS_USEMERGEPOLICY, "false");
{code}

It seems that doing this is the only way to always use the 
NoMergePolicyFactory, since we cannot use NoMergePolicy.

> TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x
> ---
>
> Key: SOLR-10178
> URL: https://issues.apache.org/jira/browse/SOLR-10178
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
> assert in-place updates.
> Towards that, NoMergePolicy is best suited and working fine on master (by 
> defining it using NoMergePolicyFactory).
> This doesn't work with just the MergePolicy 
> (systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
> and doesn't have a constructor. Setting only a NoMergePolicyFactory 
> (systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
> falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
> NoMergePolicy[Factory].
> Here's the corresponding test failure: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19012/
> Seems to me that SOLR-8668 needs to be backported to branch_6x for this test 
> to work, or some other stopgap hack needs to be put in place to make it work 
> before SOLR-8668 is backported. [~cpoerschke], WDYT?



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

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

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 719 - Failure

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 39744 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 260 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (21.9 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 30.6 MB in 0.03 sec (1151.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 65.0 MB in 0.06 sec (1148.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 75.4 MB in 0.07 sec (1138.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6206 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6206 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 214 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   6.4.2
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1474, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1418, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1456, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, gitRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 622, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
gitRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 768, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1394, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

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

Total time: 39 minutes 1 second
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any




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

[jira] [Commented] (SOLR-10079) TestInPlaceUpdates(Distrib|Standalone) failures

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10079:
-

Found another reproducible failure on master (for TestInPlaceUpdatesStandalone):
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6436/

{code}
Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([E5327FD412D6687F:3342A273798B1629]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.update.TestInPlaceUpdatesStandalone.testUpdatingDocValues(TestInPlaceUpdatesStandalone.java:191)
{code}

> TestInPlaceUpdates(Distrib|Standalone) failures
> ---
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10079.patch, stdout
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
> reproduces for me:
> {noformat}
> Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
> -Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 
> 79], now: [78, 78, 78]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:543)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
> id=PostingsFormat(name=Asserting), 
> id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
> docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
> id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
> title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
> id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
>  inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
> inplace_updatable_int=DocValuesFormat(name=Direct), 
> inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=sr-Latn-RS, 
> timezone=America/Grand_Turk
>[junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=12,threads=1,free=107734480,total=518979584
> {noformat}



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

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

[jira] [Updated] (SOLR-10079) TestInPlaceUpdates(Distrib|Standalone) failures

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-10079:

Summary: TestInPlaceUpdates(Distrib|Standalone) failures  (was: 
TestInPlaceUpdatesDistrib failure)

> TestInPlaceUpdates(Distrib|Standalone) failures
> ---
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10079.patch, stdout
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
> reproduces for me:
> {noformat}
> Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
> -Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 
> 79], now: [78, 78, 78]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:543)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
> id=PostingsFormat(name=Asserting), 
> id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
> docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
> id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
> title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
> id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
>  inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
> inplace_updatable_int=DocValuesFormat(name=Direct), 
> inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=sr-Latn-RS, 
> timezone=America/Grand_Turk
>[junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=12,threads=1,free=107734480,total=518979584
> {noformat}



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

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

[jira] [Resolved] (LUCENE-7712) SimpleQueryString should support auto fuziness

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-7712.

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

Thank you [~dadoonet] and [~dakrone]!

> SimpleQueryString should support auto fuziness
> --
>
> Key: LUCENE-7712
> URL: https://issues.apache.org/jira/browse/LUCENE-7712
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: David Pilato
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7712.patch
>
>
> Apparently the simpleQueryString query does not support auto fuziness as the 
> query string does.
> So {{foo:bar~1}} works for both simple query string and query string queries.
> But {{foo:bar~}} works for query string query but not for simple query string 
> query.



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

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

[jira] [Commented] (LUCENE-7712) SimpleQueryString should support auto fuziness

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7712: SimpleQueryParser now parses foo~ as foo~2


> SimpleQueryString should support auto fuziness
> --
>
> Key: LUCENE-7712
> URL: https://issues.apache.org/jira/browse/LUCENE-7712
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: David Pilato
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7712.patch
>
>
> Apparently the simpleQueryString query does not support auto fuziness as the 
> query string does.
> So {{foo:bar~1}} works for both simple query string and query string queries.
> But {{foo:bar~}} works for query string query but not for simple query string 
> query.



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

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

[jira] [Commented] (LUCENE-7712) SimpleQueryString should support auto fuziness

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7712: SimpleQueryParser now parses foo~ as foo~2


> SimpleQueryString should support auto fuziness
> --
>
> Key: LUCENE-7712
> URL: https://issues.apache.org/jira/browse/LUCENE-7712
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: David Pilato
> Attachments: LUCENE-7712.patch
>
>
> Apparently the simpleQueryString query does not support auto fuziness as the 
> query string does.
> So {{foo:bar~1}} works for both simple query string and query string queries.
> But {{foo:bar~}} works for query string query but not for simple query string 
> query.



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

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

[jira] [Updated] (SOLR-10105) JDBCStream should be able to load driver from runtime lib

[Noble Paul (JIRA)]

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

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

untested patch. PoC

> JDBCStream should be able to load driver from runtime lib
> -
>
> Key: SOLR-10105
> URL: https://issues.apache.org/jira/browse/SOLR-10105
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Reporter: Noble Paul
>Assignee: Kevin Risden
>Priority: Minor
> Attachments: SOLR-10105.patch
>
>
> Currently the JDBCStream uses Class.forName() to load the driver class. This 
> should be improved to try to use the classloader from runtimeLib and the blob 
> store API like SOLR-10087. It may be possible to do something like 
> Class.forName(driverClassName, true, core.getMemClassLoader()) just need to 
> figure out how to get a reference to the core.
> The relevant code is here:
> https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/JDBCStream.java#L180



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

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

[JENKINS] Lucene-Solr-SmokeRelease-6.4 - Build # 20 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.4/20/

No tests ran.

Build Log:
[...truncated 41914 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 260 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (25.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.4.2-src.tgz...
   [smoker] 30.6 MB in 0.03 sec (1157.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.4.2.tgz...
   [smoker] 65.0 MB in 0.06 sec (1105.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.4.2.zip...
   [smoker] 75.3 MB in 0.07 sec (1140.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.4.2.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6206 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.4.2.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6206 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.4.2-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 229 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker]   Backcompat testing not required for release 6.4.2 because 
it's not less than 6.4.2
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (53.5 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.4.2-src.tgz...
   [smoker] 40.2 MB in 0.56 sec (71.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.4.2.tgz...
   [smoker] 140.3 MB in 1.24 sec (113.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.4.2.zip...
   [smoker] 149.4 MB in 0.14 sec (1059.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.4.2.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.4.2.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/tmp/unpack/solr-6.4.2/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/tmp/unpack/solr-6.4.2/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/tmp/unpack/solr-6.4.2-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/tmp/unpack/solr-6.4.2-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/tmp/unpack/solr-6.4.2-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] 

[jira] [Commented] (LUCENE-7712) SimpleQueryString should support auto fuziness

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7712:


Thanks [~dakrone], patch looks good; I'll push shortly!

> SimpleQueryString should support auto fuziness
> --
>
> Key: LUCENE-7712
> URL: https://issues.apache.org/jira/browse/LUCENE-7712
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: David Pilato
> Attachments: LUCENE-7712.patch
>
>
> Apparently the simpleQueryString query does not support auto fuziness as the 
> query string does.
> So {{foo:bar~1}} works for both simple query string and query string queries.
> But {{foo:bar~}} works for query string query but not for simple query string 
> query.



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

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