[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_144) - Build # 982 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/982/ Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseG1GC 3 tests failed. FAILED: org.apache.solr.cloud.AssignBackwardCompatibilityTest.test Error Message: Error from server at https://127.0.0.1:34545/solr: Timed out waiting to see all replicas: [collection1_shard1_replica_n125] in cluster state. Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:34545/solr: Timed out waiting to see all replicas: [collection1_shard1_replica_n125] in cluster state. at __randomizedtesting.SeedInfo.seed([DAD8A6FF14496977:528C9925BAB5048F]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.AssignBackwardCompatibilityTest.test(AssignBackwardCompatibilityTest.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAda
[JENKINS] Lucene-Solr-Tests-7.x - Build # 282 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/282/ 8 tests failed. FAILED: org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove Error Message: No live SolrServers available to handle this request:[http://127.0.0.1:58252/solr/MoveReplicaHDFSTest_failed_coll_true, http://127.0.0.1:39345/solr/MoveReplicaHDFSTest_failed_coll_true] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:58252/solr/MoveReplicaHDFSTest_failed_coll_true, http://127.0.0.1:39345/solr/MoveReplicaHDFSTest_failed_coll_true] at __randomizedtesting.SeedInfo.seed([8B8AF53679C43555:214726C4CE17E085]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:990) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942) at org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:306) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at 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.Tes
[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 334 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/334/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testTriggerThrottling Error Message: Both triggers should have fired by now Stack Trace: java.lang.AssertionError: Both triggers should have fired by now at __randomizedtesting.SeedInfo.seed([A9D0B4C71D2DF79A:52F21CE2CF871408]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testTriggerThrottling(TriggerIntegrationTest.java:255) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 13514 lines...] [junit4] Suite: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest [junit4] 2> 3215829 INFO (SUITE-TriggerIntegrationTest-seed#[A9D0B4C71D2DF79A]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed
[JENKINS] Lucene-Solr-7.2-Linux (32bit/jdk1.8.0_144) - Build # 54 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Linux/54/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseConcMarkSweepGC 3 tests failed. FAILED: org.apache.solr.cloud.ShardSplitTest.test Error Message: Error from server at http://127.0.0.1:40973/bcfj: Could not fully create collection: splitByRouteKeyTest Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:40973/bcfj: Could not fully create collection: splitByRouteKeyTest at __randomizedtesting.SeedInfo.seed([9C3F8A754D094DD5:146BB5AFE3F5202D]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1668) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1607) at org.apache.solr.cloud.ShardSplitTest.splitByRouteKeyTest(ShardSplitTest.java:751) at org.apache.solr.cloud.ShardSplitTest.test(ShardSplitTest.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.
[jira] [Updated] (SOLR-11391) JoinQParser for non point fields should use the GraphTermsCollector
[ https://issues.apache.org/jira/browse/SOLR-11391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-11391: - Attachment: SOLR-11391.patch A WIP addressing some of the feedback from Hoss. I found a few spare hours so I worked on this. I plan on spending a couple of days towards the end of the year addressing all the feedback > JoinQParser for non point fields should use the GraphTermsCollector > > > Key: SOLR-11391 > URL: https://issues.apache.org/jira/browse/SOLR-11391 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker > Attachments: SOLR-11391.patch, SOLR-11391.patch, SOLR-11391.patch, > SOLR-11391.patch, SOLR-11391.patch, SOLR-11391.patch, SOLR-11391.patch, > SOLR-11391.patch, SOLR-11391.patch, SOLR-11391.patch > > > The Join Query Parser uses the GraphPointsCollector for point fields. > For non point fields if we use the GraphTermsCollector instead of the current > algorithm I am seeing quite a bit of performance gains. > I'm going to attach a quick patch which I cooked up , making sure TestJoin > and TestCloudJSONFacetJoinDomain passed. > More tests, benchmarking and code cleanup to follow -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11756) FilteredQuery in 5.5.4 needs scorer loop much more than 4.4.7
Yan Zhao created SOLR-11756: --- Summary: FilteredQuery in 5.5.4 needs scorer loop much more than 4.4.7 Key: SOLR-11756 URL: https://issues.apache.org/jira/browse/SOLR-11756 Project: Solr Issue Type: Bug Components: search Affects Versions: 5.5.4 Reporter: Yan Zhao In Solr 5.5.4, FilteredQuery no longer has the LeapFrogScorer as in Solr 4.7. And the whole query is rewritten into a BooleanQuery. As for query, if main query is like "name:zoo" which hits 10k docs in index but filterquery like "location:NewYork" helped to filter the resultset to 5 docs. And in final, the loop name:zoo set is maximum to 5 times as the filter is there. But in 5.5.4, we are seeing the name:zoo needs to loop 10k docs at first then join with the filter set. In our environment, the filter doesn't changed too much so FilterQuery cache can helped in performance. But keyword might changes, so the whole QueryResult cache is not helping in this case. This significantly increase the CPU cost for keyword search since we ran the profiling of the same query for these two versions. Is it possible to have the LeapFrogScorer back? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8086) G3d wrapper: Improve circles for non spherical planets
[
https://issues.apache.org/jira/browse/LUCENE-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288713#comment-16288713
]
David Smiley commented on LUCENE-8086:
--
BTW [~ivera] my tentative CHANGES.txt note for this issue is this:
{noformat}
* LUCENE-8086: spatial-extras Geo3dFactory: Use GeoExactCircle with
configurable precision for non-spherical planet models.
(Ignacio Vera via David Smiley)
{noformat}
Yeah I know there's more going on but I think that's essentially it from a user
perspective. It's common for issues to include various internal refactorings
but need not mention in CHANGES.txt.
> G3d wrapper: Improve circles for non spherical planets
> --
>
> Key: LUCENE-8086
> URL: https://issues.apache.org/jira/browse/LUCENE-8086
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
>Reporter: Ignacio Vera
>
> Hi [~dsmiley],
> The purpose of this ticket is to add a new circle shape (GeoExactCircle) for
> non-spherical planets and therefore remove the method relate from
> Geo3dCircleShape. The patch will include some simplifications on the wrapper
> and some refactoring of the tests.
> I will open shortly a pull request.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8086) G3d wrapper: Improve circles for non spherical planets
[ https://issues.apache.org/jira/browse/LUCENE-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288706#comment-16288706 ] David Smiley commented on LUCENE-8086: -- [~daddywri] and [~ivera] I'm looking at GeoCircleFactory and GeoStandardCircle and GeoExactCircle. Try to put yourself into a user's shoes who has no idea which to choose. Note that both circles have the same class javadocs (albeit not "public"). Also note that both factory methods on GeoCircleFactory look similar. So I've been following these issues loosely and have some vague idea of what's going on. I think it's weird that GeoExactCircle is named as such which, by it's name, might suggest (to me) that any other circle isn't "exact". Yet AFAICT this isn't true and in fact is the opposite! GeoStandardCircle is accurate in spherical, and GeoExactCircle, despite it's name, is an approximation with configurable error for non-spherical. Sure some more/better javadocs would help but I have to wonder if we need to express the distinction publicly. That is... if the PlanetModel passed is a sphere, then use GeoStandardCircle, and if it isn't, use GeoExactCircle. Essentially with this I'm suggesting moving the change in this patch in Geo3dShapeFactory (Spatial4j abstraction) to GeoCircleFactory (down a layer of abstraction). WDYT? > G3d wrapper: Improve circles for non spherical planets > -- > > Key: LUCENE-8086 > URL: https://issues.apache.org/jira/browse/LUCENE-8086 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera > > Hi [~dsmiley], > The purpose of this ticket is to add a new circle shape (GeoExactCircle) for > non-spherical planets and therefore remove the method relate from > Geo3dCircleShape. The patch will include some simplifications on the wrapper > and some refactoring of the tests. > I will open shortly a pull request. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 2219 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2219/ 3 tests failed. FAILED: org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testReadApi Error Message: expected:<1> but was:<0> Stack Trace: java.lang.AssertionError: expected:<1> but was:<0> at __randomizedtesting.SeedInfo.seed([17139275D7534F06:403A69C00CA1AD1D]: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.cloud.autoscaling.AutoScalingHandlerTest.testReadApi(AutoScalingHandlerTest.java:724) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue Error Message: action wasn't interrupted Stack Trace: java.lang.AssertionError: action wa
[jira] [Commented] (SOLR-11746) numeric fields need better error handling for prefix/wildcard syntax -- consider uniform support for "foo:* == foo:[* TO *]"
[
https://issues.apache.org/jira/browse/SOLR-11746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288675#comment-16288675
]
Yonik Seeley commented on SOLR-11746:
-
IMO it should count as a bug that numeric_field:* doesn't work.
The fact that it does work with trie fields may have originally been a fluke,
but I would have added it if it hadn't worked (didn't realize there were no
tests for it...)
> numeric fields need better error handling for prefix/wildcard syntax --
> consider uniform support for "foo:* == foo:[* TO *]"
>
>
> Key: SOLR-11746
> URL: https://issues.apache.org/jira/browse/SOLR-11746
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>
> On the solr-user mailing list, Torsten Krah pointed out that with Trie
> numeric fields, query syntax such as {{foo_d:\*}} has been functionality
> equivilent to {{foo_d:\[\* TO \*]}} and asked why this was not also supported
> for Point based numeric fields.
> The fact that this type of syntax works (for {{indexed="true"}} Trie fields)
> appears to have been an (untested, undocumented) fluke of Trie fields given
> that they use indexed terms for the (encoded) numeric terms and inherit the
> default implementation of {{FieldType.getPrefixQuery}} which produces a
> prefix query against the {{""}} (empty string) term.
> (Note that this syntax has aparently _*never*_ worked for Trie fields with
> {{indexed="false" docValues="true"}} )
> In general, we should assess the behavior users attempt a prefix/wildcard
> syntax query against numeric fields, as currently the behavior is largely
> non-sensical: prefix/wildcard syntax frequently match no docs w/o any sort
> of error, and the aformentioned {{numeric_field:*}} behaves inconsistently
> between points/trie fields and between indexed/docValued trie fields.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11754) Remove AbstractSolrTestCase
[ https://issues.apache.org/jira/browse/SOLR-11754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288668#comment-16288668 ] Yonik Seeley commented on SOLR-11754: - Yep, seems fine to me. > Remove AbstractSolrTestCase > --- > > Key: SOLR-11754 > URL: https://issues.apache.org/jira/browse/SOLR-11754 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: David Smiley >Assignee: David Smiley > > I'm arguing AbstractSolrTestCase should be removed as it's obsoleted by > SolrTestCaseJ4. > In SOLR-3911 (back in 2012) Mark made it extend from SolrTestCaseJ4. There > is really very little in this test class. Some of the methods here are > duplicated by SolrTestCaseJ4 and thus are completely redundant > (ignoreException, resetExceptionIgnores, getFile). There haven't been any > modifications to this class of substance since 2012 either. > I think we can just outright remove it (no deprecation phase). Anyone still > using it can trivially switch. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11754) Remove AbstractSolrTestCase
[ https://issues.apache.org/jira/browse/SOLR-11754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288596#comment-16288596 ] David Smiley commented on SOLR-11754: - I believe ASTC is mostly of historical use but was replaced by SolrTestCaseJ4 but we didn't actually remove the old abstraction. [~yo...@apache.org] you added SolrTestCaseJ4 in SOLR-1835, although at the time AbstractSolrTestCase was still independent. Do you agree it's time to remove ASTC? > Remove AbstractSolrTestCase > --- > > Key: SOLR-11754 > URL: https://issues.apache.org/jira/browse/SOLR-11754 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: David Smiley >Assignee: David Smiley > > I'm arguing AbstractSolrTestCase should be removed as it's obsoleted by > SolrTestCaseJ4. > In SOLR-3911 (back in 2012) Mark made it extend from SolrTestCaseJ4. There > is really very little in this test class. Some of the methods here are > duplicated by SolrTestCaseJ4 and thus are completely redundant > (ignoreException, resetExceptionIgnores, getFile). There haven't been any > modifications to this class of substance since 2012 either. > I think we can just outright remove it (no deprecation phase). Anyone still > using it can trivially switch. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.2-Linux (64bit/jdk1.8.0_144) - Build # 53 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Linux/53/ Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:46735 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:46735 at __randomizedtesting.SeedInfo.seed([DF20125B23F9C11:1E91334A835025B7]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:314) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRul
[jira] [Created] (SOLR-11755) Make V2Request constructor public
Anshum Gupta created SOLR-11755: --- Summary: Make V2Request constructor public Key: SOLR-11755 URL: https://issues.apache.org/jira/browse/SOLR-11755 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Anshum Gupta Assignee: Anshum Gupta V2Request has a private constructor that stops it from being extended. We need to change the visibility for that constructor to protected or move the shared methods out of that class into a common place so that SolrJ support could be added for new V2 APIs. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4325 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4325/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 3 tests failed. FAILED: org.apache.solr.core.TestLazyCores.testNoCommit Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([18DC44E3C3F87C55:C7BCE53208DF1FF0]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:901) at org.apache.solr.core.TestLazyCores.check10(TestLazyCores.java:855) at org.apache.solr.core.TestLazyCores.testNoCommit(TestLazyCores.java:832) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound='10'] xml response was: 00*:* request was:q=*:* at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:894) ... 41 more FAILED: junit.framework.TestSuite.org.
[jira] [Commented] (LUCENE-8084) FSTs can be very space-inefficient on array-expanded nodes
[ https://issues.apache.org/jira/browse/LUCENE-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288549#comment-16288549 ] Michael McCandless commented on LUCENE-8084: I like that idea! Maybe in the meantime we should improve the logic that decides if an node should use the dense encoding to take into account waste due to large outputs? > FSTs can be very space-inefficient on array-expanded nodes > -- > > Key: LUCENE-8084 > URL: https://issues.apache.org/jira/browse/LUCENE-8084 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Dawid Weiss >Priority: Minor > Attachments: capture-4.png > > > We have FSTs which operate on a larger alphabet (keys in int) space and emit > character sequence outputs. I noticed that certain nodes get expanded into > fixed-size arrays to accelerate lookups (binary search). This has a potential > problem, however, when the outputs emit larger blobs of data (say, one of the > outputs is very long, all the others are small). Then the fixed-size array is > very much overallocated, as evident on the attached picture. > I wonder if it'd be better to encode the array as fixed-size, but without the > outputs and use a local fixed-size pointer into a "value pool" somewhere next > to the node's arcs. Theoretically this "value pool" could even be shared by > all of automaton's nodes (saved once at the end or flushed periodically). > Just a thought. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #286: [LUCENE-8075] Possible null pointer dereferen...
Github user mikemccand commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/286#discussion_r156538059
--- Diff:
lucene/core/src/java/org/apache/lucene/codecs/blocktree/IntersectTermsEnum.java
---
@@ -106,37 +106,37 @@ public IntersectTermsEnum(FieldReader fr, Automaton
automaton, RunAutomaton runA
if (fr.index == null) {
fstReader = null;
--- End diff --
Sorry for the slow respons ehere @imgpulak and @jpountz but Adrien is
right: `fr.index` can never be null anymore. So I think we should change the
code to `assert` it's never null and only do the `else` clause of the current
`if` statement?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8075) Possible null pointer dereference in core/src/java/org/apache/lucene/codecs/blocktree/IntersectTermsEnum.java
[
https://issues.apache.org/jira/browse/LUCENE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288541#comment-16288541
]
ASF GitHub Bot commented on LUCENE-8075:
Github user mikemccand commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/286#discussion_r156538059
--- Diff:
lucene/core/src/java/org/apache/lucene/codecs/blocktree/IntersectTermsEnum.java
---
@@ -106,37 +106,37 @@ public IntersectTermsEnum(FieldReader fr, Automaton
automaton, RunAutomaton runA
if (fr.index == null) {
fstReader = null;
--- End diff --
Sorry for the slow respons ehere @imgpulak and @jpountz but Adrien is
right: `fr.index` can never be null anymore. So I think we should change the
code to `assert` it's never null and only do the `else` clause of the current
`if` statement?
> Possible null pointer dereference in
> core/src/java/org/apache/lucene/codecs/blocktree/IntersectTermsEnum.java
> -
>
> Key: LUCENE-8075
> URL: https://issues.apache.org/jira/browse/LUCENE-8075
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/codecs
>Affects Versions: 7.1
>Reporter: Xiaoshan Sun
> Labels: easyfix
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> Possible null pointer dereference in
> core/src/java/org/apache/lucene/codecs/blocktree/IntersectTermsEnum.java.
> at line 119. The fr.index may be NULL. This result is based on static
> analysis tools and the details are shown below:
> *
> {code:java}
> 106: if (fr.index == null) {
> 107: fstReader = null; // fr.index is Known NULL here.
> } else {
> fstReader = fr.index.getBytesReader();
> }
> // TODO: if the automaton is "smallish" we really
> // should use the terms index to seek at least to
> // the initial term and likely to subsequent terms
> // (or, maybe just fallback to ATE for such cases).
> // Else the seek cost of loading the frames will be
> // too costly.
> 119:final FST.Arc arc = fr.index.getFirstArc(arcs[0]);
> // fr.index is dereferenced here and fr.index can be NULL if 107 is arrived.
> {code}
> *
> It is not sure if fr.index can be NULL in runtime.
> We think it is reasonable to fix it by a test if fr.index is NULL and an
> error handling.
> --
> Please Refer to "Trusted Operating System and System Assurance Working Group,
> TCA, Institute of Software, Chinese Academy of Sciences" in the
> acknowledgement if applicable.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Ishan Chattopadhyaya to the PMC
Congrats, Ishan! On Wed, Dec 13, 2017 at 9:26 AM Michael McCandless < luc...@mikemccandless.com> wrote: > Welcome Ishan! > > Mike McCandless > > http://blog.mikemccandless.com > > On Fri, Dec 8, 2017 at 8:47 AM, Adrien Grand wrote: > >> I am pleased to announce that Ishan Chattopadhyaya has accepted the PMC's >> invitation to join. >> >> Welcome Ishan! >> > >
Re: Welcome Ishan Chattopadhyaya to the PMC
Welcome Ishan! Mike McCandless http://blog.mikemccandless.com On Fri, Dec 8, 2017 at 8:47 AM, Adrien Grand wrote: > I am pleased to announce that Ishan Chattopadhyaya has accepted the PMC's > invitation to join. > > Welcome Ishan! >
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+32) - Build # 21075 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21075/
Java: 64bit/jdk-10-ea+32 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
3 tests failed.
FAILED: junit.framework.TestSuite.org.apache.solr.ltr.TestLTROnSolrCloud
Error Message:
123 threads leaked from SUITE scope at org.apache.solr.ltr.TestLTROnSolrCloud:
1) Thread[id=67,
name=qtp307693992-67-acceptor-0@1d4b8b6c-ServerConnector@646bc0c{SSL,[ssl,
http/1.1]}{127.0.0.1:32837}, state=RUNNABLE, group=TGRP-TestLTROnSolrCloud]
at java.base@10-ea/sun.nio.ch.ServerSocketChannelImpl.accept0(Native
Method) at
java.base@10-ea/sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:424)
at
java.base@10-ea/sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:252)
at
app//org.eclipse.jetty.server.ServerConnector.accept(ServerConnector.java:371)
at
app//org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:601)
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@10-ea/java.lang.Thread.run(Thread.java:844)2)
Thread[id=186,
name=TEST-TestLTROnSolrCloud.testSimpleQuery-seed#[27A5628F1A1F6128]-SendThread(127.0.0.1:37153),
state=RUNNABLE, group=TGRP-TestLTROnSolrCloud] at
java.base@10-ea/sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at
java.base@10-ea/sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:265)
at
java.base@10-ea/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:92)
at
java.base@10-ea/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:89)
at java.base@10-ea/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:100)
at
app//org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:349)
at
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1141)3)
Thread[id=173, name=Thread-53, state=WAITING, group=TGRP-TestLTROnSolrCloud]
at java.base@10-ea/java.lang.Object.wait(Native Method) at
java.base@10-ea/java.lang.Object.wait(Object.java:328) at
app//org.apache.solr.core.CloserThread.run(CoreContainer.java:1723)4)
Thread[id=22, name=ProcessThread(sid:0 cport:37153):, state=WAITING,
group=TGRP-TestLTROnSolrCloud] at
java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at
java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at
java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074)
at
java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
at
app//org.apache.zookeeper.server.PrepRequestProcessor.run(PrepRequestProcessor.java:122)
5) Thread[id=68, name=qtp307693992-68, state=RUNNABLE,
group=TGRP-TestLTROnSolrCloud] at
java.base@10-ea/sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at
java.base@10-ea/sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:265)
at
java.base@10-ea/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:92)
at
java.base@10-ea/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:89)
at java.base@10-ea/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:100)
at java.base@10-ea/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:104)
at
app//org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:243)
at
app//org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:191)
at
app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:249)
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@10-ea/java.lang.Thread.run(Thread.java:844)6)
Thread[id=57, name=qtp317184813-57, state=RUNNABLE,
group=TGRP-TestLTROnSolrCloud] at
java.base@10-ea/sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at
java.base@10-ea/sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:265)
at
java.base@10-ea/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:92)
at
java.base@10-ea/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:89)
at java.base@10-ea/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:100)
at java.base@10-ea/sun.
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.1) - Build # 341 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/341/ Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 6 tests failed. FAILED: junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterThreadsToSegments Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestIndexWriterThreadsToSegments_BDC8A523FC5300FA-001\tempDir-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestIndexWriterThreadsToSegments_BDC8A523FC5300FA-001\tempDir-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestIndexWriterThreadsToSegments_BDC8A523FC5300FA-001\tempDir-001\segments_1: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestIndexWriterThreadsToSegments_BDC8A523FC5300FA-001\tempDir-001\segments_1 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestIndexWriterThreadsToSegments_BDC8A523FC5300FA-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestIndexWriterThreadsToSegments_BDC8A523FC5300FA-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestIndexWriterThreadsToSegments_BDC8A523FC5300FA-001\tempDir-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestIndexWriterThreadsToSegments_BDC8A523FC5300FA-001\tempDir-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestIndexWriterThreadsToSegments_BDC8A523FC5300FA-001\tempDir-001\segments_1: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestIndexWriterThreadsToSegments_BDC8A523FC5300FA-001\tempDir-001\segments_1 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestIndexWriterThreadsToSegments_BDC8A523FC5300FA-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestIndexWriterThreadsToSegments_BDC8A523FC5300FA-001 at __randomizedtesting.SeedInfo.seed([BDC8A523FC5300FA]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.lucene.store.TestMultiMMap Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_BDC8A523FC5300FA-001\testThreadSafety-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_BDC8A523FC5300FA-001\testThreadSafety-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_BDC8A523FC5300FA-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_BDC8A523FC5300FA-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_BDC8A523FC5300FA-001\testThreadSafety-001: java.nio.file
[JENKINS] Lucene-Solr-Tests-7.2 - Build # 11 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.2/11/ 11 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: Error from server at http://127.0.0.1:44046/collection1: Cannot talk to ZooKeeper - Updates are disabled. Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:44046/collection1: Cannot talk to ZooKeeper - Updates are disabled. at __randomizedtesting.SeedInfo.seed([F096ECF9689B8083:78C2D323C667ED7B]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.BaseDistributedSearchTestCase.add(BaseDistributedSearchTestCase.java:507) at org.apache.solr.cloud.BasicDistributedZkTest.testUpdateProcessorsRunOnlyOnce(BasicDistributedZkTest.java:683) at org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:377) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at or
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 905 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/905/ No tests ran. Build Log: [...truncated 28007 lines...] prepare-release-no-sign: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist [copy] Copying 476 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 215 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.04 sec (6.6 MB/sec) [smoker] check changes HTML... [smoker] download lucene-8.0.0-src.tgz... [smoker] 29.8 MB in 0.09 sec (337.0 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-8.0.0.tgz... [smoker] 71.0 MB in 0.23 sec (308.6 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-8.0.0.zip... [smoker] 81.3 MB in 0.26 sec (314.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-8.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6186 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-8.0.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6186 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-8.0.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run "ant validate" [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'... [smoker] test demo with 1.8... [smoker] got 216 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] generate javadocs w/ Java 8... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] confirm all releases have coverage in TestBackwardsCompatibility [smoker] find all past Lucene releases... [smoker] run TestBackwardsCompatibility.. [smoker] success! [smoker] [smoker] Test Solr... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.00 sec (257.0 MB/sec) [smoker] check changes HTML... [smoker] download solr-8.0.0-src.tgz... [smoker] 51.9 MB in 0.16 sec (322.4 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-8.0.0.tgz... [smoker] 146.1 MB in 0.13 sec (1123.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-8.0.0.zip... [smoker] 147.1 MB in 0.13 sec (1142.0 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-8.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-8.0.0.tgz... [smoker] **WARNING**: skipping check of /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] copying unpacked distribution for Java 8 ... [smoker] test solr example w/ Java 8... [smoker] start Solr instance (log=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/solr-example.log)... [smoker] No process found for Solr node running on port 8983 [smoker] Running techproducts example on port 8983 from /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8 [smoker] Creating Solr home directory /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/example/techproducts/solr [smoker] [smoker] Starting up Solr on port 8983 using command: [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr" [smoker] [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|] [/] [-] [\] [|] [/] [-] [\] [smoker] Starte
[jira] [Commented] (SOLR-11754) Remove AbstractSolrTestCase
[ https://issues.apache.org/jira/browse/SOLR-11754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288416#comment-16288416 ] Shawn Heisey commented on SOLR-11754: - It certainly does seem that there's almost nothing there. What little is there that has function can probably be added to SolrTestCaseJ4. Looking over the code, I don't even see any evidence that the class does what the javadoc says it does, which is creating/destroying the index, and providing assertion methods. I guess the only question really becomes whether or not the abstraction itself makes it easier for people to mentally grasp the test architecture. I don't have a problem with shim classes that don't do very much, *if* their existence and the name they've been given helps with understanding the code. I do see AbstractZkTestCase as well, with far fewer descendants, but that abstract class has a LOT more going on in it than the one you're proposing to remove. > Remove AbstractSolrTestCase > --- > > Key: SOLR-11754 > URL: https://issues.apache.org/jira/browse/SOLR-11754 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: David Smiley >Assignee: David Smiley > > I'm arguing AbstractSolrTestCase should be removed as it's obsoleted by > SolrTestCaseJ4. > In SOLR-3911 (back in 2012) Mark made it extend from SolrTestCaseJ4. There > is really very little in this test class. Some of the methods here are > duplicated by SolrTestCaseJ4 and thus are completely redundant > (ignoreException, resetExceptionIgnores, getFile). There haven't been any > modifications to this class of substance since 2012 either. > I think we can just outright remove it (no deprecation phase). Anyone still > using it can trivially switch. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9304) -Dsolr.ssl.checkPeerName=false ignored on master
[
https://issues.apache.org/jira/browse/SOLR-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288400#comment-16288400
]
Carlton Findley commented on SOLR-9304:
---
Thanks for the patch!
> -Dsolr.ssl.checkPeerName=false ignored on master
>
>
> Key: SOLR-9304
> URL: https://issues.apache.org/jira/browse/SOLR-9304
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.0
>Reporter: Hoss Man
> Attachments: SOLR-9304-uses-deprecated.patch, SOLR-9304.patch
>
>
> {{-Dsolr.ssl.checkPeerName=false}} is completely ignored on master...
> {noformat}
> hossman@tray:~/lucene/dev/solr [master] $ find -name \*.java | xargs grep
> checkPeerName
> ./solrj/src/java/org/apache/solr/client/solrj/impl/HttpClientUtil.java:
> public static final String SYS_PROP_CHECK_PEER_NAME =
> "solr.ssl.checkPeerName";
> hossman@tray:~/lucene/dev/solr [master] $ find -name \*.java | xargs grep
> SYS_PROP_CHECK_PEER_NAME
> ./test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:
> boolean sslCheckPeerName =
> toBooleanDefaultIfNull(toBooleanObject(System.getProperty(HttpClientUtil.SYS_PROP_CHECK_PEER_NAME)),
> true);
> ./solrj/src/java/org/apache/solr/client/solrj/impl/HttpClientUtil.java:
> public static final String SYS_PROP_CHECK_PEER_NAME =
> "solr.ssl.checkPeerName";
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.2-Windows (32bit/jdk1.8.0_144) - Build # 14 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Windows/14/ Java: 32bit/jdk1.8.0_144 -server -XX:+UseSerialGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCloudInspectUtil Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudInspectUtil_2E6BA8F281BA221-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudInspectUtil_2E6BA8F281BA221-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudInspectUtil_2E6BA8F281BA221-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudInspectUtil_2E6BA8F281BA221-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudInspectUtil_2E6BA8F281BA221-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudInspectUtil_2E6BA8F281BA221-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudInspectUtil_2E6BA8F281BA221-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudInspectUtil_2E6BA8F281BA221-001 at __randomizedtesting.SeedInfo.seed([2E6BA8F281BA221]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.impl.HttpSolrClientSSLAuthConPoolTest Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.impl.HttpSolrClientSSLAuthConPoolTest_ED3A13E0BBB58E-001\tempDir-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.impl.HttpSolrClientSSLAuthConPoolTest_ED3A13E0BBB58E-001\tempDir-001 C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.impl.HttpSolrClientSSLAuthConPoolTest_ED3A13E0BBB58E-001\tempDir-001\solr.xml: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.impl.HttpSolrClientSSLAuthConPoolTest_ED3A13E0BBB58E-001\tempDir-001\solr.xml C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.impl.HttpSolrClientSSLAuthConPoolTest_ED3A13E0BBB58E-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.impl.HttpSolrClientSSLAuthConPoolTest_ED3A13E0BBB58E-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.impl.HttpSolrClientSSLAuthConPoolTest_ED3A13E0BBB58E-001\tempDir-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.impl.HttpSolrClientSSLAuthConPoolTest_ED3A13E0BBB58E-001\tempDir-001 C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.impl.HttpSolrClien
[jira] [Commented] (LUCENE-8011) Improve similarity explanations
[
https://issues.apache.org/jira/browse/LUCENE-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288340#comment-16288340
]
ASF GitHub Bot commented on LUCENE-8011:
Github user jpountz commented on the issue:
https://github.com/apache/lucene-solr/pull/280
No need to be sorry!
> Improve similarity explanations
> ---
>
> Key: LUCENE-8011
> URL: https://issues.apache.org/jira/browse/LUCENE-8011
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
> Labels: newdev
>
> LUCENE-7997 improves BM25 and Classic explains to better explain:
> {noformat}
> product of:
> 2.2 = scaling factor, k1 + 1
> 9.388654 = idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:
> 1.0 = n, number of documents containing term
> 17927.0 = N, total number of documents with field
> 0.9987758 = tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl))
> from:
> 979.0 = freq, occurrences of term within document
> 1.2 = k1, term saturation parameter
> 0.75 = b, length normalization parameter
> 1.0 = dl, length of field
> 1.0 = avgdl, average length of field
> {noformat}
> Previously it was pretty cryptic and used confusing terminology like
> docCount/docFreq without explanation:
> {noformat}
> product of:
> 0.016547536 = idf, computed as log(1 + (docCount - docFreq + 0.5) /
> (docFreq + 0.5)) from:
> 449.0 = docFreq
> 456.0 = docCount
> 2.1920826 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b
> * fieldLength / avgFieldLength)) from:
> 113659.0 = freq=113658
> 1.2 = parameter k1
> 0.75 = parameter b
> 2300.5593 = avgFieldLength
> 1048600.0 = fieldLength
> {noformat}
> We should fix other similarities too in the same way, they should be more
> practical.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #280: LUCENE-8011: Improve similarity explanations
Github user jpountz commented on the issue: https://github.com/apache/lucene-solr/pull/280 No need to be sorry! --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8011) Improve similarity explanations
[
https://issues.apache.org/jira/browse/LUCENE-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288338#comment-16288338
]
ASF GitHub Bot commented on LUCENE-8011:
Github user mayya-sharipova commented on the issue:
https://github.com/apache/lucene-solr/pull/280
@jpountz Adrien thanks for your help. Sorry, I will make sure to run `ant
precommit` before committing next time. I have pushed another change to address
this.
> Improve similarity explanations
> ---
>
> Key: LUCENE-8011
> URL: https://issues.apache.org/jira/browse/LUCENE-8011
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
> Labels: newdev
>
> LUCENE-7997 improves BM25 and Classic explains to better explain:
> {noformat}
> product of:
> 2.2 = scaling factor, k1 + 1
> 9.388654 = idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:
> 1.0 = n, number of documents containing term
> 17927.0 = N, total number of documents with field
> 0.9987758 = tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl))
> from:
> 979.0 = freq, occurrences of term within document
> 1.2 = k1, term saturation parameter
> 0.75 = b, length normalization parameter
> 1.0 = dl, length of field
> 1.0 = avgdl, average length of field
> {noformat}
> Previously it was pretty cryptic and used confusing terminology like
> docCount/docFreq without explanation:
> {noformat}
> product of:
> 0.016547536 = idf, computed as log(1 + (docCount - docFreq + 0.5) /
> (docFreq + 0.5)) from:
> 449.0 = docFreq
> 456.0 = docCount
> 2.1920826 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b
> * fieldLength / avgFieldLength)) from:
> 113659.0 = freq=113658
> 1.2 = parameter k1
> 0.75 = parameter b
> 2300.5593 = avgFieldLength
> 1048600.0 = fieldLength
> {noformat}
> We should fix other similarities too in the same way, they should be more
> practical.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #280: LUCENE-8011: Improve similarity explanations
Github user mayya-sharipova commented on the issue: https://github.com/apache/lucene-solr/pull/280 @jpountz Adrien thanks for your help. Sorry, I will make sure to run `ant precommit` before committing next time. I have pushed another change to address this. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11754) Remove AbstractSolrTestCase
David Smiley created SOLR-11754: --- Summary: Remove AbstractSolrTestCase Key: SOLR-11754 URL: https://issues.apache.org/jira/browse/SOLR-11754 Project: Solr Issue Type: Test Security Level: Public (Default Security Level. Issues are Public) Components: Tests Reporter: David Smiley I'm arguing AbstractSolrTestCase should be removed as it's obsoleted by SolrTestCaseJ4. In SOLR-3911 (back in 2012) Mark made it extend from SolrTestCaseJ4. There is really very little in this test class. Some of the methods here are duplicated by SolrTestCaseJ4 and thus are completely redundant (ignoreException, resetExceptionIgnores, getFile). There haven't been any modifications to this class of substance since 2012 either. I think we can just outright remove it (no deprecation phase). Anyone still using it can trivially switch. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11754) Remove AbstractSolrTestCase
[ https://issues.apache.org/jira/browse/SOLR-11754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley reassigned SOLR-11754: --- Assignee: David Smiley > Remove AbstractSolrTestCase > --- > > Key: SOLR-11754 > URL: https://issues.apache.org/jira/browse/SOLR-11754 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: David Smiley >Assignee: David Smiley > > I'm arguing AbstractSolrTestCase should be removed as it's obsoleted by > SolrTestCaseJ4. > In SOLR-3911 (back in 2012) Mark made it extend from SolrTestCaseJ4. There > is really very little in this test class. Some of the methods here are > duplicated by SolrTestCaseJ4 and thus are completely redundant > (ignoreException, resetExceptionIgnores, getFile). There haven't been any > modifications to this class of substance since 2012 either. > I think we can just outright remove it (no deprecation phase). Anyone still > using it can trivially switch. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9304) -Dsolr.ssl.checkPeerName=false ignored on master
[
https://issues.apache.org/jira/browse/SOLR-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated SOLR-9304:
---
Attachment: SOLR-9304.patch
With some help from [~hossman], I was able to eliminate the deprecated code.
Apparently directly setting things like the hostname verifier can be overridden
by other configuration, particularly by setting an SSL context. I didn't see
that being done in the code, but it's something that could be added later.
I did put nocommit in the patch -- I think we need a test that can verify that
disabling hostname verification with a sysprop actually works.
> -Dsolr.ssl.checkPeerName=false ignored on master
>
>
> Key: SOLR-9304
> URL: https://issues.apache.org/jira/browse/SOLR-9304
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.0
>Reporter: Hoss Man
> Attachments: SOLR-9304-uses-deprecated.patch, SOLR-9304.patch
>
>
> {{-Dsolr.ssl.checkPeerName=false}} is completely ignored on master...
> {noformat}
> hossman@tray:~/lucene/dev/solr [master] $ find -name \*.java | xargs grep
> checkPeerName
> ./solrj/src/java/org/apache/solr/client/solrj/impl/HttpClientUtil.java:
> public static final String SYS_PROP_CHECK_PEER_NAME =
> "solr.ssl.checkPeerName";
> hossman@tray:~/lucene/dev/solr [master] $ find -name \*.java | xargs grep
> SYS_PROP_CHECK_PEER_NAME
> ./test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:
> boolean sslCheckPeerName =
> toBooleanDefaultIfNull(toBooleanObject(System.getProperty(HttpClientUtil.SYS_PROP_CHECK_PEER_NAME)),
> true);
> ./solrj/src/java/org/apache/solr/client/solrj/impl/HttpClientUtil.java:
> public static final String SYS_PROP_CHECK_PEER_NAME =
> "solr.ssl.checkPeerName";
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11753) Ref Guide: Upgrade notes for 7.2
[ https://issues.apache.org/jira/browse/SOLR-11753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288286#comment-16288286 ] ASF subversion and git services commented on SOLR-11753: Commit 80324cd647560a766acbdd29104cc87f426144ec in lucene-solr's branch refs/heads/branch_7_2 from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=80324cd ] SOLR-11753: add upgrade notes; misc cleanups in other pages > Ref Guide: Upgrade notes for 7.2 > > > Key: SOLR-11753 > URL: https://issues.apache.org/jira/browse/SOLR-11753 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett > Fix For: 7.2 > > > Issue to track adding 7.2 upgrade notes for the Ref Guide. > Also serves as an umbrella issue for small edits done as part of copy editing > the 7.2 release. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11753) Ref Guide: Upgrade notes for 7.2
[ https://issues.apache.org/jira/browse/SOLR-11753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288284#comment-16288284 ] ASF subversion and git services commented on SOLR-11753: Commit 67bbdaaa4d72e8a8d4a4623f8ed9fcb0827e0677 in lucene-solr's branch refs/heads/branch_7x from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=67bbdaa ] SOLR-11753: add upgrade notes; misc cleanups in other pages > Ref Guide: Upgrade notes for 7.2 > > > Key: SOLR-11753 > URL: https://issues.apache.org/jira/browse/SOLR-11753 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett > Fix For: 7.2 > > > Issue to track adding 7.2 upgrade notes for the Ref Guide. > Also serves as an umbrella issue for small edits done as part of copy editing > the 7.2 release. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11753) Ref Guide: Upgrade notes for 7.2
[ https://issues.apache.org/jira/browse/SOLR-11753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288275#comment-16288275 ] ASF subversion and git services commented on SOLR-11753: Commit 6d23ee96a99932bedaf658ddd61fd58875656cd4 in lucene-solr's branch refs/heads/master from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6d23ee9 ] SOLR-11753: add upgrade notes; misc cleanups in other pages > Ref Guide: Upgrade notes for 7.2 > > > Key: SOLR-11753 > URL: https://issues.apache.org/jira/browse/SOLR-11753 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett > Fix For: 7.2 > > > Issue to track adding 7.2 upgrade notes for the Ref Guide. > Also serves as an umbrella issue for small edits done as part of copy editing > the 7.2 release. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11753) Ref Guide: Upgrade notes for 7.2
Cassandra Targett created SOLR-11753: Summary: Ref Guide: Upgrade notes for 7.2 Key: SOLR-11753 URL: https://issues.apache.org/jira/browse/SOLR-11753 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: Cassandra Targett Assignee: Cassandra Targett Fix For: 7.2 Issue to track adding 7.2 upgrade notes for the Ref Guide. Also serves as an umbrella issue for small edits done as part of copy editing the 7.2 release. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9304) -Dsolr.ssl.checkPeerName=false ignored on master
[
https://issues.apache.org/jira/browse/SOLR-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated SOLR-9304:
---
Attachment: SOLR-9304-uses-deprecated.patch
Patch that uses deprecated HttpClient stuff. Also re-introduces a couple of
boolean-related methods that perhaps should be done another way. The patch
would probably work, but I don't think it's a very good one.
> -Dsolr.ssl.checkPeerName=false ignored on master
>
>
> Key: SOLR-9304
> URL: https://issues.apache.org/jira/browse/SOLR-9304
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.0
>Reporter: Hoss Man
> Attachments: SOLR-9304-uses-deprecated.patch
>
>
> {{-Dsolr.ssl.checkPeerName=false}} is completely ignored on master...
> {noformat}
> hossman@tray:~/lucene/dev/solr [master] $ find -name \*.java | xargs grep
> checkPeerName
> ./solrj/src/java/org/apache/solr/client/solrj/impl/HttpClientUtil.java:
> public static final String SYS_PROP_CHECK_PEER_NAME =
> "solr.ssl.checkPeerName";
> hossman@tray:~/lucene/dev/solr [master] $ find -name \*.java | xargs grep
> SYS_PROP_CHECK_PEER_NAME
> ./test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:
> boolean sslCheckPeerName =
> toBooleanDefaultIfNull(toBooleanObject(System.getProperty(HttpClientUtil.SYS_PROP_CHECK_PEER_NAME)),
> true);
> ./solrj/src/java/org/apache/solr/client/solrj/impl/HttpClientUtil.java:
> public static final String SYS_PROP_CHECK_PEER_NAME =
> "solr.ssl.checkPeerName";
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-9.0.1) - Build # 7053 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7053/ Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.lucene.store.TestFileSwitchDirectory Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_59B0C5750EABCDAA-001\bar-005: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_59B0C5750EABCDAA-001\bar-005 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_59B0C5750EABCDAA-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_59B0C5750EABCDAA-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_59B0C5750EABCDAA-001\bar-005: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_59B0C5750EABCDAA-001\bar-005 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_59B0C5750EABCDAA-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_59B0C5750EABCDAA-001 at __randomizedtesting.SeedInfo.seed([59B0C5750EABCDAA]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.lucene.index.TestIndexSplitter Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\misc\test\J0\temp\lucene.index.TestIndexSplitter_A9B01EFB6F2C5549-001\TestIndexSplitter-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\misc\test\J0\temp\lucene.index.TestIndexSplitter_A9B01EFB6F2C5549-001\TestIndexSplitter-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\misc\test\J0\temp\lucene.index.TestIndexSplitter_A9B01EFB6F2C5549-001\TestIndexSplitter-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\misc\test\J0\temp\lucene.index.TestIndexSplitter_A9B01EFB6F2C5549-001\TestIndexSplitter-001 at __randomizedtesting.SeedInfo.seed([A9B01EFB6F2C5549]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuit
[jira] [Updated] (SOLR-11624) _default configset overwrites a a configset if collection.configName isn't specified even if a confiset of the same name already exists.
[ https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Kumar Singh updated SOLR-11624: Attachment: SOLR-11624.4.patch Updated the patch with documentation. [~ichattopadhyaya] [~dsmiley] Kindly review the same. > _default configset overwrites a a configset if collection.configName isn't > specified even if a confiset of the same name already exists. > > > Key: SOLR-11624 > URL: https://issues.apache.org/jira/browse/SOLR-11624 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.2 >Reporter: Erick Erickson >Assignee: Ishan Chattopadhyaya > Attachments: SOLR-11624-2.patch, SOLR-11624.3.patch, > SOLR-11624.4.patch, SOLR-11624.patch > > > Looks like a problem that crept in when we changed the _default configset > stuff. > setup: > upload a configset named "wiki" > collections?action=CREATE&name=wiki&. > My custom configset "wiki" gets overwritten by _default and then used by the > "wiki" collection. > Assigning to myself only because it really needs to be fixed IMO and I don't > want to lose track of it. Anyone else please feel free to take it. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.2-Linux (64bit/jdk1.8.0_144) - Build # 52 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Linux/52/ Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:37279 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:37279 at __randomizedtesting.SeedInfo.seed([F1B01862A7AB3B70:79E427B809575688]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:314) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
[jira] [Created] (SOLR-11752) add gzip to jetty
Matthew Sporleder created SOLR-11752:
Summary: add gzip to jetty
Key: SOLR-11752
URL: https://issues.apache.org/jira/browse/SOLR-11752
Project: Solr
Issue Type: New Feature
Security Level: Public (Default Security Level. Issues are Public)
Components: Server
Reporter: Matthew Sporleder
Priority: Trivial
with a little bit of typing I am able to add gzip to my solr's jetty, which is
a big help for SAN access and completely out-of-band to solr, *and* only
happens if the client requests it so I think it is is a good default.
I will just inline my code to this ticket:
{code}
#server/etc/jetty-gzip.xml
#just download it from here:
http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-server/9.3.0.v20150612/etc/jetty-gzip.xml?av=f
{code}
{code}
#server/modules/gzip.mod
[depend]
server
[xml]
etc/jetty-gzip.xml
{code}
This is where you might want to add an option, but the result should look like
this:
{code}
#bin/solr
else
SOLR_JETTY_CONFIG+=("--module=http,gzip")
fi
{code}
I can now do this:
{code}
curl -vvv --compressed localhost:8983/solr/ > /dev/null
{code}
With:
{code}
< Content-Encoding: gzip
< Content-Length: 2890
{code}
Without:
{code}
< Content-Length: 13349
{code}
---
A regular query:
With:
{code}
< Content-Encoding: gzip
< Content-Length: 2876
{code}
Without:
{code}
< Content-Length: 17761
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11751) Collections API: Implement collection properties that block Collections API actions
[ https://issues.apache.org/jira/browse/SOLR-11751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288156#comment-16288156 ] Shawn Heisey commented on SOLR-11751: - [~erickerickson], I didn't see your comment until after I had finished adding my optional ideas. Which I did type immediately, but forgot to click "Add" until later. Regarding the optional idea where an override parameter must match the value in the property: If we make it so that an empty string in the property can't ever be matched, that would allow somebody to easily prevent the override. Of course the same thing could be accomplished with a special string, like "NO_OVERRIDE". > Collections API: Implement collection properties that block Collections API > actions > > > Key: SOLR-11751 > URL: https://issues.apache.org/jira/browse/SOLR-11751 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.1 >Reporter: Shawn Heisey >Priority: Minor > > [~yriveiro] asked on the mailing list whether we had any ability to prevent a > collection from being deleted with a property. > I don't know of any way to do this currently, but it does strike me as > useful, so here's the proposal: > Implement some new collection properties, that when set, block certain > Collections API actions. > At this time, I'm not even sure that user-modifiable collection-level > properties actually exist, so that may need to be implemented before this can > be implemented. It *could* be done with cluster properties, but that seems > like a hack. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11751) Collections API: Implement collection properties that block Collections API actions
[ https://issues.apache.org/jira/browse/SOLR-11751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288137#comment-16288137 ] Shawn Heisey commented on SOLR-11751: - Optional ideas: * If a blocking property can have an arbitrary value, implement an API parameter that would override the block, IF the value for that parameter matches the value in the property. * One single property that blocks ALL Collections API usage. A tangent idea, for a separate issue: * Prevent external CoreAdmin requests on SolrCloud unless a property is set that essentially makes the user declare "yes, I know what I'm doing". This one probably should work at the cluster or collection level. > Collections API: Implement collection properties that block Collections API > actions > > > Key: SOLR-11751 > URL: https://issues.apache.org/jira/browse/SOLR-11751 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.1 >Reporter: Shawn Heisey >Priority: Minor > > [~yriveiro] asked on the mailing list whether we had any ability to prevent a > collection from being deleted with a property. > I don't know of any way to do this currently, but it does strike me as > useful, so here's the proposal: > Implement some new collection properties, that when set, block certain > Collections API actions. > At this time, I'm not even sure that user-modifiable collection-level > properties actually exist, so that may need to be implemented before this can > be implemented. It *could* be done with cluster properties, but that seems > like a hack. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11751) Collections API: Implement collection properties that block Collections API actions
[ https://issues.apache.org/jira/browse/SOLR-11751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288106#comment-16288106 ] Erick Erickson commented on SOLR-11751: --- The collecitons API MODIFYCOLLECTION can add/modify collection properties I think, which would allow you to add the tags at least already. We'd need to build in code to respect such tags of course. I'd guess you'd have to change the property in order to be able to delete the collection if you _really_ wanted to delete it at some later point. I can imagine you'd like to lock down configsets too, although that'd be a sticky wicket wrt field guessing, and the schema and config APIs. > Collections API: Implement collection properties that block Collections API > actions > > > Key: SOLR-11751 > URL: https://issues.apache.org/jira/browse/SOLR-11751 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.1 >Reporter: Shawn Heisey >Priority: Minor > > [~yriveiro] asked on the mailing list whether we had any ability to prevent a > collection from being deleted with a property. > I don't know of any way to do this currently, but it does strike me as > useful, so here's the proposal: > Implement some new collection properties, that when set, block certain > Collections API actions. > At this time, I'm not even sure that user-modifiable collection-level > properties actually exist, so that may need to be implemented before this can > be implemented. It *could* be done with cluster properties, but that seems > like a hack. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Created] (SOLR-11751) Collections API: Implement collection properties that block Collections API actions
Can't get to JIRA right now, but the Collections API MODIFYCOLLECTION seems right for adding properties On Tue, Dec 12, 2017 at 10:58 AM, Shawn Heisey (JIRA) wrote: > Shawn Heisey created SOLR-11751: > --- > > Summary: Collections API: Implement collection properties that > block Collections API actions > Key: SOLR-11751 > URL: https://issues.apache.org/jira/browse/SOLR-11751 > Project: Solr > Issue Type: New Feature > Security Level: Public (Default Security Level. Issues are Public) > Components: SolrCloud > Affects Versions: 7.1 > Reporter: Shawn Heisey > Priority: Minor > > > [~yriveiro] asked on the mailing list whether we had any ability to prevent a > collection from being deleted with a property. > > I don't know of any way to do this currently, but it does strike me as > useful, so here's the proposal: > > Implement some new collection properties, that when set, block certain > Collections API actions. > > At this time, I'm not even sure that user-modifiable collection-level > properties actually exist, so that may need to be implemented before this can > be implemented. It *could* be done with cluster properties, but that seems > like a hack. > > > > > -- > This message was sent by Atlassian JIRA > (v6.4.14#64029) > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11725) json.facet's stddev() function should be changed to use the "Corrected sample stddev" formula
[
https://issues.apache.org/jira/browse/SOLR-11725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288090#comment-16288090
]
ASF subversion and git services commented on SOLR-11725:
Commit 2990c88a927213177483b61fe8e6971df04fc3ed in lucene-solr's branch
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2990c88 ]
Beef up testing of json.facet 'refine:simple' when dealing with 'Long Tail'
terms
In an attempt to get more familiar with json.facet refinement, I set out to try
and refactor/generalize/clone
some of the existing facet.pivot refinement tests to assert that json.facet
could produce the same results.
This test is a baby step towards doing that: Cloning
DistributedFacetPivotLongTailTest into
DistributedFacetSimpleRefinementLongTailTest (with shared index building code).
Along the way, I learned that the core logic of 'refine:simple' is actually
quite different then how facet.field
& facet.pivot work (see discussion in SOLR-11733), so they do *NOT* produce the
same results in many "Long Tail"
Sitautions. As a result, many of the logic/assertions
inDistributedFacetSimpleRefinementLongTailTest are very
differnet then their counter parts in DistributedFacetPivotLongTailTest, with
detailed explanations in comments.
Hopefully this test will prove useful down the road to anyone who might want to
compare/contrast facet.pivot
with json.facet, and to prevent regressions in 'refine:simple' if/when we add
more complex refinement
approaches in the future.
There are also a few TODOs in the test related to some other small
discrepencies between json.facet and
stats.field that I opened along the way, indicating where the tests should be
modified once those issues are
addressed in json.facet...
- SOLR-11706: support for multivalued numeric fields in stats
- SOLR-11695: support for 'missing()' & 'num_vals()' (aka: 'count' from
stats.field) numeric stats
- SOLR-11725: switch from 'uncorrected stddev' to 'corrected stddev'
> json.facet's stddev() function should be changed to use the "Corrected sample
> stddev" formula
> -
>
> Key: SOLR-11725
> URL: https://issues.apache.org/jira/browse/SOLR-11725
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-11725.patch
>
>
> While working on some equivalence tests/demonstrations for
> {{facet.pivot+stats.field}} vs {{json.facet}} I noticed that the {{stddev}}
> calculations done between the two code paths can be measurably different, and
> realized this is due to them using very different code...
> * {{json.facet=foo:stddev(foo)}}
> ** {{StddevAgg.java}}
> ** {{Math.sqrt((sumSq/count)-Math.pow(sum/count, 2))}}
> * {{stats.field=\{!stddev=true\}foo}}
> ** {{StatsValuesFactory.java}}
> ** {{Math.sqrt(((count * sumOfSquares) - (sum * sum)) / (count * (count -
> 1.0D)))}}
> Since I"m not really a math guy, I consulting with a bunch of smart math/stat
> nerds I know online to help me sanity check if these equations (some how)
> reduced to eachother (In which case the discrepancies I was seeing in my
> results might have just been due to the order of intermediate operation
> execution & floating point rounding differences).
> They confirmed that the two bits of code are _not_ equivalent to each other,
> and explained that the code JSON Faceting is using is equivalent to the
> "Uncorrected sample stddev" formula, while StatsComponent's code is
> equivalent to the the "Corrected sample stddev" formula...
> https://en.wikipedia.org/wiki/Standard_deviation#Uncorrected_sample_standard_deviation
> When I told them that stuff like this is why no one likes mathematicians and
> pressed them to explain which one was the "most canonical" (or "most
> generally applicable" or "best") definition of stddev, I was told that:
> # This is something statisticians frequently disagree on
> # Practically speaking the diff between the calculations doesn't tend to
> differ significantly when count is "very large"
> # _"Corrected sample stddev" is more appropriate when comparing two
> distributions_
> Given that:
> * the primary usage of computing the stddev of a field/function against a
> Solr result set (or against a sub-set of results defined by a facet
> constraint) is probably to compare that distribution to a different Solr
> result set (or to compare N sub-sets of results defined by N facet
> constraints)
> * the size of the sets of documents (values) can be relatively small when
> computing stats over facet constraint sub-sets
> ...it seems like {{StddevAgg.java}} should be updated to use the "Corrected
> sample stddev" equation.
--
[jira] [Commented] (SOLR-11725) json.facet's stddev() function should be changed to use the "Corrected sample stddev" formula
[
https://issues.apache.org/jira/browse/SOLR-11725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288086#comment-16288086
]
ASF subversion and git services commented on SOLR-11725:
Commit 53f2d4aa3aa171d5f37284eba9ca56d987729796 in lucene-solr's branch
refs/heads/branch_7x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=53f2d4a ]
Beef up testing of json.facet 'refine:simple' when dealing with 'Long Tail'
terms
In an attempt to get more familiar with json.facet refinement, I set out to try
and refactor/generalize/clone
some of the existing facet.pivot refinement tests to assert that json.facet
could produce the same results.
This test is a baby step towards doing that: Cloning
DistributedFacetPivotLongTailTest into
DistributedFacetSimpleRefinementLongTailTest (with shared index building code).
Along the way, I learned that the core logic of 'refine:simple' is actually
quite different then how facet.field
& facet.pivot work (see discussion in SOLR-11733), so they do *NOT* produce the
same results in many "Long Tail"
Sitautions. As a result, many of the logic/assertions
inDistributedFacetSimpleRefinementLongTailTest are very
differnet then their counter parts in DistributedFacetPivotLongTailTest, with
detailed explanations in comments.
Hopefully this test will prove useful down the road to anyone who might want to
compare/contrast facet.pivot
with json.facet, and to prevent regressions in 'refine:simple' if/when we add
more complex refinement
approaches in the future.
There are also a few TODOs in the test related to some other small
discrepencies between json.facet and
stats.field that I opened along the way, indicating where the tests should be
modified once those issues are
addressed in json.facet...
- SOLR-11706: support for multivalued numeric fields in stats
- SOLR-11695: support for 'missing()' & 'num_vals()' (aka: 'count' from
stats.field) numeric stats
- SOLR-11725: switch from 'uncorrected stddev' to 'corrected stddev'
(cherry picked from commit 2990c88a927213177483b61fe8e6971df04fc3ed)
> json.facet's stddev() function should be changed to use the "Corrected sample
> stddev" formula
> -
>
> Key: SOLR-11725
> URL: https://issues.apache.org/jira/browse/SOLR-11725
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-11725.patch
>
>
> While working on some equivalence tests/demonstrations for
> {{facet.pivot+stats.field}} vs {{json.facet}} I noticed that the {{stddev}}
> calculations done between the two code paths can be measurably different, and
> realized this is due to them using very different code...
> * {{json.facet=foo:stddev(foo)}}
> ** {{StddevAgg.java}}
> ** {{Math.sqrt((sumSq/count)-Math.pow(sum/count, 2))}}
> * {{stats.field=\{!stddev=true\}foo}}
> ** {{StatsValuesFactory.java}}
> ** {{Math.sqrt(((count * sumOfSquares) - (sum * sum)) / (count * (count -
> 1.0D)))}}
> Since I"m not really a math guy, I consulting with a bunch of smart math/stat
> nerds I know online to help me sanity check if these equations (some how)
> reduced to eachother (In which case the discrepancies I was seeing in my
> results might have just been due to the order of intermediate operation
> execution & floating point rounding differences).
> They confirmed that the two bits of code are _not_ equivalent to each other,
> and explained that the code JSON Faceting is using is equivalent to the
> "Uncorrected sample stddev" formula, while StatsComponent's code is
> equivalent to the the "Corrected sample stddev" formula...
> https://en.wikipedia.org/wiki/Standard_deviation#Uncorrected_sample_standard_deviation
> When I told them that stuff like this is why no one likes mathematicians and
> pressed them to explain which one was the "most canonical" (or "most
> generally applicable" or "best") definition of stddev, I was told that:
> # This is something statisticians frequently disagree on
> # Practically speaking the diff between the calculations doesn't tend to
> differ significantly when count is "very large"
> # _"Corrected sample stddev" is more appropriate when comparing two
> distributions_
> Given that:
> * the primary usage of computing the stddev of a field/function against a
> Solr result set (or against a sub-set of results defined by a facet
> constraint) is probably to compare that distribution to a different Solr
> result set (or to compare N sub-sets of results defined by N facet
> constraints)
> * the size of the sets of documents (values) can be relatively small when
> computing stats over facet constraint sub-sets
> ...it seems like {{StddevAgg.java}}
[jira] [Commented] (SOLR-11706) JSON FacetModule can't compute stats (min,max,etc...) on multivalued fields
[ https://issues.apache.org/jira/browse/SOLR-11706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288088#comment-16288088 ] ASF subversion and git services commented on SOLR-11706: Commit 2990c88a927213177483b61fe8e6971df04fc3ed in lucene-solr's branch refs/heads/master from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2990c88 ] Beef up testing of json.facet 'refine:simple' when dealing with 'Long Tail' terms In an attempt to get more familiar with json.facet refinement, I set out to try and refactor/generalize/clone some of the existing facet.pivot refinement tests to assert that json.facet could produce the same results. This test is a baby step towards doing that: Cloning DistributedFacetPivotLongTailTest into DistributedFacetSimpleRefinementLongTailTest (with shared index building code). Along the way, I learned that the core logic of 'refine:simple' is actually quite different then how facet.field & facet.pivot work (see discussion in SOLR-11733), so they do *NOT* produce the same results in many "Long Tail" Sitautions. As a result, many of the logic/assertions inDistributedFacetSimpleRefinementLongTailTest are very differnet then their counter parts in DistributedFacetPivotLongTailTest, with detailed explanations in comments. Hopefully this test will prove useful down the road to anyone who might want to compare/contrast facet.pivot with json.facet, and to prevent regressions in 'refine:simple' if/when we add more complex refinement approaches in the future. There are also a few TODOs in the test related to some other small discrepencies between json.facet and stats.field that I opened along the way, indicating where the tests should be modified once those issues are addressed in json.facet... - SOLR-11706: support for multivalued numeric fields in stats - SOLR-11695: support for 'missing()' & 'num_vals()' (aka: 'count' from stats.field) numeric stats - SOLR-11725: switch from 'uncorrected stddev' to 'corrected stddev' > JSON FacetModule can't compute stats (min,max,etc...) on multivalued fields > --- > > Key: SOLR-11706 > URL: https://issues.apache.org/jira/browse/SOLR-11706 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man > Attachments: SOLR-11706.patch > > > While trying to write some tests demonstrating equivalences between the > StatsComponent and the JSON FacetModule i discovered that the FacetModules > stat functions (min, max, etc...) don't seem to work on multivalued fields. > Based on the stack traces, i gather the problem is because the FacetModule > seems to rely exclusively on using the "Function" parsers to get a value > source -- apparently w/o any other method of accumulating numeric stats from > multivalued (numeric) DocValues? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11706) JSON FacetModule can't compute stats (min,max,etc...) on multivalued fields
[ https://issues.apache.org/jira/browse/SOLR-11706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288084#comment-16288084 ] ASF subversion and git services commented on SOLR-11706: Commit 53f2d4aa3aa171d5f37284eba9ca56d987729796 in lucene-solr's branch refs/heads/branch_7x from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=53f2d4a ] Beef up testing of json.facet 'refine:simple' when dealing with 'Long Tail' terms In an attempt to get more familiar with json.facet refinement, I set out to try and refactor/generalize/clone some of the existing facet.pivot refinement tests to assert that json.facet could produce the same results. This test is a baby step towards doing that: Cloning DistributedFacetPivotLongTailTest into DistributedFacetSimpleRefinementLongTailTest (with shared index building code). Along the way, I learned that the core logic of 'refine:simple' is actually quite different then how facet.field & facet.pivot work (see discussion in SOLR-11733), so they do *NOT* produce the same results in many "Long Tail" Sitautions. As a result, many of the logic/assertions inDistributedFacetSimpleRefinementLongTailTest are very differnet then their counter parts in DistributedFacetPivotLongTailTest, with detailed explanations in comments. Hopefully this test will prove useful down the road to anyone who might want to compare/contrast facet.pivot with json.facet, and to prevent regressions in 'refine:simple' if/when we add more complex refinement approaches in the future. There are also a few TODOs in the test related to some other small discrepencies between json.facet and stats.field that I opened along the way, indicating where the tests should be modified once those issues are addressed in json.facet... - SOLR-11706: support for multivalued numeric fields in stats - SOLR-11695: support for 'missing()' & 'num_vals()' (aka: 'count' from stats.field) numeric stats - SOLR-11725: switch from 'uncorrected stddev' to 'corrected stddev' (cherry picked from commit 2990c88a927213177483b61fe8e6971df04fc3ed) > JSON FacetModule can't compute stats (min,max,etc...) on multivalued fields > --- > > Key: SOLR-11706 > URL: https://issues.apache.org/jira/browse/SOLR-11706 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man > Attachments: SOLR-11706.patch > > > While trying to write some tests demonstrating equivalences between the > StatsComponent and the JSON FacetModule i discovered that the FacetModules > stat functions (min, max, etc...) don't seem to work on multivalued fields. > Based on the stack traces, i gather the problem is because the FacetModule > seems to rely exclusively on using the "Function" parsers to get a value > source -- apparently w/o any other method of accumulating numeric stats from > multivalued (numeric) DocValues? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11733) json.facet refinement fails to bubble up some long tail (overrequested) terms?
[
https://issues.apache.org/jira/browse/SOLR-11733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288087#comment-16288087
]
ASF subversion and git services commented on SOLR-11733:
Commit 2990c88a927213177483b61fe8e6971df04fc3ed in lucene-solr's branch
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2990c88 ]
Beef up testing of json.facet 'refine:simple' when dealing with 'Long Tail'
terms
In an attempt to get more familiar with json.facet refinement, I set out to try
and refactor/generalize/clone
some of the existing facet.pivot refinement tests to assert that json.facet
could produce the same results.
This test is a baby step towards doing that: Cloning
DistributedFacetPivotLongTailTest into
DistributedFacetSimpleRefinementLongTailTest (with shared index building code).
Along the way, I learned that the core logic of 'refine:simple' is actually
quite different then how facet.field
& facet.pivot work (see discussion in SOLR-11733), so they do *NOT* produce the
same results in many "Long Tail"
Sitautions. As a result, many of the logic/assertions
inDistributedFacetSimpleRefinementLongTailTest are very
differnet then their counter parts in DistributedFacetPivotLongTailTest, with
detailed explanations in comments.
Hopefully this test will prove useful down the road to anyone who might want to
compare/contrast facet.pivot
with json.facet, and to prevent regressions in 'refine:simple' if/when we add
more complex refinement
approaches in the future.
There are also a few TODOs in the test related to some other small
discrepencies between json.facet and
stats.field that I opened along the way, indicating where the tests should be
modified once those issues are
addressed in json.facet...
- SOLR-11706: support for multivalued numeric fields in stats
- SOLR-11695: support for 'missing()' & 'num_vals()' (aka: 'count' from
stats.field) numeric stats
- SOLR-11725: switch from 'uncorrected stddev' to 'corrected stddev'
> json.facet refinement fails to bubble up some long tail (overrequested) terms?
> --
>
> Key: SOLR-11733
> URL: https://issues.apache.org/jira/browse/SOLR-11733
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Reporter: Hoss Man
>
> Something wonky is happening with {{json.facet}} refinement.
> "Long Tail" terms that may not be in the "top n" on every shard, but are in
> the "top n + overrequest" for at least 1 shard aren't getting refined and
> included in the aggragated response in some cases.
> I don't understand the code enough to explain this, but I have some steps to
> reproduce that i'll post in a comment shortly
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11695) JSON FacetModule needs equivilents for StatsComponent's "count" and "missing" features
[ https://issues.apache.org/jira/browse/SOLR-11695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288089#comment-16288089 ] ASF subversion and git services commented on SOLR-11695: Commit 2990c88a927213177483b61fe8e6971df04fc3ed in lucene-solr's branch refs/heads/master from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2990c88 ] Beef up testing of json.facet 'refine:simple' when dealing with 'Long Tail' terms In an attempt to get more familiar with json.facet refinement, I set out to try and refactor/generalize/clone some of the existing facet.pivot refinement tests to assert that json.facet could produce the same results. This test is a baby step towards doing that: Cloning DistributedFacetPivotLongTailTest into DistributedFacetSimpleRefinementLongTailTest (with shared index building code). Along the way, I learned that the core logic of 'refine:simple' is actually quite different then how facet.field & facet.pivot work (see discussion in SOLR-11733), so they do *NOT* produce the same results in many "Long Tail" Sitautions. As a result, many of the logic/assertions inDistributedFacetSimpleRefinementLongTailTest are very differnet then their counter parts in DistributedFacetPivotLongTailTest, with detailed explanations in comments. Hopefully this test will prove useful down the road to anyone who might want to compare/contrast facet.pivot with json.facet, and to prevent regressions in 'refine:simple' if/when we add more complex refinement approaches in the future. There are also a few TODOs in the test related to some other small discrepencies between json.facet and stats.field that I opened along the way, indicating where the tests should be modified once those issues are addressed in json.facet... - SOLR-11706: support for multivalued numeric fields in stats - SOLR-11695: support for 'missing()' & 'num_vals()' (aka: 'count' from stats.field) numeric stats - SOLR-11725: switch from 'uncorrected stddev' to 'corrected stddev' > JSON FacetModule needs equivilents for StatsComponent's "count" and "missing" > features > -- > > Key: SOLR-11695 > URL: https://issues.apache.org/jira/browse/SOLR-11695 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man > > StatsComponent supports stats named "count" and "missing": > * count: for the set of documents we're computing stats over, "how many > _non-distinct_ values exist in those documents in the specified field?" (or > in the case of an arbitrary function: "in how many of these documents does > true==ValueSource.exist()" ?) > ** no to be confused with the number of _unique_ values (aprox "cardinality" > or exact "countDistinct") > * missing: for the set of documents we're computing stats over, "how many of > those documents do not have any value in the specified field?" (or in the > case of an arbitrary function: "in how many of thse documents does > false==ValueSource.exist()" ?) > (NOTE: for a single valued field, these are essentially inveses of each > other, but for multivalued fields "count" actaully returns the total number > of "value instances" not just the number of docs that have at least one value) > AFAICT there is no equivalent functionality supported by the JSON > FacetModule, which will be a blocker preventing some users from migrating > from using stats.field (or facet.pivot+stats.field) to json.facet. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11695) JSON FacetModule needs equivilents for StatsComponent's "count" and "missing" features
[ https://issues.apache.org/jira/browse/SOLR-11695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288085#comment-16288085 ] ASF subversion and git services commented on SOLR-11695: Commit 53f2d4aa3aa171d5f37284eba9ca56d987729796 in lucene-solr's branch refs/heads/branch_7x from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=53f2d4a ] Beef up testing of json.facet 'refine:simple' when dealing with 'Long Tail' terms In an attempt to get more familiar with json.facet refinement, I set out to try and refactor/generalize/clone some of the existing facet.pivot refinement tests to assert that json.facet could produce the same results. This test is a baby step towards doing that: Cloning DistributedFacetPivotLongTailTest into DistributedFacetSimpleRefinementLongTailTest (with shared index building code). Along the way, I learned that the core logic of 'refine:simple' is actually quite different then how facet.field & facet.pivot work (see discussion in SOLR-11733), so they do *NOT* produce the same results in many "Long Tail" Sitautions. As a result, many of the logic/assertions inDistributedFacetSimpleRefinementLongTailTest are very differnet then their counter parts in DistributedFacetPivotLongTailTest, with detailed explanations in comments. Hopefully this test will prove useful down the road to anyone who might want to compare/contrast facet.pivot with json.facet, and to prevent regressions in 'refine:simple' if/when we add more complex refinement approaches in the future. There are also a few TODOs in the test related to some other small discrepencies between json.facet and stats.field that I opened along the way, indicating where the tests should be modified once those issues are addressed in json.facet... - SOLR-11706: support for multivalued numeric fields in stats - SOLR-11695: support for 'missing()' & 'num_vals()' (aka: 'count' from stats.field) numeric stats - SOLR-11725: switch from 'uncorrected stddev' to 'corrected stddev' (cherry picked from commit 2990c88a927213177483b61fe8e6971df04fc3ed) > JSON FacetModule needs equivilents for StatsComponent's "count" and "missing" > features > -- > > Key: SOLR-11695 > URL: https://issues.apache.org/jira/browse/SOLR-11695 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man > > StatsComponent supports stats named "count" and "missing": > * count: for the set of documents we're computing stats over, "how many > _non-distinct_ values exist in those documents in the specified field?" (or > in the case of an arbitrary function: "in how many of these documents does > true==ValueSource.exist()" ?) > ** no to be confused with the number of _unique_ values (aprox "cardinality" > or exact "countDistinct") > * missing: for the set of documents we're computing stats over, "how many of > those documents do not have any value in the specified field?" (or in the > case of an arbitrary function: "in how many of thse documents does > false==ValueSource.exist()" ?) > (NOTE: for a single valued field, these are essentially inveses of each > other, but for multivalued fields "count" actaully returns the total number > of "value instances" not just the number of docs that have at least one value) > AFAICT there is no equivalent functionality supported by the JSON > FacetModule, which will be a blocker preventing some users from migrating > from using stats.field (or facet.pivot+stats.field) to json.facet. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11733) json.facet refinement fails to bubble up some long tail (overrequested) terms?
[
https://issues.apache.org/jira/browse/SOLR-11733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288083#comment-16288083
]
ASF subversion and git services commented on SOLR-11733:
Commit 53f2d4aa3aa171d5f37284eba9ca56d987729796 in lucene-solr's branch
refs/heads/branch_7x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=53f2d4a ]
Beef up testing of json.facet 'refine:simple' when dealing with 'Long Tail'
terms
In an attempt to get more familiar with json.facet refinement, I set out to try
and refactor/generalize/clone
some of the existing facet.pivot refinement tests to assert that json.facet
could produce the same results.
This test is a baby step towards doing that: Cloning
DistributedFacetPivotLongTailTest into
DistributedFacetSimpleRefinementLongTailTest (with shared index building code).
Along the way, I learned that the core logic of 'refine:simple' is actually
quite different then how facet.field
& facet.pivot work (see discussion in SOLR-11733), so they do *NOT* produce the
same results in many "Long Tail"
Sitautions. As a result, many of the logic/assertions
inDistributedFacetSimpleRefinementLongTailTest are very
differnet then their counter parts in DistributedFacetPivotLongTailTest, with
detailed explanations in comments.
Hopefully this test will prove useful down the road to anyone who might want to
compare/contrast facet.pivot
with json.facet, and to prevent regressions in 'refine:simple' if/when we add
more complex refinement
approaches in the future.
There are also a few TODOs in the test related to some other small
discrepencies between json.facet and
stats.field that I opened along the way, indicating where the tests should be
modified once those issues are
addressed in json.facet...
- SOLR-11706: support for multivalued numeric fields in stats
- SOLR-11695: support for 'missing()' & 'num_vals()' (aka: 'count' from
stats.field) numeric stats
- SOLR-11725: switch from 'uncorrected stddev' to 'corrected stddev'
(cherry picked from commit 2990c88a927213177483b61fe8e6971df04fc3ed)
> json.facet refinement fails to bubble up some long tail (overrequested) terms?
> --
>
> Key: SOLR-11733
> URL: https://issues.apache.org/jira/browse/SOLR-11733
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Reporter: Hoss Man
>
> Something wonky is happening with {{json.facet}} refinement.
> "Long Tail" terms that may not be in the "top n" on every shard, but are in
> the "top n + overrequest" for at least 1 shard aren't getting refined and
> included in the aggragated response in some cases.
> I don't understand the code enough to explain this, but I have some steps to
> reproduce that i'll post in a comment shortly
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11751) Collections API: Implement collection properties that block Collections API actions
Shawn Heisey created SOLR-11751: --- Summary: Collections API: Implement collection properties that block Collections API actions Key: SOLR-11751 URL: https://issues.apache.org/jira/browse/SOLR-11751 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Affects Versions: 7.1 Reporter: Shawn Heisey Priority: Minor [~yriveiro] asked on the mailing list whether we had any ability to prevent a collection from being deleted with a property. I don't know of any way to do this currently, but it does strike me as useful, so here's the proposal: Implement some new collection properties, that when set, block certain Collections API actions. At this time, I'm not even sure that user-modifiable collection-level properties actually exist, so that may need to be implemented before this can be implemented. It *could* be done with cluster properties, but that seems like a hack. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.1) - Build # 21074 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21074/ Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates Error Message: Error from server at http://127.0.0.1:33191/solr: create the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:33191/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([E519150A6D300C6B]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.createMiniSolrCloudCluster(TestStressCloudBlindAtomicUpdates.java:132) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.cloud.AliasIntegrationTest.testErrorChecks Error Message: Error from server at http://127.0.0.1:39413/solr: deletealias the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:39413/solr: deletealias the collection time out:180s at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr
[JENKINS] Lucene-Solr-Tests-7.x - Build # 281 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/281/ 3 tests failed. FAILED: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test Error Message: Could not load collection from ZK: collection2 Stack Trace: org.apache.solr.common.SolrException: Could not load collection from ZK: collection2 at __randomizedtesting.SeedInfo.seed([1FCBAD3EC7009FA3:979F92E469FCF25B]:0) at org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1123) at org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:648) at org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:130) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:154) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:140) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:907) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:658) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.
[jira] [Created] (SOLR-11750) Collection aliases should be easier manage
Scott Stults created SOLR-11750: --- Summary: Collection aliases should be easier manage Key: SOLR-11750 URL: https://issues.apache.org/jira/browse/SOLR-11750 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI Affects Versions: 7.1, 7.0.1, 6.6 Reporter: Scott Stults Priority: Minor Currently the only way to determine which aliases apply to a collection is to go into the tree view of the cloud page and look at the contents of the aliases node. It would be handy to have this information alongside the other collection details. Also, the delete alias drop-down shows all of the aliases for all collections, not just the one that applies to the currently viewed collection. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11711) distributed pivot & field facets can processes excessive docs unneccessarily due to internal mincount=0
[
https://issues.apache.org/jira/browse/SOLR-11711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287988#comment-16287988
]
ASF GitHub Bot commented on SOLR-11711:
---
Github user HoustonPutman closed the pull request at:
https://github.com/apache/lucene-solr/pull/279
> distributed pivot & field facets can processes excessive docs unneccessarily
> due to internal mincount=0
> ---
>
> Key: SOLR-11711
> URL: https://issues.apache.org/jira/browse/SOLR-11711
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: faceting
>Affects Versions: master (8.0)
>Reporter: Houston Putman
>Assignee: Hoss Man
> Labels: pull-request-available
> Fix For: master (8.0), 7.3
>
>
> Currently while sending pivot facet requests to each shard, the
> {{facet.pivot.mincount}} is set to {{0}} if the facet is sorted by count with
> a specified limit > 0. However with a mincount of 0, the pivot facet will use
> exponentially more wasted memory for every pivot field added. This is because
> there will be a total of {{limit^(# of pivots)}} pivot values created in
> memory, even though the vast majority of them will have counts of 0, and are
> therefore useless.
> Imagine the scenario of a pivot facet with 3 levels, and
> {{facet.limit=1000}}. There will be a billion pivot values created, and there
> will almost definitely be nowhere near a billion pivot values with counts > 0.
> This likely due to the reasoning mentioned in [this comment in the original
> distributed pivot facet
> ticket|https://issues.apache.org/jira/browse/SOLR-2894?focusedCommentId=13979898].
> Basically it was thought that the refinement code would need to know that a
> count was 0 for a shard so that a refinement request wasn't sent to that
> shard. However this is checked in the code, [in this part of the refinement
> candidate
> checking|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.1.0/solr/core/src/java/org/apache/solr/handler/component/PivotFacetField.java#L275].
> Therefore if the {{pivot.mincount}} was set to 1, the non-existent values
> would either:
> * Not be known, because the {{facet.limit}} was smaller than the number of
> facet values with positive counts. This isn't an issue, because they wouldn't
> have been returned with {{pivot.mincount}} set to 0.
> * Would be known, because the {{facet.limit}} would be larger than the number
> of facet values returned. therefore this conditional would return false
> (since we are only talking about pivot facets sorted by count).
> The solution, is to use the same pivot mincount as would be used if no limit
> was specified.
> This also relates to a similar problem in field faceting that was "fixed" in
> [SOLR-8988|https://issues.apache.org/jira/browse/SOLR-8988#13324]. The
> solution was to add a flag, {{facet.distrib.mco}}, which would enable not
> choosing a mincount of 0 when unnessesary. Since this flag can only increase
> performance, and doesn't break any queries I have removed it as an option and
> replaced the code to use the feature always.
> There was one code change necessary to fix the MCO option, since the
> refinement candidate selection logic had a bug. The bug only occured with a
> minCount > 0 and limit > 0 specified. When a shard replied with less than the
> limit requested, it would assume the next maximum count on that shard was the
> {{mincount}}, where it would actually be the {{mincount-1}} (because a facet
> value with a count of mincount would have been returned). Therefore the MCO
> didn't cause any errors, but with a mincount of 1 the refinement logic always
> assumed that the shard had more values with a count of 1.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #279: SOLR-11711: Fixed minCount bug in distributed...
Github user HoustonPutman closed the pull request at: https://github.com/apache/lucene-solr/pull/279 --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Ishan Chattopadhyaya to the PMC
Congratulations and welcome Ishan! -Anshum > On Dec 8, 2017, at 5:47 AM, Adrien Grand wrote: > > I am pleased to announce that Ishan Chattopadhyaya has accepted the PMC's > invitation to join. > > Welcome Ishan! signature.asc Description: Message signed with OpenPGP
[jira] [Commented] (LUCENE-8093) TrimFilterFactory should implement MultiTermAwareComponent
[ https://issues.apache.org/jira/browse/LUCENE-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287885#comment-16287885 ] Robert Muir commented on LUCENE-8093: - Seems like a reasonable argument to me. The other main things to worry about IMO: * will the special syntax (e.g. of regex or wildcard or whatever) will confuse the filter? * will the filter always return 1:1 token for token or will it remove/add tokens (this will confuse the queryparser). Not sure there are any issues here for the trimfilter, it returns an empty string if you give it all whitespace so I think its ok there > TrimFilterFactory should implement MultiTermAwareComponent > -- > > Key: LUCENE-8093 > URL: https://issues.apache.org/jira/browse/LUCENE-8093 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > > TrimFilter will work perfectly well in CustomAnalyzer.normalize(), so it > should implement MultiTermAwareComponent -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8011) Improve similarity explanations
[
https://issues.apache.org/jira/browse/LUCENE-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287881#comment-16287881
]
ASF GitHub Bot commented on LUCENE-8011:
Github user jpountz commented on the issue:
https://github.com/apache/lucene-solr/pull/280
Thanks @mayya-sharipova, this looks great. `ant precommit` complains from
some missing docs (the build requires that all public/protected APIs have some
minimal documentation), could you fix it?
> Improve similarity explanations
> ---
>
> Key: LUCENE-8011
> URL: https://issues.apache.org/jira/browse/LUCENE-8011
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
> Labels: newdev
>
> LUCENE-7997 improves BM25 and Classic explains to better explain:
> {noformat}
> product of:
> 2.2 = scaling factor, k1 + 1
> 9.388654 = idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:
> 1.0 = n, number of documents containing term
> 17927.0 = N, total number of documents with field
> 0.9987758 = tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl))
> from:
> 979.0 = freq, occurrences of term within document
> 1.2 = k1, term saturation parameter
> 0.75 = b, length normalization parameter
> 1.0 = dl, length of field
> 1.0 = avgdl, average length of field
> {noformat}
> Previously it was pretty cryptic and used confusing terminology like
> docCount/docFreq without explanation:
> {noformat}
> product of:
> 0.016547536 = idf, computed as log(1 + (docCount - docFreq + 0.5) /
> (docFreq + 0.5)) from:
> 449.0 = docFreq
> 456.0 = docCount
> 2.1920826 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b
> * fieldLength / avgFieldLength)) from:
> 113659.0 = freq=113658
> 1.2 = parameter k1
> 0.75 = parameter b
> 2300.5593 = avgFieldLength
> 1048600.0 = fieldLength
> {noformat}
> We should fix other similarities too in the same way, they should be more
> practical.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #280: LUCENE-8011: Improve similarity explanations
Github user jpountz commented on the issue: https://github.com/apache/lucene-solr/pull/280 Thanks @mayya-sharipova, this looks great. `ant precommit` complains from some missing docs (the build requires that all public/protected APIs have some minimal documentation), could you fix it? --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1565 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1565/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) Thread[id=16422, name=jetty-launcher-3459-thread-2-EventThread, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) at org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323) at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105) at org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41) at org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244) at org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44) at org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61) at org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) Thread[id=16422, name=jetty-launcher-3459-thread-2-EventThread, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) at org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323) at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105) at org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41) at org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244) at org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44) at org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61) at org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505) at __randomizedtesting.SeedInfo.seed([2E5DB48DB0935A5]:0) Build Log: [...truncated 12475 lines...] [junit4] Suite: org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation [junit4] 2> 1741340 INFO (SUITE-TestSolrCloudWithSecureImpersonation-seed#[2E5DB48DB0935A5]-worker) [ ] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> Creating dataDir: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J1/temp/solr.cloud.TestSolrCloudWithSecureImpersonation_2E5DB48DB0935A5-001/init-core-data-001 [junit4] 2> 1741341 WARN (SUITE-TestSolrCloudWithSecureImpersonation-seed#[2E5DB48DB0935A5]-worker) [ ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=1 numCloses=1 [junit4] 2> 1741354 INFO (SUITE-TestSolrCloudWithSecureImpersonation-seed#[2E5DB48DB0935A5]-worker) [ ] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=true [junit4] 2> 1741356 INFO (SUITE-TestSolrCloudWithSecu
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.1) - Build # 979 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/979/ Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=17644, name=searcherExecutor-6041-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.1/java.lang.Thread.run(Thread.java:844) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=17644, name=searcherExecutor-6041-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.1/java.lang.Thread.run(Thread.java:844) at __randomizedtesting.SeedInfo.seed([D77BDF962F1881EB]:0) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=17644, name=searcherExecutor-6041-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.1/java.lang.Thread.run(Thread.java:844) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=17644, name=searcherExecutor-6041-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.1/java.lang.Thread.run(Thread.java:844) at __randomizedtesting.SeedInfo.seed([D77BDF962F1881EB]:0) FAILED: org.apache.solr.cloud.LeaderFailureAfterFreshStartTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:33137/_u/h Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:33137/_u/h at __randomizedtesting.SeedInfo.seed([D77BDF962F1881EB:5F2FE04C81E4EC13]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apac
Re: Heads up: Lucene 8 to require positive scores
Thanks for having a look Hoss, I added a new CHANGES entry under "Changes in Runtime Behavior" (in addition to "API Changes") and added an upgrade note in the solr changelog: https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f525ce8. Le ven. 8 déc. 2017 à 23:29, Chris Hostetter a écrit : > > Adrien: shouldn't we have a note about this in the "Changes in Runtime > Behavior" section of lucene/CHANGES.txt and the "Upgrade Notes" section of > solr/CHANGES.txt for 8.0? > > > : Date: Wed, 06 Dec 2017 13:25:10 + > : From: Adrien Grand > : Reply-To: dev@lucene.apache.org > : To: Lucene Dev > : Subject: Heads up: Lucene 8 to require positive scores > : > : Hello, > : > : I just merged a change to the Scorer contract: Scorer.score() must now > : return a positive float, see > : https://issues.apache.org/jira/browse/LUCENE-7996. > : > : As a side effect, negative boosts are now disallowed. > : > : Since FunctionScoreQuery and FunctionQuery can't ensure that the value > : source only produces positive values, they return 0 when a negative value > : is produced. > : > : This might look like an annoying constraint, but this new requirement is > : going to help build new features and optimizations, in particular > : LUCENE-4100, which helps get great speedups for top-k queries sorted by > : score. > : > > -Hoss > http://www.lucidworks.com/ > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Created] (LUCENE-8094) Improve TermInSetQuery.toString
Michael McCandless created LUCENE-8094:
--
Summary: Improve TermInSetQuery.toString
Key: LUCENE-8094
URL: https://issues.apache.org/jira/browse/LUCENE-8094
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Fix For: master (8.0), 7.3
Today a {{TermInSetQuery}} on field F and terms A, B, C returns this from
{{toString}}:
{noformat}
F:A F:B F:C
{noformat}
But this gets misleading when you embed it in a {{BooleanQuery}} as a negated
clause, which then renders like this:
{noformat}
-F:A F:B F:C
{noformat}
Making it look like only the first clause is negated when in fact they all are.
So ... I'd like to instead change it to:
{noformat}
F:(A B C)
{noformat}
I know {{Query.toString}} is simply best-effort, is not guaranteed to make
something you can then parse in any query parser back to itself, etc., but I
think we should still try to make a string that is not misleading when humans
stare at it?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8093) TrimFilterFactory should implement MultiTermAwareComponent
[ https://issues.apache.org/jira/browse/LUCENE-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287789#comment-16287789 ] Alan Woodward commented on LUCENE-8093: --- TrimFilter would I think normally be used with a Tokenizer that doesn't split things up, like KeywordTokenizer or NGramTokenizer, in which case removing surrounding whitespace seems like a natural normalization to me, much like lowercasing. And the issue with stemmers is that they can completely change the token, such that prefixes or fuzzy queries won't make sense, which doesn't apply here? > TrimFilterFactory should implement MultiTermAwareComponent > -- > > Key: LUCENE-8093 > URL: https://issues.apache.org/jira/browse/LUCENE-8093 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > > TrimFilter will work perfectly well in CustomAnalyzer.normalize(), so it > should implement MultiTermAwareComponent -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7996) Should we require positive scores?
[ https://issues.apache.org/jira/browse/LUCENE-7996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287778#comment-16287778 ] ASF subversion and git services commented on LUCENE-7996: - Commit f525ce8fbb30367be2d816be303ee7c1b8d4d0ae in lucene-solr's branch refs/heads/master from [~jpountz] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f525ce8 ] LUCENE-7996: Add a note to the changes in runtime behaviour and to the solr upgrade notes. > Should we require positive scores? > -- > > Key: LUCENE-7996 > URL: https://issues.apache.org/jira/browse/LUCENE-7996 > Project: Lucene - Core > Issue Type: Wish >Reporter: Adrien Grand >Priority: Minor > Fix For: master (8.0) > > Attachments: LUCENE-7996.patch, LUCENE-7996.patch, LUCENE-7996.patch > > > Having worked on MAXSCORE recently, things would be simpler if we required > that scores are positive. Practically, this would mean > - forbidding/fixing similarities that may produce negative scores (we have > some of them) > - forbidding things like negative boosts > So I'd be curious to have opinions whether this would be a sane requirement > or whether we need to be able to cope with negative scores eg. because some > similarities that we want to support produce negative scores by design. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Ishan Chattopadhyaya to the PMC
Congrats and welcome Ishan! From: dev@lucene.apache.org At: 12/12/17 14:06:15To: dev@lucene.apache.org Subject: Re: Welcome Ishan Chattopadhyaya to the PMC congrats and welcome Ishan! Tommaso Il giorno mar 12 dic 2017 alle ore 12:13 Shalin Shekhar Mangar ha scritto: Congratulations and welcome Ishan! On Fri, Dec 8, 2017 at 7:17 PM, Adrien Grand wrote: > I am pleased to announce that Ishan Chattopadhyaya has accepted the PMC's > invitation to join. > > Welcome Ishan! -- Regards, Shalin Shekhar Mangar. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11740) bin/solr stop command always throws Connection refused
[
https://issues.apache.org/jira/browse/SOLR-11740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-11740:
---
Component/s: scripts and tools
> bin/solr stop command always throws Connection refused
> --
>
> Key: SOLR-11740
> URL: https://issues.apache.org/jira/browse/SOLR-11740
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Reporter: Varun Thacker
>Assignee: Christine Poerschke
>Priority: Blocker
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11740.patch
>
>
> Start solr using {{./bin/solr start -e cloud -noprompt}} and then try
> stopping it. I ran into this problem every time I stopping solr on master.
> I'm using Java9 and it works fine on Solr 7.1 ( haven't checked on the 7_2
> branch yet )
> [master] ~/apache-work/lucene-solr/solr$ ./bin/solr stop -all
> Sending stop command to Solr running on port 7574 ... waiting up to 180
> seconds to allow Jetty process 40360 to stop gracefully.
> Sending stop command to Solr running on port 8983 ... waiting up to 180
> seconds to allow Jetty process 40263 to stop gracefully.
> java.net.ConnectException: Connection refused (Connection refused)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:244)
> at org.eclipse.jetty.start.Main.stop(Main.java:535)
> at org.eclipse.jetty.start.Main.stop(Main.java:511)
> at org.eclipse.jetty.start.Main.doStop(Main.java:499)
> at org.eclipse.jetty.start.Main.start(Main.java:404)
> at org.eclipse.jetty.start.Main.main(Main.java:76)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11749) regression-test-like functionality for bin/solr*
[ https://issues.apache.org/jira/browse/SOLR-11749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-11749: --- Attachment: SOLR-11749.patch minimal start > regression-test-like functionality for bin/solr* > > > Key: SOLR-11749 > URL: https://issues.apache.org/jira/browse/SOLR-11749 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Reporter: Christine Poerschke >Priority: Minor > Attachments: SOLR-11749.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11749) regression-test-like functionality for bin/solr*
[ https://issues.apache.org/jira/browse/SOLR-11749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-11749: --- Component/s: scripts and tools > regression-test-like functionality for bin/solr* > > > Key: SOLR-11749 > URL: https://issues.apache.org/jira/browse/SOLR-11749 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Reporter: Christine Poerschke >Priority: Minor > Attachments: SOLR-11749.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11749) regression-test-like functionality for bin/solr*
Christine Poerschke created SOLR-11749: -- Summary: regression-test-like functionality for bin/solr* Key: SOLR-11749 URL: https://issues.apache.org/jira/browse/SOLR-11749 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Christine Poerschke Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.2-Linux (64bit/jdk1.8.0_144) - Build # 51 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Linux/51/ Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestTolerantUpdateProcessorRandomCloud Error Message: Error from server at http://127.0.0.1:36423/solr: create the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:36423/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([EDEAA8BC2CAEE27D]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.TestTolerantUpdateProcessorRandomCloud.createMiniSolrCloudCluster(TestTolerantUpdateProcessorRandomCloud.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.HttpPartitionTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:38165/collMinRf_1x3 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:38165/collMinRf_1x3 at __randomizedtesting.SeedInfo.seed([EDEAA8BC2CAEE27D:65BE976682528F85]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.HttpPartitionTest.r
[jira] [Commented] (SOLR-11740) bin/solr stop command always throws Connection refused
[
https://issues.apache.org/jira/browse/SOLR-11740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287747#comment-16287747
]
Christine Poerschke commented on SOLR-11740:
Looks like {{bin/solr.cmd}} is unaffected i.e. no changes needed for that.
> bin/solr stop command always throws Connection refused
> --
>
> Key: SOLR-11740
> URL: https://issues.apache.org/jira/browse/SOLR-11740
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Christine Poerschke
>Priority: Blocker
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11740.patch
>
>
> Start solr using {{./bin/solr start -e cloud -noprompt}} and then try
> stopping it. I ran into this problem every time I stopping solr on master.
> I'm using Java9 and it works fine on Solr 7.1 ( haven't checked on the 7_2
> branch yet )
> [master] ~/apache-work/lucene-solr/solr$ ./bin/solr stop -all
> Sending stop command to Solr running on port 7574 ... waiting up to 180
> seconds to allow Jetty process 40360 to stop gracefully.
> Sending stop command to Solr running on port 8983 ... waiting up to 180
> seconds to allow Jetty process 40263 to stop gracefully.
> java.net.ConnectException: Connection refused (Connection refused)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:244)
> at org.eclipse.jetty.start.Main.stop(Main.java:535)
> at org.eclipse.jetty.start.Main.stop(Main.java:511)
> at org.eclipse.jetty.start.Main.doStop(Main.java:499)
> at org.eclipse.jetty.start.Main.start(Main.java:404)
> at org.eclipse.jetty.start.Main.main(Main.java:76)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 2218 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2218/
15 tests failed.
FAILED: org.apache.solr.cloud.AddReplicaTest.test
Error Message:
core_node6:{"core":"addreplicatest_coll_shard1_replica_n5","base_url":"http://127.0.0.1:39182/solr","node_name":"127.0.0.1:39182_solr","state":"active","type":"NRT"}
Stack Trace:
java.lang.AssertionError:
core_node6:{"core":"addreplicatest_coll_shard1_replica_n5","base_url":"http://127.0.0.1:39182/solr","node_name":"127.0.0.1:39182_solr","state":"active","type":"NRT"}
at
__randomizedtesting.SeedInfo.seed([797A54C4371B097F:F12E6B1E99E76487]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.solr.cloud.AddReplicaTest.test(AddReplicaTest.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
FAILED:
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateWithDefaultConfigSet
Error Message:
Stack Trace:
java.lang.Nu
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 339 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/339/ Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test Error Message: Could not find collection:collection2 Stack Trace: java.lang.AssertionError: Could not find collection:collection2 at __randomizedtesting.SeedInfo.seed([8179C33DAEBEF7A1:92DFCE700429A59]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:140) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:907) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:612) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lu
[jira] [Commented] (LUCENE-8093) TrimFilterFactory should implement MultiTermAwareComponent
[
https://issues.apache.org/jira/browse/LUCENE-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287706#comment-16287706
]
Robert Muir commented on LUCENE-8093:
-
Well i don't think its a truly formal definition, just mentioning it for
discussion. Some of the normalization components can change the length of the
string (e.g. ascii folder or german normalizer) in rarer cases but in general
they are just normalizing characters and won't confuse e.g. wildcard {{?}}
operator or regexes "too much".
> TrimFilterFactory should implement MultiTermAwareComponent
> --
>
> Key: LUCENE-8093
> URL: https://issues.apache.org/jira/browse/LUCENE-8093
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
>
> TrimFilter will work perfectly well in CustomAnalyzer.normalize(), so it
> should implement MultiTermAwareComponent
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8086) G3d wrapper: Improve circles for non spherical planets
[
https://issues.apache.org/jira/browse/LUCENE-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287651#comment-16287651
]
ASF GitHub Bot commented on LUCENE-8086:
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/288#discussion_r155938328
--- Diff:
lucene/spatial-extras/src/java/org/apache/lucene/spatial/spatial4j/Geo3dShapeFactory.java
---
@@ -150,10 +176,21 @@ public Rectangle rect(double minX, double maxX,
double minY, double maxY) {
@Override
public Circle circle(double x, double y, double distance) {
-GeoCircle circle = GeoCircleFactory.makeGeoCircle(planetModel,
-y * DistanceUtils.DEGREES_TO_RADIANS,
-x * DistanceUtils.DEGREES_TO_RADIANS,
-distance * DistanceUtils.DEGREES_TO_RADIANS);
+GeoCircle circle;
+if (planetModel.ab == planetModel.c) {
--- End diff --
@DaddyWri comments?
> G3d wrapper: Improve circles for non spherical planets
> --
>
> Key: LUCENE-8086
> URL: https://issues.apache.org/jira/browse/LUCENE-8086
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
>Reporter: Ignacio Vera
>
> Hi [~dsmiley],
> The purpose of this ticket is to add a new circle shape (GeoExactCircle) for
> non-spherical planets and therefore remove the method relate from
> Geo3dCircleShape. The patch will include some simplifications on the wrapper
> and some refactoring of the tests.
> I will open shortly a pull request.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8086) G3d wrapper: Improve circles for non spherical planets
[
https://issues.apache.org/jira/browse/LUCENE-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287650#comment-16287650
]
ASF GitHub Bot commented on LUCENE-8086:
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/288#discussion_r155938315
--- Diff:
lucene/spatial-extras/src/test/org/apache/lucene/spatial/spatial4j/ShapeRectRelationTestCase.java
---
@@ -28,15 +28,15 @@
import static
org.locationtech.spatial4j.distance.DistanceUtils.DEGREES_TO_RADIANS;
-public abstract class Geo3dShapeRectRelationTestCase extends
RandomizedShapeTestCase {
+public abstract class ShapeRectRelationTestCase extends
RandomizedShapeTestCase {
protected final static double RADIANS_PER_DEGREE = Math.PI/180.0;
@Rule
public final TestLog testLog = TestLog.instance;
protected int maxRadius = 180;
- public Geo3dShapeRectRelationTestCase() {
+ public ShapeRectRelationTestCase() {
super(SpatialContext.GEO);
--- End diff --
I think the subclass should pass in the context.
> G3d wrapper: Improve circles for non spherical planets
> --
>
> Key: LUCENE-8086
> URL: https://issues.apache.org/jira/browse/LUCENE-8086
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
>Reporter: Ignacio Vera
>
> Hi [~dsmiley],
> The purpose of this ticket is to add a new circle shape (GeoExactCircle) for
> non-spherical planets and therefore remove the method relate from
> Geo3dCircleShape. The patch will include some simplifications on the wrapper
> and some refactoring of the tests.
> I will open shortly a pull request.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #288: LUCENE-8086
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/288#discussion_r155938328
--- Diff:
lucene/spatial-extras/src/java/org/apache/lucene/spatial/spatial4j/Geo3dShapeFactory.java
---
@@ -150,10 +176,21 @@ public Rectangle rect(double minX, double maxX,
double minY, double maxY) {
@Override
public Circle circle(double x, double y, double distance) {
-GeoCircle circle = GeoCircleFactory.makeGeoCircle(planetModel,
-y * DistanceUtils.DEGREES_TO_RADIANS,
-x * DistanceUtils.DEGREES_TO_RADIANS,
-distance * DistanceUtils.DEGREES_TO_RADIANS);
+GeoCircle circle;
+if (planetModel.ab == planetModel.c) {
--- End diff --
@DaddyWri comments?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #288: LUCENE-8086
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/288#discussion_r155938315
--- Diff:
lucene/spatial-extras/src/test/org/apache/lucene/spatial/spatial4j/ShapeRectRelationTestCase.java
---
@@ -28,15 +28,15 @@
import static
org.locationtech.spatial4j.distance.DistanceUtils.DEGREES_TO_RADIANS;
-public abstract class Geo3dShapeRectRelationTestCase extends
RandomizedShapeTestCase {
+public abstract class ShapeRectRelationTestCase extends
RandomizedShapeTestCase {
protected final static double RADIANS_PER_DEGREE = Math.PI/180.0;
@Rule
public final TestLog testLog = TestLog.instance;
protected int maxRadius = 180;
- public Geo3dShapeRectRelationTestCase() {
+ public ShapeRectRelationTestCase() {
super(SpatialContext.GEO);
--- End diff --
I think the subclass should pass in the context.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Ishan Chattopadhyaya to the PMC
congrats and welcome Ishan! Tommaso Il giorno mar 12 dic 2017 alle ore 12:13 Shalin Shekhar Mangar < shalinman...@gmail.com> ha scritto: > Congratulations and welcome Ishan! > > On Fri, Dec 8, 2017 at 7:17 PM, Adrien Grand wrote: > > I am pleased to announce that Ishan Chattopadhyaya has accepted the PMC's > > invitation to join. > > > > Welcome Ishan! > > > > -- > Regards, > Shalin Shekhar Mangar. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Commented] (LUCENE-8091) Better nearest-neighbor queries
[
https://issues.apache.org/jira/browse/LUCENE-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287631#comment-16287631
]
Adrien Grand commented on LUCENE-8091:
--
This implementation requires values to be both indexed with points and readable
with doc values. The thing that makes it hard with more than 1 dimension is
that we do not have a canonical way to represent vectors in doc values, this
requires a custom encoding with a binary doc value field. So it would be doable
but either the API would be a bit hard to use or we would have to make
assumptions as to how the float[] is encoded in a binary field.
> Better nearest-neighbor queries
> ---
>
> Key: LUCENE-8091
> URL: https://issues.apache.org/jira/browse/LUCENE-8091
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8091.patch
>
>
> LatLonPoint.nearest is very efficient at identifying the top-k documents
> sorted by distance from a given point, by working directly on the BKD tree.
> This doesn't support filtering though, so if you need to filter by another
> property, you need to switch to querying on the filter and sorting by a
> LatLonPointSortField. Unfortunately this requires visiting all documents that
> match the filter.
> We could leverage the new {{setMinCompetitiveScore}} API introduced in
> LUCENE-4100 in order to allow for retrieval of nearest neighbors with
> arbitrary filters, by recomputing a bounding-box when a new minimum
> competitive score is set.
> In the future we could also leverage this to speed up queries that are
> boosted by distance. For instance if the final score is a weighted sum of the
> score on a text field and a distance-based score, and the minimum competitive
> score gets higher than the maximum score that may be produced on the text
> field at some point, then we could dynamically prune hits based on the
> distance.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-7.2 - Build # 10 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.2/10/ 1 tests failed. FAILED: org.apache.solr.store.blockcache.BlockDirectoryTest.testRandomAccessWrites Error Message: Direct buffer memory Stack Trace: java.lang.OutOfMemoryError: Direct buffer memory at java.nio.Bits.reserveMemory(Bits.java:694) at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) at org.apache.solr.store.blockcache.BlockCache.(BlockCache.java:71) at org.apache.solr.store.blockcache.BlockDirectoryTest.setUp(BlockDirectoryTest.java:119) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:968) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 14099 lines...] [junit4] Suite: org.apache.solr.store.blockcache.BlockDirectoryTest [junit4] 2> Creating dataDir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.2/solr/build/solr-core/test/J2/temp/solr.store.blockcache.BlockDirectoryTest_F30493D96233D566-001/init-core-data-001 [junit4] 2> 7022120 WARN (SUITE-BlockDirectoryTest-seed#[F30493D9
[jira] [Commented] (LUCENE-8093) TrimFilterFactory should implement MultiTermAwareComponent
[ https://issues.apache.org/jira/browse/LUCENE-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287592#comment-16287592 ] Alan Woodward commented on LUCENE-8093: --- Ah, ok. Maybe I should add some javadoc to MultiTermAwareComponent making that clear? > TrimFilterFactory should implement MultiTermAwareComponent > -- > > Key: LUCENE-8093 > URL: https://issues.apache.org/jira/browse/LUCENE-8093 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > > TrimFilter will work perfectly well in CustomAnalyzer.normalize(), so it > should implement MultiTermAwareComponent -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8093) TrimFilterFactory should implement MultiTermAwareComponent
[ https://issues.apache.org/jira/browse/LUCENE-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287565#comment-16287565 ] Robert Muir commented on LUCENE-8093: - Any stemmer will work "perfectly well" too, until it gets to the user. today we don't do this for tokenfilters that change the length of a string. > TrimFilterFactory should implement MultiTermAwareComponent > -- > > Key: LUCENE-8093 > URL: https://issues.apache.org/jira/browse/LUCENE-8093 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > > TrimFilter will work perfectly well in CustomAnalyzer.normalize(), so it > should implement MultiTermAwareComponent -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11740) bin/solr stop command always throws Connection refused
[
https://issues.apache.org/jira/browse/SOLR-11740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-11740:
---
Attachment: SOLR-11740.patch
Thanks everyone for noticing and looking into this! Yes, looks like SOLR-9137
broke this i.e. the first instance is stopped successfully and then the 'local'
STOP_PORT variable carries over to the stopping of subsequent instances which
naturally won't work.
Attached patch for {{bin/solr}} avoids this by giving the local variable
another name, perhaps there is a different way to achieve the equivalent? Will
try and figure out the {{bin/solr.cmd}} equivalent next.
> bin/solr stop command always throws Connection refused
> --
>
> Key: SOLR-11740
> URL: https://issues.apache.org/jira/browse/SOLR-11740
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Christine Poerschke
>Priority: Blocker
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11740.patch
>
>
> Start solr using {{./bin/solr start -e cloud -noprompt}} and then try
> stopping it. I ran into this problem every time I stopping solr on master.
> I'm using Java9 and it works fine on Solr 7.1 ( haven't checked on the 7_2
> branch yet )
> [master] ~/apache-work/lucene-solr/solr$ ./bin/solr stop -all
> Sending stop command to Solr running on port 7574 ... waiting up to 180
> seconds to allow Jetty process 40360 to stop gracefully.
> Sending stop command to Solr running on port 8983 ... waiting up to 180
> seconds to allow Jetty process 40263 to stop gracefully.
> java.net.ConnectException: Connection refused (Connection refused)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:244)
> at org.eclipse.jetty.start.Main.stop(Main.java:535)
> at org.eclipse.jetty.start.Main.stop(Main.java:511)
> at org.eclipse.jetty.start.Main.doStop(Main.java:499)
> at org.eclipse.jetty.start.Main.start(Main.java:404)
> at org.eclipse.jetty.start.Main.main(Main.java:76)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11740) bin/solr stop command always throws Connection refused
[
https://issues.apache.org/jira/browse/SOLR-11740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke reassigned SOLR-11740:
--
Assignee: Christine Poerschke
> bin/solr stop command always throws Connection refused
> --
>
> Key: SOLR-11740
> URL: https://issues.apache.org/jira/browse/SOLR-11740
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Christine Poerschke
>Priority: Blocker
> Fix For: 7.2, master (8.0)
>
>
> Start solr using {{./bin/solr start -e cloud -noprompt}} and then try
> stopping it. I ran into this problem every time I stopping solr on master.
> I'm using Java9 and it works fine on Solr 7.1 ( haven't checked on the 7_2
> branch yet )
> [master] ~/apache-work/lucene-solr/solr$ ./bin/solr stop -all
> Sending stop command to Solr running on port 7574 ... waiting up to 180
> seconds to allow Jetty process 40360 to stop gracefully.
> Sending stop command to Solr running on port 8983 ... waiting up to 180
> seconds to allow Jetty process 40263 to stop gracefully.
> java.net.ConnectException: Connection refused (Connection refused)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:244)
> at org.eclipse.jetty.start.Main.stop(Main.java:535)
> at org.eclipse.jetty.start.Main.stop(Main.java:511)
> at org.eclipse.jetty.start.Main.doStop(Main.java:499)
> at org.eclipse.jetty.start.Main.start(Main.java:404)
> at org.eclipse.jetty.start.Main.main(Main.java:76)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8093) TrimFilterFactory should implement MultiTermAwareComponent
Alan Woodward created LUCENE-8093: - Summary: TrimFilterFactory should implement MultiTermAwareComponent Key: LUCENE-8093 URL: https://issues.apache.org/jira/browse/LUCENE-8093 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor TrimFilter will work perfectly well in CustomAnalyzer.normalize(), so it should implement MultiTermAwareComponent -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8092) TestRandomChains failure
Alan Woodward created LUCENE-8092: - Summary: TestRandomChains failure Key: LUCENE-8092 URL: https://issues.apache.org/jira/browse/LUCENE-8092 Project: Lucene - Core Issue Type: Bug Reporter: Alan Woodward https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.2/1/ ant test -Dtestcase=TestRandomChains -Dtests.method=testRandomChains -Dtests.seed=C006DAD2E1FC77AF -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/Users/romseygeek/projects/lucene-test-data/enwiki.random.lines.txt -Dtests.locale=tr -Dtests.timezone=Europe/Simferopol -Dtests.asserts=true -Dtests.file.encoding=UTF-8 Reproduces locally on 7.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.1) - Build # 340 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/340/ Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.lucene.index.TestBackwardsCompatibility Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J1\temp\lucene.index.TestBackwardsCompatibility_F0AB425F50FF8E66-001\2.4.1-nocfs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J1\temp\lucene.index.TestBackwardsCompatibility_F0AB425F50FF8E66-001\2.4.1-nocfs-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J1\temp\lucene.index.TestBackwardsCompatibility_F0AB425F50FF8E66-001\2.4.1-nocfs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J1\temp\lucene.index.TestBackwardsCompatibility_F0AB425F50FF8E66-001\2.4.1-nocfs-001 at __randomizedtesting.SeedInfo.seed([F0AB425F50FF8E66]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.lucene.codecs.blockterms.TestFixedGapPostingsFormat Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestFixedGapPostingsFormat_2B738DC8CE26C20C-001\testPostingsFormat.testExact-006: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestFixedGapPostingsFormat_2B738DC8CE26C20C-001\testPostingsFormat.testExact-006 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestFixedGapPostingsFormat_2B738DC8CE26C20C-001\testPostingsFormat.testExact-006\_0_LuceneFixedGap_0.tib: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestFixedGapPostingsFormat_2B738DC8CE26C20C-001\testPostingsFormat.testExact-006\_0_LuceneFixedGap_0.tib C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestFixedGapPostingsFormat_2B738DC8CE26C20C-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestFixedGapPostingsFormat_2B738DC8CE26C20C-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestFixedGapPostingsFormat_2B738DC8CE26C20C-001\testPostingsFormat.testExact-006: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestFixedGapPostingsFormat_2B738DC8CE26C20C-001\testPostingsFormat.testExact-006 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestFixedGapPostingsFormat_2B738DC8CE26C20C-001\testPostingsFormat.testExact-006\_0_LuceneFixedGap_0.tib: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestFixedGapPostingsFormat_2B738DC8CE26C20C-001\testPostingsFormat.testExact-006\_0_LuceneFixedGap_0.tib C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.1) - Build # 978 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/978/ Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestHdfsCloudBackupRestore Error Message: Timed out waiting for Mini HDFS Cluster to start Stack Trace: java.io.IOException: Timed out waiting for Mini HDFS Cluster to start at __randomizedtesting.SeedInfo.seed([40874ADE0025D71E]:0) at org.apache.hadoop.hdfs.MiniDFSCluster.waitClusterUp(MiniDFSCluster.java:1207) at org.apache.hadoop.hdfs.MiniDFSCluster.initMiniDFSCluster(MiniDFSCluster.java:840) at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:746) at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:616) at org.apache.solr.cloud.hdfs.HdfsTestUtil.setupClass(HdfsTestUtil.java:105) at org.apache.solr.cloud.hdfs.HdfsTestUtil.setupClass(HdfsTestUtil.java:63) at org.apache.solr.cloud.TestHdfsCloudBackupRestore.setupClass(TestHdfsCloudBackupRestore.java:100) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsNNFailoverTest Error Message: Timed out waiting for Mini HDFS Cluster to start Stack Trace: java.io.IOException: Timed out waiting for Mini HDFS Cluster to start at __randomizedtesting.SeedInfo.seed([40874ADE0025D71E]:0) at org.apache.hadoop.hdfs.MiniDFSCluster.waitClusterUp(MiniDFSCluster.java:1207) at org.apache.hadoop.hdfs.MiniDFSCluster.initMiniDFSCluster(MiniDFSCluster.java:840) at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:746) at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:616) at org.apache.solr.cloud.hdfs.HdfsTestUtil.setupClass(HdfsTestUtil.java:105) at org.apache.solr.cloud.hdfs.HdfsNNFailoverTest.setupClass(HdfsNNFailoverTest.java:43) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:89
Re: Welcome Ishan Chattopadhyaya to the PMC
Congratulations and welcome Ishan! On Fri, Dec 8, 2017 at 7:17 PM, Adrien Grand wrote: > I am pleased to announce that Ishan Chattopadhyaya has accepted the PMC's > invitation to join. > > Welcome Ishan! -- Regards, Shalin Shekhar Mangar. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.2-Windows (32bit/jdk1.8.0_144) - Build # 13 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Windows/13/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseParallelGC 6 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-7.2-Windows\lucene\build\misc\test\J0\temp\lucene.store.TestRAFDirectory_F943233552C328F-001\tempDir-004: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\misc\test\J0\temp\lucene.store.TestRAFDirectory_F943233552C328F-001\tempDir-004 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\misc\test\J0\temp\lucene.store.TestRAFDirectory_F943233552C328F-001\tempDir-004: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\misc\test\J0\temp\lucene.store.TestRAFDirectory_F943233552C328F-001\tempDir-004 at __randomizedtesting.SeedInfo.seed([F943233552C328F]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.lucene.replicator.IndexReplicationClientTest.testConsistencyOnExceptions Error Message: Captured an uncaught exception in thread: Thread[id=67, name=ReplicationThread-index, state=RUNNABLE, group=TGRP-IndexReplicationClientTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=67, name=ReplicationThread-index, state=RUNNABLE, group=TGRP-IndexReplicationClientTest] at __randomizedtesting.SeedInfo.seed([6B0F352AF55712E2:E481D28AE73BE11D]:0) Caused by: java.lang.AssertionError: handler failed too many times: -1 at __randomizedtesting.SeedInfo.seed([6B0F352AF55712E2]:0) at org.apache.lucene.replicator.IndexReplicationClientTest$4.handleUpdateException(IndexReplicationClientTest.java:304) at org.apache.lucene.replicator.ReplicationClient$ReplicationThread.run(ReplicationClient.java:77) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CreateCollectionCleanupTest Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.CreateCollectionCleanupTest_BBDBE0D167F59093-001\tempDir-001\zookeeper\server1\data\version-2: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.CreateCollectionCleanupTest_BBDBE0D167F59093-001\tempDir-001\zookeeper\server1\data\version-2 C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.CreateCollectionCleanupTest_BBDBE0D167F59093-001\tempDir-001\zookeeper\server1\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.CreateCollectionCleanupTest_BBDBE0D167F59093-001\tempDir-001\zookeeper\server1\data C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.CreateCollectionCleanupTest_BBDBE0D167F59093-001\tempDir-001\zookeeper\server1: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.CreateCollectionCleanupTest_BBDBE0D167F59093-001\tempDir-001\zookeeper\server1 C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.CreateCollectionCleanupTest_BBDBE0D167F59093-001\tempDir-001\zookeeper: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.CreateCollectionCle
[JENKINS-EA] Lucene-Solr-7.2-Linux (64bit/jdk-10-ea+32) - Build # 50 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Linux/50/ Java: 64bit/jdk-10-ea+32 -XX:-UseCompressedOops -XX:+UseParallelGC 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=5242, name=searcherExecutor-2366-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074) at java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@10-ea/java.lang.Thread.run(Thread.java:844) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=5242, name=searcherExecutor-2366-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074) at java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@10-ea/java.lang.Thread.run(Thread.java:844) at __randomizedtesting.SeedInfo.seed([2144D2898B56367D]:0) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=5242, name=searcherExecutor-2366-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074) at java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@10-ea/java.lang.Thread.run(Thread.java:844) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=5242, name=searcherExecutor-2366-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074) at java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@10-ea/java.lang.Thread.run(Thread.java:844) at __randomizedtesting.SeedInfo.seed([2144D2898B56367D]:0) FAILED: org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testStopAllStartAll Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([2144D2898B56367D:577ACDFACA619B52]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:185)
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_144) - Build # 21072 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21072/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.testSimple Error Message: Timeout waiting for all live and active Stack Trace: java.lang.AssertionError: Timeout waiting for all live and active at __randomizedtesting.SeedInfo.seed([9E0916063CE510AC:A6BA32F81B16C47D]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.testSimple(AutoAddReplicasPlanActionTest.java:123) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 12120 lines...] [junit4] Suite: org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.
