Get size occupied by each field in lucene index
Hello, I'm using lucene 6.3.0 I have an index which has 500k documents with each document having 53 fields. The problem is the index size is becoming an issue day by day so we are planning to weed out or trim some fields. I'm trying to get estimate size of each field using luke but the tool only shows me no. of terms and frequencies which may not suggest exact size of that field inside the index. Is there any other way to know the size of individual fields or am I missing something in luke? -- View this message in context: http://lucene.472066.n3.nabble.com/Get-size-occupied-by-each-field-in-lucene-index-tp4347856.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_141) - Build # 20207 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20207/ Java: 64bit/jdk1.8.0_141 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.LeaderElectionContextKeyTest.test Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([37AC31AA706E6CA6:BFF80E70DE92015E]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.cloud.LeaderElectionContextKeyTest.test(LeaderElectionContextKeyTest.java:88) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 11029 lines...] [junit4] Suite: org.apache.solr.cloud.LeaderElectionContextKeyTest [junit4] 2> Creating dataDir:
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_141) - Build # 6786 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6786/ Java: 64bit/jdk1.8.0_141 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.update.HardAutoCommitTest.testCommitWithin Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([CC8A71C53B74FE40:76581EBDB85A1055]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:886) at org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: 039 request was:q=id:529==0=20=2.2 at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:879) ... 40 more Build Log: [...truncated 11 lines...] ERROR: Error fetching remote repo 'origin'
[jira] [Commented] (SOLR-10734) Multithreaded test/support for AtomicURP broken
[
https://issues.apache.org/jira/browse/SOLR-10734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102756#comment-16102756
]
ASF subversion and git services commented on SOLR-10734:
Commit edff113e13f2a108d2f4177da3e88cf6f3402b23 in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=edff113 ]
SOLR-10734: AtomicUpdateProcessorFactoryTest was not truly multithreaded
> Multithreaded test/support for AtomicURP broken
> ---
>
> Key: SOLR-10734
> URL: https://issues.apache.org/jira/browse/SOLR-10734
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
> Attachments: log-snippet, Screen Shot 2017-05-31 at 4.50.23 PM.png,
> SOLR-10734.patch
>
>
> The multithreaded test doesn't actually start the threads, but only invokes
> the run directly. The join afterwards doesn't do anything, hence.
> {code}
> diff --git
> a/solr/core/src/test/org/apache/solr/update/processor/AtomicUpdateProcessorFactoryTest.java
>
> b/solr/core/src/test/org/apache/solr/update/processor/AtomicUpdateProcessorFactoryTest.java
> index f3f833d..10b7770 100644
> ---
> a/solr/core/src/test/org/apache/solr/update/processor/AtomicUpdateProcessorFactoryTest.java
> +++
> b/solr/core/src/test/org/apache/solr/update/processor/AtomicUpdateProcessorFactoryTest.java
> @@ -238,7 +238,7 @@ public class AtomicUpdateProcessorFactoryTest extends
> SolrTestCaseJ4 {
>}
> }
>};
> - t.run();
> + t.run(); // red flag, shouldn't this be t.start?
>threads.add(t);
>finalCount += index; //int_i
> }
> {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-10814) Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos authentication
[ https://issues.apache.org/jira/browse/SOLR-10814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101521#comment-16101521 ] Don Bosco Durai commented on SOLR-10814: bq. No. getShortName() is not backward compatible. How are you going to switch between the both? What I meant was, all existing code will continue using getPrincipal(). And for anyone writing new authorization plugin, they can use either of the two methods. Those who want to keep to play it safe, can use getShortName() and not worry about the underlying authentication mode. And those who want to do additional processing then can use getPrincipal(). > Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos > authentication > --- > > Key: SOLR-10814 > URL: https://issues.apache.org/jira/browse/SOLR-10814 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.2 >Reporter: Hrishikesh Gadre > > Solr allows configuring roles to control user access to the system. This is > accomplished through rule-based permission definitions which are assigned to > users. > The authorization framework in Solr passes the information about the request > (to be authorized) using an instance of AuthorizationContext class. Currently > the only way to extract authenticated user is via getUserPrincipal() method > which returns an instance of java.security.Principal class. The > RuleBasedAuthorizationPlugin implementation invokes getName() method on the > Principal instance to fetch the list of associated roles. > https://github.com/apache/lucene-solr/blob/2271e73e763b17f971731f6f69d6ffe46c40b944/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L156 > In case of basic authentication mechanism, the principal is the userName. > Hence it works fine. But in case of kerberos authentication, the user > principal also contains the RELM information e.g. instead of foo, it would > return f...@example.com. This means if the user changes the authentication > mechanism, he would also need to change the user-role mapping in > authorization section to use f...@example.com instead of foo. This is not > good from usability perspective. -- 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-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101574#comment-16101574
]
ASF subversion and git services commented on SOLR-11130:
Commit 917a116b90ce908ec3b0669431864b9807de74b6 in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=917a116 ]
SOLR-11130: V2Request in SolrJ should return the correct collection name so
that the request is forwarded to the correct node
> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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] [Updated] (SOLR-11130) V2Request in SolrJ should return the correct collection name so that the request is forwarded to the correct node
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-11130:
--
Summary: V2Request in SolrJ should return the correct collection name so
that the request is forwarded to the correct node (was: SolrJ routes
V2Request to wrong nodes and such nodes are not able to forward these requests
correctly)
> V2Request in SolrJ should return the correct collection name so that the
> request is forwarded to the correct node
> ---
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101586#comment-16101586
]
ASF subversion and git services commented on SOLR-11130:
Commit 3a8bcad5c6e83b4c66d65e1226cb2ef860c4 in lucene-solr's branch
refs/heads/branch_7_0 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3a8bcad ]
SOLR-11130: V2Request is SolrJ should return the correct collection name
> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101587#comment-16101587
]
ASF subversion and git services commented on SOLR-11130:
Commit e79d1f2470e3698a95a54354be1b6d54cf322dba in lucene-solr's branch
refs/heads/branch_7_0 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e79d1f2 ]
SOLR-11130: V2Request in SolrJ should return the correct collection name so
that the request is forwarded to the correct node
> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101588#comment-16101588
]
ASF subversion and git services commented on SOLR-11130:
Commit 0fc791af379721bc9e30782011e378b3c6455aae in lucene-solr's branch
refs/heads/branch_7_0 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0fc791a ]
SOLR-11130: change was added in wrong version
> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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-NightlyTests-master - Build # 1363 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1363/
6 tests failed.
FAILED: org.apache.solr.cloud.HttpPartitionTest.test
Error Message:
Didn't see all replicas for shard shard1 in c8n_1x2 come up within 9 ms!
ClusterState: { "collMinRf_1x3":{ "pullReplicas":"0",
"replicationFactor":"1", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node4":{ "core":"collMinRf_1x3_shard1_replica_n1",
"base_url":"http://127.0.0.1:43595/_/t;,
"node_name":"127.0.0.1:43595__%2Ft", "state":"active",
"type":"NRT"}, "core_node5":{
"core":"collMinRf_1x3_shard1_replica_n2",
"base_url":"http://127.0.0.1:34265/_/t;,
"node_name":"127.0.0.1:34265__%2Ft", "state":"active",
"type":"NRT", "leader":"true"}, "core_node6":{
"core":"collMinRf_1x3_shard1_replica_n3",
"base_url":"http://127.0.0.1:43409/_/t;,
"node_name":"127.0.0.1:43409__%2Ft", "state":"active",
"type":"NRT", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false", "nrtReplicas":"3",
"tlogReplicas":"0"}, "collection1":{ "pullReplicas":"0",
"replicationFactor":"1", "shards":{ "shard1":{
"range":"8000-", "state":"active",
"replicas":{"core_node4":{ "core":"collection1_shard1_replica_n3",
"base_url":"http://127.0.0.1:43595/_/t;,
"node_name":"127.0.0.1:43595__%2Ft", "state":"active",
"type":"NRT", "leader":"true"}}}, "shard2":{
"range":"0-7fff", "state":"active", "replicas":{
"core_node2":{ "core":"collection1_shard2_replica_n1",
"base_url":"http://127.0.0.1:43409/_/t;,
"node_name":"127.0.0.1:43409__%2Ft", "state":"active",
"type":"NRT", "leader":"true"}, "core_node6":{
"core":"collection1_shard2_replica_n5",
"base_url":"http://127.0.0.1:34265/_/t;,
"node_name":"127.0.0.1:34265__%2Ft", "state":"active",
"type":"NRT", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false", "nrtReplicas":"1",
"tlogReplicas":"0"}, "control_collection":{ "pullReplicas":"0",
"replicationFactor":"1", "shards":{"shard1":{
"range":"8000-7fff", "state":"active",
"replicas":{"core_node2":{
"core":"control_collection_shard1_replica_n1",
"base_url":"http://127.0.0.1:35120/_/t;,
"node_name":"127.0.0.1:35120__%2Ft", "state":"active",
"type":"NRT", "leader":"true",
"router":{"name":"compositeId"}, "maxShardsPerNode":"1",
"autoAddReplicas":"false", "nrtReplicas":"1", "tlogReplicas":"0"},
"c8n_1x2":{ "pullReplicas":"0", "replicationFactor":"1",
"shards":{"shard1":{ "range":"8000-7fff",
"state":"active", "replicas":{ "core_node3":{
"state":"down", "base_url":"http://127.0.0.1:35120/_/t;,
"core":"c8n_1x2_shard1_replica_n2",
"node_name":"127.0.0.1:35120__%2Ft", "type":"NRT"},
"core_node4":{ "core":"c8n_1x2_shard1_replica_n1",
"base_url":"http://127.0.0.1:43409/_/t;,
"node_name":"127.0.0.1:43409__%2Ft", "state":"active",
"type":"NRT", "leader":"true",
"router":{"name":"compositeId"}, "maxShardsPerNode":"1",
"autoAddReplicas":"false", "nrtReplicas":"2", "tlogReplicas":"0"}}
Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in c8n_1x2
come up within 9 ms! ClusterState: {
"collMinRf_1x3":{
"pullReplicas":"0",
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node4":{
"core":"collMinRf_1x3_shard1_replica_n1",
"base_url":"http://127.0.0.1:43595/_/t;,
"node_name":"127.0.0.1:43595__%2Ft",
"state":"active",
"type":"NRT"},
"core_node5":{
"core":"collMinRf_1x3_shard1_replica_n2",
"base_url":"http://127.0.0.1:34265/_/t;,
"node_name":"127.0.0.1:34265__%2Ft",
"state":"active",
"type":"NRT",
"leader":"true"},
"core_node6":{
"core":"collMinRf_1x3_shard1_replica_n3",
"base_url":"http://127.0.0.1:43409/_/t;,
"node_name":"127.0.0.1:43409__%2Ft",
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101670#comment-16101670
]
Ignacio Vera commented on LUCENE-7906:
--
I coorected the code above.
I found the issue, it is in line 496 of GeoComplexPolygon:
if (right != null && minValue >= low && right.traverse(edgeIterator, minValue,
maxValue) == false) {
|It seems that the condition minValue >= low prevents to look for necessary
planes. If a change the condition to maxValue >= low my test run smooth but I
don't know if is correct. What it is sure is that the conditin is not right.
Any ideas?
> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
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] [Comment Edited] (LUCENE-7906) Spatial relationship between Geoshapes
[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101670#comment-16101670
]
Ignacio Vera edited comment on LUCENE-7906 at 7/26/17 1:37 PM:
---
I corrected the code above.
I found the issue, it is in line 496 of GeoComplexPolygon:
if (right != null && minValue >= low && right.traverse(edgeIterator, minValue,
maxValue) == false) {
|It seems that the condition minValue >= low prevents to look for necessary
planes. If a change the condition to maxValue >= low my test run smooth but I
don't know if it is correct. What it is sure is that the condition is not
right. Any ideas?
was (Author: ivera):
I coorected the code above.
I found the issue, it is in line 496 of GeoComplexPolygon:
if (right != null && minValue >= low && right.traverse(edgeIterator, minValue,
maxValue) == false) {
|It seems that the condition minValue >= low prevents to look for necessary
planes. If a change the condition to maxValue >= low my test run smooth but I
don't know if is correct. What it is sure is that the conditin is not right.
Any ideas?
> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
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-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101571#comment-16101571
]
ASF subversion and git services commented on SOLR-11130:
Commit 9f73bcf11d89f6ee7b2de8bea25be9018f4554cb in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9f73bcf ]
SOLR-11130: V2Request is SolrJ should return the correct collection name
> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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] [Created] (SOLR-11147) Restore command does not copy .fdt file correctly
MANUEL S. FUENTES created SOLR-11147: Summary: Restore command does not copy .fdt file correctly Key: SOLR-11147 URL: https://issues.apache.org/jira/browse/SOLR-11147 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Backup/Restore Affects Versions: 6.6, 6.3 Environment: Windows 2012 R2. Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 1.8.0_91 25.91-b15- Solr 6.3 (6.6) Standalone Reporter: MANUEL S. FUENTES Priority: Minor This is my first issue here, so excuse me if anything is wrong. When recovering a core backup according to the API, the process goes normally restoring all the files except the biggest (.fdt file). If you restart SoLR then that core is not loaded. Some other times I've found that the .fdt file is copied partially, so restarting has the same effect. The log says that the .fdt file is copied, but it's not. The only workarounds found are: - Copy the .fdt file manually from the backup - Deleting the index completely before restoring - Optimizing the index before restarting SoLR (weird with one file missing but worked). Thanks, Manuel F. -- 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-10814) Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos authentication
[ https://issues.apache.org/jira/browse/SOLR-10814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101510#comment-16101510 ] Noble Paul commented on SOLR-10814: --- No. getShortName() is not backward compatible. How are you going to switch between the both? > Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos > authentication > --- > > Key: SOLR-10814 > URL: https://issues.apache.org/jira/browse/SOLR-10814 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.2 >Reporter: Hrishikesh Gadre > > Solr allows configuring roles to control user access to the system. This is > accomplished through rule-based permission definitions which are assigned to > users. > The authorization framework in Solr passes the information about the request > (to be authorized) using an instance of AuthorizationContext class. Currently > the only way to extract authenticated user is via getUserPrincipal() method > which returns an instance of java.security.Principal class. The > RuleBasedAuthorizationPlugin implementation invokes getName() method on the > Principal instance to fetch the list of associated roles. > https://github.com/apache/lucene-solr/blob/2271e73e763b17f971731f6f69d6ffe46c40b944/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L156 > In case of basic authentication mechanism, the principal is the userName. > Hence it works fine. But in case of kerberos authentication, the user > principal also contains the RELM information e.g. instead of foo, it would > return f...@example.com. This means if the user changes the authentication > mechanism, he would also need to change the user-role mapping in > authorization section to use f...@example.com instead of foo. This is not > good from usability perspective. -- 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-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101576#comment-16101576
]
ASF subversion and git services commented on SOLR-11130:
Commit c167e0da22491a24a3bd1a5cec0f659ca4f1f291 in lucene-solr's branch
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c167e0d ]
SOLR-11130: V2Request is SolrJ should return the correct collection name
> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101577#comment-16101577
]
ASF subversion and git services commented on SOLR-11130:
Commit c1c731af09cd75e50c5b80e61047520ca2d0134e in lucene-solr's branch
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c1c731a ]
SOLR-11130: V2Request in SolrJ should return the correct collection name so
that the request is forwarded to the correct node
> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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-7906) Spatial relationship between Geoshapes
[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101664#comment-16101664
]
Karl Wright commented on LUCENE-7906:
-
{quote}
My qiestion is, is there any issue to implement intersects in the circle as:
{quote}
[~ivera] Are you using "p" when you mean "circlePlane"? This may work for
circles, but it would need to be thoroughly tested.
{quote}
On another topic, I am having problems with GeoComplexPolygon. It seems they
way I have implemented and the more efficient way of intersects with plane on
the class give different results. I tried to implement an
IntersectorShapeIterator but some of my test were failing. I need to have a
closer look into that.
{quote}
I am not sure quite what you mean here? Can you give me a snippet of code?
> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
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-11150) When V2Request is sent to the wrong node, it throws NPE
Noble Paul created SOLR-11150: - Summary: When V2Request is sent to the wrong node, it throws NPE Key: SOLR-11150 URL: https://issues.apache.org/jira/browse/SOLR-11150 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul -- 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-11130) V2Request in SolrJ should return the correct collection name so that the request is forwarded to the correct node
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-11130:
--
Fix Version/s: master (8.0)
> V2Request in SolrJ should return the correct collection name so that the
> request is forwarded to the correct node
> ---
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0, master (8.0)
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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] [Resolved] (SOLR-11130) V2Request in SolrJ should return the correct collection name so that the request is forwarded to the correct node
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-11130.
---
Resolution: Fixed
> V2Request in SolrJ should return the correct collection name so that the
> request is forwarded to the correct node
> ---
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0, master (8.0)
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101674#comment-16101674 ] Karl Wright commented on LUCENE-7906: - Hi [~ivera], the GeoComplexPolygon implementation of Node was modeled directly on Robert Muir's implementation of 2D polygons. The code is very complex and very sensitive to changes, so before we change anything we must confirm that I made an error in revising the original code for the 3D case. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- 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-11130) V2Request in SolrJ should return the correct collection name so that the request is forwarded to the correct node
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101591#comment-16101591
]
Noble Paul commented on SOLR-11130:
---
The new ticket can be fixed in 7.1 and it does not have to be a vlocker for 7.0
[~anshumg] this is resolved
> V2Request in SolrJ should return the correct collection name so that the
> request is forwarded to the correct node
> ---
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0, master (8.0)
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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] (SOLR-11130) V2Request in SolrJ should return the correct collection name so that the request is forwarded to the correct node
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101590#comment-16101590
]
Noble Paul commented on SOLR-11130:
---
Opened a new ticket SOLR-11150
> V2Request in SolrJ should return the correct collection name so that the
> request is forwarded to the correct node
> ---
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0, master (8.0)
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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] [Comment Edited] (LUCENE-7906) Spatial relationship between Geoshapes
[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101644#comment-16101644
]
Ignacio Vera edited comment on LUCENE-7906 at 7/26/17 1:32 PM:
---
My qiestion is, is there any issue to implement intersects in the circle as:
@Override
public boolean intersects(GeoShape shape) {
if (circlePlane == null) {
return false;
}
return shape.intersects(circlePlane, circlePoints);
}
On another topic, I am having problems with GeoComplexPolygon. It seems they
way I have implemented and the more efficient way of intersects with plane on
the class give different results. I tried to implement an
IntersectorShapeIterator but some of my test were failing. I need to have a
closer look into that.
was (Author: ivera):
My qiestion is, is there any issue to implement intersects in the circle as:
@Override
public boolean intersects(GeoShape shape) {
if (circlePlane == null) {
return false;
}
return shape.intersects(planetModel, p, notablePoints, circlePoints);
}
On another topic, I am having problems with GeoComplexPolygon. It seems they
way I have implemented and the more efficient way of intersects with plane on
the class give different results. I tried to implement an
IntersectorShapeIterator but some of my test were failing. I need to have a
closer look into that.
> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
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] [Comment Edited] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101571#comment-16101571
]
Noble Paul edited comment on SOLR-11130 at 7/26/17 11:41 AM:
-
Commit 9f73bcf11d89f6ee7b2de8bea25be9018f4554cb in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9f73bcf ]
SOLR-11130: V2Request in SolrJ should return the correct collection name
was (Author: jira-bot):
Commit 9f73bcf11d89f6ee7b2de8bea25be9018f4554cb in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9f73bcf ]
SOLR-11130: V2Request is SolrJ should return the correct collection name
> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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-EA] Lucene-Solr-7.0-Windows (32bit/jdk-9-ea+178) - Build # 49 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Windows/49/ Java: 32bit/jdk-9-ea+178 -server -XX:+UseSerialGC --illegal-access=deny 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.SolrExceptionTest Error Message: The test or suite printed 10340 bytes to stdout and stderr, even though the limit was set to 8192 bytes. Increase the limit with @Limit, ignore it completely with @SuppressSysoutChecks or run with -Dtests.verbose=true Stack Trace: java.lang.AssertionError: The test or suite printed 10340 bytes to stdout and stderr, even though the limit was set to 8192 bytes. Increase the limit with @Limit, ignore it completely with @SuppressSysoutChecks or run with -Dtests.verbose=true at __randomizedtesting.SeedInfo.seed([6E3B0744256E75A0]:0) at org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:211) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37) 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) Build Log: [...truncated 13700 lines...] [junit4] Suite: org.apache.solr.client.solrj.SolrExceptionTest [junit4] 2> SLF4J: Class path contains multiple SLF4J bindings. [junit4] 2> SLF4J: Found binding in [jar:file:/C:/Users/jenkins/workspace/Lucene-Solr-7.0-Windows/solr/solrj/test-lib/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class] [junit4] 2> SLF4J: Found binding in [jar:file:/C:/Users/jenkins/workspace/Lucene-Solr-7.0-Windows/solr/core/lib/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class] [junit4] 2> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. [junit4] 2> SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory] [junit4] 2> 0INFO (TEST-SolrExceptionTest.testSolrException-seed#[6E3B0744256E75A0]) [] o.a.s.u.Java9InitHack Adding temporary workaround for Hadoop's Shell class to allow running on Java 9 (please ignore any warnings/failures). [junit4] 2> 22 ERROR (TEST-SolrExceptionTest.testSolrException-seed#[6E3B0744256E75A0]) [] o.a.h.u.Shell Failed to locate the winutils binary in the hadoop binary path [junit4] 2> java.io.IOException: Could not locate executable null\bin\winutils.exe in the Hadoop binaries. [junit4] 2>at org.apache.hadoop.util.Shell.getQualifiedBinPath(Shell.java:356) [junit4] 2>at org.apache.hadoop.util.Shell.getWinUtilsPath(Shell.java:371) [junit4] 2>at org.apache.hadoop.util.Shell.(Shell.java:364) [junit4] 2>at java.base/java.lang.Class.forName0(Native Method) [junit4] 2>at java.base/java.lang.Class.forName(Class.java:292) [junit4] 2>at org.apache.solr.util.Java9InitHack.initPrivileged(Java9InitHack.java:65) [junit4] 2>at java.base/java.security.AccessController.doPrivileged(Native Method) [junit4] 2>at org.apache.solr.util.Java9InitHack.initJava9(Java9InitHack.java:55) [junit4] 2>at org.apache.solr.SolrTestCaseJ4.(SolrTestCaseJ4.java:167) [junit4] 2>at org.apache.solr.client.solrj.SolrExceptionTest.testSolrException(SolrExceptionTest.java:43) [junit4] 2>at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4] 2>at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [junit4] 2>at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit4] 2>at java.base/java.lang.reflect.Method.invoke(Method.java:564) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) [junit4] 2>at
[jira] [Commented] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101580#comment-16101580
]
ASF subversion and git services commented on SOLR-11130:
Commit 41c666d44d12b4d5420e5888cceadc821a0d404f in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=41c666d ]
SOLR-11130: change was added in wrong version
> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly
[
https://issues.apache.org/jira/browse/SOLR-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101581#comment-16101581
]
ASF subversion and git services commented on SOLR-11130:
Commit 1ec0ce7d7431bb8554b7922a101c339809a1fbb9 in lucene-solr's branch
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1ec0ce7 ]
SOLR-11130: change was added in wrong version
> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes,
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
> at
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName +
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which
> does not have any replica for the collection. Now in v1 API, solrj would
> refuse to send the request and complain that no default collection is set but
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default
> collection
> # We detect that users are trying to invoke a collection specific v2 api and
> we add a new method in V2RequestBuilder to specify a collection name and
> ensure that the user calls 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-7906) Spatial relationship between Geoshapes
[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101644#comment-16101644
]
Ignacio Vera commented on LUCENE-7906:
--
My qiestion is, is there any issue to implement intersects in the circle as:
@Override
public boolean intersects(GeoShape shape) {
if (circlePlane == null) {
return false;
}
return shape.intersects(planetModel, p, notablePoints, circlePoints);
}
On another topic, I am having problems with GeoComplexPolygon. It seems they
way I have implemented and the more efficient way of intersects with plane on
the class give different results. I tried to implement an
IntersectorShapeIterator but some of my test were failing. I need to have a
closer look into that.
> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
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/jdk1.8.0_141) - Build # 78 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/78/ Java: 64bit/jdk1.8.0_141 -XX:-UseCompressedOops -XX:+UseSerialGC 4 tests failed. FAILED: org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.testFullImportInnerEntity Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_1830AB6BFB34D858-001\tempDir-002\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_1830AB6BFB34D858-001\tempDir-002\collection1 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_1830AB6BFB34D858-001\tempDir-002: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_1830AB6BFB34D858-001\tempDir-002 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_1830AB6BFB34D858-001\tempDir-002\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_1830AB6BFB34D858-001\tempDir-002\collection1 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_1830AB6BFB34D858-001\tempDir-002: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_1830AB6BFB34D858-001\tempDir-002 at __randomizedtesting.SeedInfo.seed([1830AB6BFB34D858:E94707DE5A57ABCF]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd$SolrInstance.tearDown(TestSolrEntityProcessorEndToEnd.java:360) at org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.tearDown(TestSolrEntityProcessorEndToEnd.java:142) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:965) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at
[JENKINS] Lucene-Solr-Tests-7.0 - Build # 78 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/78/
All tests passed
Build Log:
[...truncated 53272 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1528273208
[ecj-lint] Compiling 441 source files to /tmp/ecj1528273208
[ecj-lint] --
[ecj-lint] 1. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java
(at line 19)
[ecj-lint] import org.apache.solr.common.params.CommonParams;
[ecj-lint]^^
[ecj-lint] The import org.apache.solr.common.params.CommonParams is never used
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/solr/solrj/src/java/org/apache/solr/common/util/CommandOperation.java
(at line 248)
[ecj-lint] new JavaBinCodec() {
[ecj-lint] int level = 0;
[ecj-lint] @Override
[ecj-lint] protected Map newMap(int size) {
[ecj-lint] level++;
[ecj-lint] return level == 1 ? map : super.newMap(size);
[ecj-lint] }
[ecj-lint] }.unmarshal(in);
[ecj-lint]
^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 3. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/solr/solrj/src/java/org/apache/solr/common/util/Utils.java
(at line 110)
[ecj-lint] new JavaBinCodec().marshal(o,baos);
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 3 problems (1 error, 2 warnings)
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/build.xml:810: The
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/build.xml:101: The
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/solr/build.xml:689:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/solr/solrj/build.xml:67:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/lucene/common-build.xml:2043:
Compile failed; see the compiler error output for details.
Total time: 79 minutes 24 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11150) When V2Request is sent to the wrong node, it throws NPE
[ https://issues.apache.org/jira/browse/SOLR-11150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-11150: -- Fix Version/s: 7.1 > When V2Request is sent to the wrong node, it throws NPE > --- > > Key: SOLR-11150 > URL: https://issues.apache.org/jira/browse/SOLR-11150 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6, 7.0 >Reporter: Noble Paul > Fix For: 7.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
[jira] [Assigned] (SOLR-11150) When V2Request is sent to the wrong node, it throws NPE
[ https://issues.apache.org/jira/browse/SOLR-11150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-11150: - Assignee: Noble Paul > When V2Request is sent to the wrong node, it throws NPE > --- > > Key: SOLR-11150 > URL: https://issues.apache.org/jira/browse/SOLR-11150 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6, 7.0 >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 7.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
[jira] [Updated] (SOLR-11150) When V2Request is sent to the wrong node, it throws NPE
[ https://issues.apache.org/jira/browse/SOLR-11150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-11150: -- Affects Version/s: 7.0 6.6 > When V2Request is sent to the wrong node, it throws NPE > --- > > Key: SOLR-11150 > URL: https://issues.apache.org/jira/browse/SOLR-11150 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6, 7.0 >Reporter: Noble Paul > Fix For: 7.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
[jira] [Assigned] (SOLR-9321) Removed usage of deprecated clusterstate.getSlicesMap(), getSlices() and getActiveSlices()
[ https://issues.apache.org/jira/browse/SOLR-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya reassigned SOLR-9321: -- Assignee: Ishan Chattopadhyaya > Removed usage of deprecated clusterstate.getSlicesMap(), getSlices() and > getActiveSlices() > -- > > Key: SOLR-9321 > URL: https://issues.apache.org/jira/browse/SOLR-9321 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 7.0 > > Attachments: SOLR-9321.patch, SOLR-9321.patch, SOLR-9321.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] [Closed] (SOLR-11148) dataimport form mysql error
[ https://issues.apache.org/jira/browse/SOLR-11148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev closed SOLR-11148. --- Resolution: Not A Problem > dataimport form mysql error > --- > > Key: SOLR-11148 > URL: https://issues.apache.org/jira/browse/SOLR-11148 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 5.5.4 > Environment: Ubuntu14.04 + solr 5.5.4+mysql 5.7.15 >Reporter: Joe Yang > Labels: test > > error occured while import data from mysql to solr: > 2017-07-26 10:01:49.020 WARN (Thread-47) [ x:mycore1] o.a.s.h.d.SolrWriter > Error creating document : SolrInputDocument(fields: > [deliver_to=桃園市桃園區大興路118-1號4樓, ship_id=fd219e30-7119-11e7-af5d-005056af8f8b]) > org.apache.solr.common.SolrException: Document is missing mandatory uniqueKey > field: id > at > org.apache.solr.update.AddUpdateCommand.getIndexedId(AddUpdateCommand.java:97) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:947) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:712) > at > org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103) > at > org.apache.solr.handler.dataimport.SolrWriter.upload(SolrWriter.java:74) > at > org.apache.solr.handler.dataimport.DataImportHandler$1.upload(DataImportHandler.java:260) > at > org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:524) > at > org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:414) > at > org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:329) > at > org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:232) > at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:416) > at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:480) > at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:461) > -- 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-11149) import data from mysql failed
Joe Yang created SOLR-11149: --- Summary: import data from mysql failed Key: SOLR-11149 URL: https://issues.apache.org/jira/browse/SOLR-11149 Project: Solr Issue Type: Test Security Level: Public (Default Security Level. Issues are Public) Components: Build Affects Versions: 5.5.4 Environment: ubuntu14.04+solr5.5.4+mysql5.7.15 Reporter: Joe Yang dataimport from mysql to solr, errors as follows: 2017-07-26 10:01:49.020 WARN (Thread-47) [ x:mycore1] o.a.s.h.d.SolrWriter Error creating document : SolrInputDocument(fields: [deliver_to=桃園市桃園區大興路118-1號4樓, ship_id=fd219e30-7119-11e7-af5d-005056af8f8b]) org.apache.solr.common.SolrException: Document is missing mandatory uniqueKey field: id at org.apache.solr.update.AddUpdateCommand.getIndexedId(AddUpdateCommand.java:97) at org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:947) at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:712) at org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103) at org.apache.solr.handler.dataimport.SolrWriter.upload(SolrWriter.java:74) at org.apache.solr.handler.dataimport.DataImportHandler$1.upload(DataImportHandler.java:260) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:524) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:414) at org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:329) at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:232) at org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:416) at org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:480) at org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:461) -- 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] [Reopened] (SOLR-11141) Replication causes memory leak
[ https://issues.apache.org/jira/browse/SOLR-11141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] DROOPY reopened SOLR-11141: --- After replication,solr will reload cores. But solr use different SolrResourceLoader to load jars, so singleton is fail. There is hundreds of SolrResourceLoader and org.apache.lucene.analysis.cn.smart.hhmm.BigramDictionary.BigramDictionary is 3000kb. !http://dwz.cn/6jJvFB! !http://dwz.cn/6jJzn5! !http://dwz.cn/6jJzUF! > Replication causes memory leak > --- > > Key: SOLR-11141 > URL: https://issues.apache.org/jira/browse/SOLR-11141 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: replication (java) >Affects Versions: 6.3 > Environment: CentOS 6 > Java(TM) SE Runtime Environment (build 1.8.0_111-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode) > Apache Tomcat/8.5.9 >Reporter: DROOPY > > !http://dwz.cn/6jvbId! -- 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-11141) Replication causes memory leak
[ https://issues.apache.org/jira/browse/SOLR-11141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101346#comment-16101346 ] DROOPY commented on SOLR-11141: --- After replication,solr will reload cores. But solr use different SolrResourceLoader to load jars, so singleton is fail. There is hundreds of SolrResourceLoader and org.apache.lucene.analysis.cn.smart.hhmm.BigramDictionary.BigramDictionary is 3000kb. !http://dwz.cn/6jJvFB! !http://dwz.cn/6jJzn5! !http://dwz.cn/6jJzUF! > Replication causes memory leak > --- > > Key: SOLR-11141 > URL: https://issues.apache.org/jira/browse/SOLR-11141 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: replication (java) >Affects Versions: 6.3 > Environment: CentOS 6 > Java(TM) SE Runtime Environment (build 1.8.0_111-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode) > Apache Tomcat/8.5.9 >Reporter: DROOPY > > !http://dwz.cn/6jvbId! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-9-ea+178) - Build # 145 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/145/ Java: 64bit/jdk-9-ea+178 -XX:-UseCompressedOops -XX:+UseSerialGC --illegal-access=deny 1 tests failed. FAILED: org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelExecutorStream Error Message: Error from server at http://127.0.0.1:35885/solr/mainCorpus_shard2_replica_n3: Expected mime type application/octet-stream but got text/html. Error 404HTTP ERROR: 404 Problem accessing /solr/mainCorpus_shard2_replica_n3/update. Reason: Can not find: /solr/mainCorpus_shard2_replica_n3/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.14.v20161028 Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at http://127.0.0.1:35885/solr/mainCorpus_shard2_replica_n3: Expected mime type application/octet-stream but got text/html. Error 404 HTTP ERROR: 404 Problem accessing /solr/mainCorpus_shard2_replica_n3/update. Reason: Can not find: /solr/mainCorpus_shard2_replica_n3/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.14.v20161028 at __randomizedtesting.SeedInfo.seed([2A545782239BCC4F:9743229B1AB7F112]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233) at org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelExecutorStream(StreamExpressionTest.java:6844) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at
[jira] [Commented] (SOLR-10814) Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos authentication
[ https://issues.apache.org/jira/browse/SOLR-10814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101408#comment-16101408 ] Don Bosco Durai commented on SOLR-10814: After going again through the discussion, I personally feel, option A is a good option. > option (a) Expose both short user-name and principal It should be the authentication plugins responsibility to set/derive the short name, but also expose the security Principal, so that the authorization module (or others) if it wants to, it can process the Principals as it wishes. So in the future, if we start supporting certificate based two way SSL authentication, then the SSLAuthPlugin will be responsible for getting the CN from the certificate and derive the shortUserName from it, but also make the entire DN available in the getPrincipal() API. In most cases, all the code should use getShortName(), which should be user friendly and printable string. So that we can use it in logs and other places. This approach will give provide both backward compatibility and also we don't have to do any property hacks. And make it future proof for any new authentication plugins. > Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos > authentication > --- > > Key: SOLR-10814 > URL: https://issues.apache.org/jira/browse/SOLR-10814 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.2 >Reporter: Hrishikesh Gadre > > Solr allows configuring roles to control user access to the system. This is > accomplished through rule-based permission definitions which are assigned to > users. > The authorization framework in Solr passes the information about the request > (to be authorized) using an instance of AuthorizationContext class. Currently > the only way to extract authenticated user is via getUserPrincipal() method > which returns an instance of java.security.Principal class. The > RuleBasedAuthorizationPlugin implementation invokes getName() method on the > Principal instance to fetch the list of associated roles. > https://github.com/apache/lucene-solr/blob/2271e73e763b17f971731f6f69d6ffe46c40b944/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L156 > In case of basic authentication mechanism, the principal is the userName. > Hence it works fine. But in case of kerberos authentication, the user > principal also contains the RELM information e.g. instead of foo, it would > return f...@example.com. This means if the user changes the authentication > mechanism, he would also need to change the user-role mapping in > authorization section to use f...@example.com instead of foo. This is not > good from usability perspective. -- 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 # 2042 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2042/ 1 tests failed. FAILED: org.apache.solr.update.HardAutoCommitTest.testCommitWithin Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([E53CDBAD52B67C22:5FEEB4D5D1989237]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:886) at org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: 00 request was:q=id:529==0=20=2.2 at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:879) ... 40 more Build Log: [...truncated 11711 lines...] [junit4] Suite: org.apache.solr.update.HardAutoCommitTest [junit4] 2> Creating dataDir:
[JENKINS] Lucene-Solr-Tests-7.x - Build # 102 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/102/ 1 tests failed. FAILED: org.apache.solr.cloud.LeaderElectionContextKeyTest.test Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([31E78931675B40DA:B9B3B6EBC9A72D22]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.cloud.LeaderElectionContextKeyTest.test(LeaderElectionContextKeyTest.java:88) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 11332 lines...] [junit4] Suite: org.apache.solr.cloud.LeaderElectionContextKeyTest [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/build/solr-core/test/J2/temp/solr.cloud.LeaderElectionContextKeyTest_31E78931675B40DA-001/init-core-data-001 [junit4] 2> 528580 WARN
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+178) - Build # 20201 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20201/ Java: 64bit/jdk-9-ea+178 -XX:+UseCompressedOops -XX:+UseSerialGC --illegal-access=deny 2 tests failed. FAILED: org.apache.solr.cloud.TestAuthenticationFramework.testBasics Error Message: Error from server at https://127.0.0.1:40929/solr/testcollection_shard1_replica_n2: Expected mime type application/octet-stream but got text/html.Error 404HTTP ERROR: 404 Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason: Can not find: /solr/testcollection_shard1_replica_n2/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.14.v20161028 Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at https://127.0.0.1:40929/solr/testcollection_shard1_replica_n2: Expected mime type application/octet-stream but got text/html. Error 404 HTTP ERROR: 404 Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason: Can not find: /solr/testcollection_shard1_replica_n2/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.14.v20161028 at __randomizedtesting.SeedInfo.seed([DE591C668A385444:E381B24AB2D60A34]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233) at org.apache.solr.cloud.TestAuthenticationFramework.collectionCreateSearchDeleteTwice(TestAuthenticationFramework.java:126) at org.apache.solr.cloud.TestAuthenticationFramework.testBasics(TestAuthenticationFramework.java:74) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at
[jira] [Created] (SOLR-11148) dataimport form mysql error
Joe Yang created SOLR-11148: --- Summary: dataimport form mysql error Key: SOLR-11148 URL: https://issues.apache.org/jira/browse/SOLR-11148 Project: Solr Issue Type: Test Security Level: Public (Default Security Level. Issues are Public) Components: Build Affects Versions: 5.5.4 Environment: Ubuntu14.04 + solr 5.5.4+mysql 5.7.15 Reporter: Joe Yang error occured while import data from mysql to solr: 2017-07-26 10:01:49.020 WARN (Thread-47) [ x:mycore1] o.a.s.h.d.SolrWriter Error creating document : SolrInputDocument(fields: [deliver_to=桃園市桃園區大興路118-1號4樓, ship_id=fd219e30-7119-11e7-af5d-005056af8f8b]) org.apache.solr.common.SolrException: Document is missing mandatory uniqueKey field: id at org.apache.solr.update.AddUpdateCommand.getIndexedId(AddUpdateCommand.java:97) at org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:947) at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:712) at org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103) at org.apache.solr.handler.dataimport.SolrWriter.upload(SolrWriter.java:74) at org.apache.solr.handler.dataimport.DataImportHandler$1.upload(DataImportHandler.java:260) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:524) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:414) at org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:329) at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:232) at org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:416) at org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:480) at org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:461) -- 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-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101740#comment-16101740 ] ASF subversion and git services commented on LUCENE-7906: - Commit 5d0e58fd7ac7f9cbe9f520f848b7fef847869130 in lucene-solr's branch refs/heads/branch_7x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5d0e58f ] LUCENE-7906: Logic fix for crosses condition > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk1.8.0) - Build # 75 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/75/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.TestDeleteCollectionOnDownNodes.deleteCollectionWithDownNodes Error Message: Timed out waiting for leader elections null Live Nodes: [127.0.0.1:50338_solr, 127.0.0.1:50339_solr] Last available state: null Stack Trace: java.lang.AssertionError: Timed out waiting for leader elections null Live Nodes: [127.0.0.1:50338_solr, 127.0.0.1:50339_solr] Last available state: null at __randomizedtesting.SeedInfo.seed([F57C5CD077E642DE:6B49382851C50E56]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269) at org.apache.solr.cloud.TestDeleteCollectionOnDownNodes.deleteCollectionWithDownNodes(TestDeleteCollectionOnDownNodes.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748)
[jira] [Updated] (SOLR-11151) SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value goes from null -> non-null
[
https://issues.apache.org/jira/browse/SOLR-11151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-11151:
--
Attachment: SOLR-11151.patch
Patch with added test that reproduces 100% of the time without a fix, and a fix
(basically: don't assume that the previous bean value is non-null).
I'll beast this for a while and then commit if I see no failures.
> SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value
> goes from null -> non-null
>
>
> Key: SOLR-11151
> URL: https://issues.apache.org/jira/browse/SOLR-11151
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-11151.patch
>
>
> {{MBeansHandler.testDiff()}} has been failing regularly on Jenkins, e.g.
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20192/]:
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=MBeansHandlerTest
> -Dtests.method=testDiff -Dtests.seed=CD7B1EB232DD9490 -Dtests.multiplier=3
> -Dtests.slow=true -Dtests.locale=es-PA -Dtests.timezone=Asia/Phnom_Penh
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR 0.02s J0 | MBeansHandlerTest.testDiff <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([CD7B1EB232DD9490:86DDA29226BACF0]:0)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
>[junit4]> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>[junit4]> at
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2473)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:337)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:319)
>[junit4]> at
> org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
> {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] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101746#comment-16101746 ] Ignacio Vera commented on LUCENE-7906: -- Great! Shall I add it to the patch? I have the random test almost ready except for polygon with holes. I am concern because sometimes get a bit stuck when trying to build shapes with very specific characteristics. I will send you a new patch soon. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- 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-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101744#comment-16101744 ] Karl Wright commented on LUCENE-7906: - [~ivera], I have pushed the change to GeoComplexPolygon that you suggested to all pertinent branches. Hopefully this will no longer block development for you. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- 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-11152) ClassNotFoundException: com.uwyn.jhighlight.renderer.XhtmlRendererFactory
Simon Endele created SOLR-11152:
---
Summary: ClassNotFoundException:
com.uwyn.jhighlight.renderer.XhtmlRendererFactory
Key: SOLR-11152
URL: https://issues.apache.org/jira/browse/SOLR-11152
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: contrib - Solr Cell (Tika extraction)
Affects Versions: 6.6
Reporter: Simon Endele
We get the following error when trying to index/extract a tgz file with Solr
6.6.0:
{code:java}
Caused by: java.lang.NoClassDefFoundError:
com/uwyn/jhighlight/renderer/XhtmlRendererFactory
at
org.apache.tika.parser.code.SourceCodeParser.getRenderer(SourceCodeParser.java:132)
at
org.apache.tika.parser.code.SourceCodeParser.parse(SourceCodeParser.java:111)
at
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
at
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
at
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:120)
at
org.apache.tika.parser.DelegatingParser.parse(DelegatingParser.java:72)
at
org.apache.tika.extractor.ParsingEmbeddedDocumentExtractor.parseEmbedded(ParsingEmbeddedDocumentExtractor.java:102)
at
org.apache.tika.parser.pkg.PackageParser.parseEntry(PackageParser.java:219)
at
org.apache.tika.parser.pkg.PackageParser.parse(PackageParser.java:182)
at
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
at
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
at
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:120)
at
org.apache.tika.parser.DelegatingParser.parse(DelegatingParser.java:72)
at
org.apache.tika.extractor.ParsingEmbeddedDocumentExtractor.parseEmbedded(ParsingEmbeddedDocumentExtractor.java:102)
at
org.apache.tika.parser.pkg.PackageParser.parseEntry(PackageParser.java:219)
at
org.apache.tika.parser.pkg.PackageParser.parse(PackageParser.java:182)
at
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
at
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
at
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:120)
at
org.apache.tika.parser.DelegatingParser.parse(DelegatingParser.java:72)
at
org.apache.tika.extractor.ParsingEmbeddedDocumentExtractor.parseEmbedded(ParsingEmbeddedDocumentExtractor.java:102)
at
org.apache.tika.parser.pkg.CompressorParser.parse(CompressorParser.java:164)
at
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
at
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
at
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:120)
at
org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:228)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:723)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:529)
... 29 more
Caused by: java.lang.ClassNotFoundException:
com.uwyn.jhighlight.renderer.XhtmlRendererFactory
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:814)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 60 more
{code}
It seems like the dependency
[com.uwyn:jhighlight:1.0|https://mvnrepository.com/artifact/com.uwyn/jhighlight/1.0]
is missing in {{contrib/extraction/lib}} in the Solr installation.
When placing it there, the indexation works perfectly.
--
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-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101725#comment-16101725 ] Ignacio Vera commented on LUCENE-7906: -- My feel is that there is a min value missing: * high: higher value of the node * low: lower value ofthe node * max: maximum value of the tree * min: (missing) minimum value of the tree. The condition you want to add is: minValue>=min insterad of minValue>=low ... then you discard edges out of scope. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- 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-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101726#comment-16101726 ] Karl Wright commented on LUCENE-7906: - Looking at the new way this is being done in the 2D world, it's not compatible with the edge traversal accounting that is needed for the 3D world. So I don't see that it can be adapted readily. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- 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-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101751#comment-16101751 ] Karl Wright commented on LUCENE-7906: - [~ivera] The patch should not contain the GeoComplexPolygon fix, since that has been already committed. You may want to git pull before generating the new patch? > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_141) - Build # 146 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/146/ Java: 32bit/jdk1.8.0_141 -client -XX:+UseG1GC All tests passed Build Log: [...truncated 51714 lines...] -ecj-javadoc-lint-src: [mkdir] Created dir: /tmp/ecj1123210154 [ecj-lint] Compiling 444 source files to /tmp/ecj1123210154 [ecj-lint] -- [ecj-lint] 1. ERROR in /home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java (at line 19) [ecj-lint] import org.apache.solr.common.params.CommonParams; [ecj-lint]^^ [ecj-lint] The import org.apache.solr.common.params.CommonParams is never used [ecj-lint] -- [ecj-lint] 1 problem (1 error) BUILD FAILED /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:810: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:101: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build.xml:689: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/solrj/build.xml:67: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:2046: Compile failed; see the compiler error output for details. Total time: 75 minutes 22 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11151) SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value goes from null -> non-null
Steve Rowe created SOLR-11151:
-
Summary: SolrInfoMBeanHandler.getDiff() ADD case non-functional:
NPE when a bean value goes from null -> non-null
Key: SOLR-11151
URL: https://issues.apache.org/jira/browse/SOLR-11151
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Steve Rowe
Assignee: Steve Rowe
Fix For: 7.0, master (8.0), 7.1
{{MBeansHandler.testDiff()}} has been failing regularly on Jenkins, e.g.
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20192/]:
{noformat}
[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=MBeansHandlerTest
-Dtests.method=testDiff -Dtests.seed=CD7B1EB232DD9490 -Dtests.multiplier=3
-Dtests.slow=true -Dtests.locale=es-PA -Dtests.timezone=Asia/Phnom_Penh
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 0.02s J0 | MBeansHandlerTest.testDiff <<<
[junit4]> Throwable #1: java.lang.NullPointerException
[junit4]>at
__randomizedtesting.SeedInfo.seed([CD7B1EB232DD9490:86DDA29226BACF0]:0)
[junit4]>at
org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
[junit4]>at
org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
[junit4]>at
org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
[junit4]>at
org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
[junit4]>at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
[junit4]>at
org.apache.solr.core.SolrCore.execute(SolrCore.java:2473)
[junit4]>at
org.apache.solr.util.TestHarness.query(TestHarness.java:337)
[junit4]>at
org.apache.solr.util.TestHarness.query(TestHarness.java:319)
[junit4]>at
org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4]>at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4]>at
java.base/java.lang.reflect.Method.invoke(Method.java:564)
[junit4]>at java.base/java.lang.Thread.run(Thread.java:844)
{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-Tests-7.x - Build # 103 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/103/ All tests passed Build Log: [...truncated 53277 lines...] -ecj-javadoc-lint-src: [mkdir] Created dir: /tmp/ecj890849962 [ecj-lint] Compiling 444 source files to /tmp/ecj890849962 [ecj-lint] -- [ecj-lint] 1. ERROR in /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java (at line 19) [ecj-lint] import org.apache.solr.common.params.CommonParams; [ecj-lint]^^ [ecj-lint] The import org.apache.solr.common.params.CommonParams is never used [ecj-lint] -- [ecj-lint] 1 problem (1 error) BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/build.xml:810: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/build.xml:101: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/build.xml:689: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/solrj/build.xml:67: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/common-build.xml:2046: Compile failed; see the compiler error output for details. Total time: 80 minutes 41 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101694#comment-16101694
]
Karl Wright commented on LUCENE-7906:
-
The 2D tree creation code now looks like this:
{code}
/**
* Creates an edge interval tree from a set of polygon vertices.
* @return root node of the tree.
*/
private static Edge createTree(double polyLats[], double polyLons[]) {
Edge edges[] = new Edge[polyLats.length - 1];
for (int i = 1; i < polyLats.length; i++) {
double lat1 = polyLats[i-1];
double lon1 = polyLons[i-1];
double lat2 = polyLats[i];
double lon2 = polyLons[i];
edges[i - 1] = new Edge(lat1, lon1, lat2, lon2, Math.min(lat1, lat2),
Math.max(lat1, lat2));
}
// sort the edges then build a balanced tree from them
Arrays.sort(edges, (left, right) -> {
int ret = Double.compare(left.low, right.low);
if (ret == 0) {
ret = Double.compare(left.max, right.max);
}
return ret;
});
return createTree(edges, 0, edges.length - 1);
}
/** Creates tree from sorted edges (with range low and high inclusive) */
private static Edge createTree(Edge edges[], int low, int high) {
if (low > high) {
return null;
}
// add midpoint
int mid = (low + high) >>> 1;
Edge newNode = edges[mid];
// add children
newNode.left = createTree(edges, low, mid - 1);
newNode.right = createTree(edges, mid + 1, high);
// pull up max values to this node
if (newNode.left != null) {
newNode.max = Math.max(newNode.max, newNode.left.max);
}
if (newNode.right != null) {
newNode.max = Math.max(newNode.max, newNode.right.max);
}
return newNode;
}
{code}
If we adopt the new membership code we would need to adapt the new tree
construction code as well.
> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
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-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101735#comment-16101735 ] ASF subversion and git services commented on LUCENE-7906: - Commit 2eba4cebc5fa963dc90cf31e8b10801c0161fc55 in lucene-solr's branch refs/heads/master from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2eba4ce ] LUCENE-7906: Logic fix for crosses condition > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- 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-7906) Spatial relationship between Geoshapes
[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101677#comment-16101677
]
Karl Wright commented on LUCENE-7906:
-
Here is the current 2D polygon code. It has changed somewhat since I
originally used it as a baseline.
{code}
/**
* Returns true if the point is contained within this polygon.
*
* See https://www.ecse.rpi.edu/~wrf/Research/Short_Notes/pnpoly.html;>
* https://www.ecse.rpi.edu/~wrf/Research/Short_Notes/pnpoly.html for
more information.
*/
public boolean contains(double latitude, double longitude) {
if (latitude <= maxY && longitude <= maxX) {
if (componentContains(latitude, longitude)) {
return true;
}
if (left != null) {
if (left.contains(latitude, longitude)) {
return true;
}
}
if (right != null && ((splitX == false && latitude >= minLat) || (splitX
&& longitude >= minLon))) {
if (right.contains(latitude, longitude)) {
return true;
}
}
}
return false;
}
/** Returns true if the point is contained within this polygon component. */
private boolean componentContains(double latitude, double longitude) {
// check bounding box
if (latitude < minLat || latitude > maxLat || longitude < minLon ||
longitude > maxLon) {
return false;
}
if (tree.contains(latitude, longitude)) {
if (holes != null && holes.contains(latitude, longitude)) {
return false;
}
return true;
}
return false;
}
{code}
> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
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] [Comment Edited] (LUCENE-7906) Spatial relationship between Geoshapes
[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101726#comment-16101726
]
Karl Wright edited comment on LUCENE-7906 at 7/26/17 2:32 PM:
--
Ah, I included the wrong code. The "crosses" detection uses this logic:
{code}
if (left != null) {
if (left.crosses(minLat, maxLat, minLon, maxLon)) {
return true;
}
}
if (right != null && maxLat >= low) {
if (right.crosses(minLat, maxLat, minLon, maxLon)) {
return true;
}
}
{code}
So, you are correct; the code should read "maxValue >= low".
was (Author: kwri...@metacarta.com):
Looking at the new way this is being done in the 2D world, it's not compatible
with the edge traversal accounting that is needed for the 3D world. So I don't
see that it can be adapted readily.
> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
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-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101736#comment-16101736 ] ASF subversion and git services commented on LUCENE-7906: - Commit 5aa71427f2e4b22da22836e923fb52361f0d1721 in lucene-solr's branch refs/heads/branch_6x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5aa7142 ] LUCENE-7906: Logic fix for crosses condition > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- 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-SmokeRelease-7.0 - Build # 15 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.0/15/ No tests ran. Build Log: [...truncated 25708 lines...] prepare-release-no-sign: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/dist [copy] Copying 476 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 215 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/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-7.0/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.01 sec (39.8 MB/sec) [smoker] check changes HTML... [smoker] download lucene-7.0.0-src.tgz... [smoker] 29.5 MB in 0.02 sec (1246.4 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.0.0.tgz... [smoker] 69.0 MB in 0.06 sec (1247.7 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.0.0.zip... [smoker] 79.3 MB in 0.06 sec (1249.8 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-7.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6165 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.0.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6165 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.0.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run "ant validate" [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'... [smoker] test demo with 1.8... [smoker] got 213 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 (290.9 MB/sec) [smoker] check changes HTML... [smoker] download solr-7.0.0-src.tgz... [smoker] 50.2 MB in 0.04 sec (1184.7 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-7.0.0.tgz... [smoker] 141.7 MB in 0.12 sec (1139.5 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-7.0.0.zip... [smoker] 142.7 MB in 0.12 sec (1208.8 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-7.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-7.0.0.tgz... [smoker] **WARNING**: skipping check of /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] copying unpacked distribution for Java 8 ... [smoker] test solr example w/ Java 8... [smoker] start Solr instance (log=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)... [smoker] No process found for Solr node running on port 8983 [smoker] Running techproducts example on port 8983 from /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8 [smoker] Creating Solr home directory /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr [smoker] [smoker] Starting up Solr on port 8983 using command: [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr" [smoker] [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|] [/] [-] [\] [|] [/] [-] [\] [smoker] Started Solr server on port
[jira] [Resolved] (SOLR-11151) SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value goes from null -> non-null
[
https://issues.apache.org/jira/browse/SOLR-11151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved SOLR-11151.
---
Resolution: Fixed
> SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value
> goes from null -> non-null
>
>
> Key: SOLR-11151
> URL: https://issues.apache.org/jira/browse/SOLR-11151
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-11151.patch
>
>
> {{MBeansHandler.testDiff()}} has been failing regularly on Jenkins, e.g.
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20192/]:
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=MBeansHandlerTest
> -Dtests.method=testDiff -Dtests.seed=CD7B1EB232DD9490 -Dtests.multiplier=3
> -Dtests.slow=true -Dtests.locale=es-PA -Dtests.timezone=Asia/Phnom_Penh
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR 0.02s J0 | MBeansHandlerTest.testDiff <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([CD7B1EB232DD9490:86DDA29226BACF0]:0)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
>[junit4]> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>[junit4]> at
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2473)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:337)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:319)
>[junit4]> at
> org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
> {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] [Resolved] (SOLR-9995) refactor / cleanup PointFields code and overall asumptions about numerics
[
https://issues.apache.org/jira/browse/SOLR-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved SOLR-9995.
--
Resolution: Fixed
Assignee: Steve Rowe
Fix Version/s: 7.1
master (8.0)
7.0
Resolving as Fixed, since all child issues are resolved.
> refactor / cleanup PointFields code and overall asumptions about numerics
> -
>
> Key: SOLR-9995
> URL: https://issues.apache.org/jira/browse/SOLR-9995
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomás Fernández Löbbe
>Assignee: Steve Rowe
>Priority: Trivial
> Labels: numeric-tries-to-points
> Fix For: 7.0, master (8.0), 7.1
>
>
> Generalizing this issue to serve as a parent for small individual
> improvements/cleanup/refactoring subtasks that can be made to various places
> in the solr code where we deal with Points fields and other older types of
> numeric fields.
>
> Original description...
> As Suggested by Adrien in
> [SOLR-8396|https://issues.apache.org/jira/browse/SOLR-8396?focusedCommentId=15828365=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15828365]
> {quote}
> in the below change, it looks like the logic that you apply to point fields
> would work in the general case and be as efficient?
> {code}
> +if (ft.isPointField()) {
> + for (String term : terms) {
> +int count = searcher.numDocs(ft.getFieldQuery(null, sf, term),
> parsed.docs);
> +res.add(term, count);
> + }
> +} else {
> + for (String term : terms) {
> +String internal = ft.toInternal(term);
> +int count = searcher.numDocs(new TermQuery(new Term(field,
> internal)), parsed.docs);
> +res.add(term, count);
> + }
> }
> {code}
> {quote}
--
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-11056) Add random range query test for PointFields
[ https://issues.apache.org/jira/browse/SOLR-11056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101950#comment-16101950 ] ASF subversion and git services commented on SOLR-11056: Commit 9372270f3f0c69634d169bd9dcf959b1eb2b2218 in lucene-solr's branch refs/heads/branch_7_0 from [~tomasflobbe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9372270 ] SOLR-11070, SOLR-11056: Make docValues range queries behave the same as Trie/Point fields for Double/Float Infinity cases > Add random range query test for PointFields > --- > > Key: SOLR-11056 > URL: https://issues.apache.org/jira/browse/SOLR-11056 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Tomás Fernández Löbbe >Assignee: Tomás Fernández Löbbe > Attachments: SOLR-11056.patch, SOLR-11056.patch > > > While working on SOLR-11043 I had some issues with range queries. I'm working > on adding a random test for range queries in points -- 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-11153) Incomplete schema results in mysterious error
[
https://issues.apache.org/jira/browse/SOLR-11153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated SOLR-11153:
Attachment: SOLR-11153.patch
Patch to have Solr assume "example" for the schema name and "1.0" for the
version, if they are not provided. If these values are used, a WARN message
will be logged.
> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a
> very minimal solrconfig and schema. The error was ultimately caused by NPE
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top
> level XML "schema" element in the file.
> {code}
>
>
>
> required="true"/>
> required="true"/>
>
> _id
>
>
>
>
> {code}
> As written, the code will explode with an NPE if either the name or version
> is missing from the schema. Although I can state that the user's minimal
> config/schema are not very useful, Solr should not blow up without a useful
> error message, and in this case, I think it should have worked, only emitting
> a WARN message and assuming a default name.
--
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-11070) DocValues range query behaves different than Trie/Point range queries for Float/Double "Infinity"
[ https://issues.apache.org/jira/browse/SOLR-11070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101949#comment-16101949 ] ASF subversion and git services commented on SOLR-11070: Commit 9372270f3f0c69634d169bd9dcf959b1eb2b2218 in lucene-solr's branch refs/heads/branch_7_0 from [~tomasflobbe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9372270 ] SOLR-11070, SOLR-11056: Make docValues range queries behave the same as Trie/Point fields for Double/Float Infinity cases > DocValues range query behaves different than Trie/Point range queries for > Float/Double "Infinity" > - > > Key: SOLR-11070 > URL: https://issues.apache.org/jira/browse/SOLR-11070 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Tomás Fernández Löbbe >Assignee: Tomás Fernández Löbbe > Fix For: 7.0 > > Attachments: SOLR-11070.patch, SOLR-11070.patch, SOLR-11070.patch, > SOLR-11070.patch, SOLR-11070.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] [Commented] (SOLR-10831) Document Replica Types
[ https://issues.apache.org/jira/browse/SOLR-10831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101960#comment-16101960 ] Cassandra Targett commented on SOLR-10831: -- OK, I'll take a crack at it and post a patch. I think it's (past) time to add a page about shard leaders & replicas and the new options can be covered there. I think users will need a better understanding of what the default behavior is in order to decide if they want/need to depart from it. > Document Replica Types > -- > > Key: SOLR-10831 > URL: https://issues.apache.org/jira/browse/SOLR-10831 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Tomás Fernández Löbbe >Assignee: Tomás Fernández Löbbe > Fix For: 7.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11153) Incomplete schema results in mysterious error
[
https://issues.apache.org/jira/browse/SOLR-11153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101988#comment-16101988
]
Shawn Heisey edited comment on SOLR-11153 at 7/26/17 5:45 PM:
--
I put 6.6 for the affected version, but I am pretty sure that this code has
been around at least since the managed-schema came on the scene, which was
quite a while ago. It probably affects versions 4.4 and later.
was (Author: elyograg):
I put 6.6 for the affected version, but I am pretty sure that this code has
been around for a LONG time, so the problem likely affects most versions of
Solr that have ever been released.
> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a
> very minimal solrconfig and schema. The error was ultimately caused by NPE
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top
> level XML "schema" element in the file.
> {code}
>
>
>
> required="true"/>
> required="true"/>
>
> _id
>
>
>
>
> {code}
> As written, the code will explode with an NPE if either the name or version
> is missing from the schema. Although I can state that the user's minimal
> config/schema are not very useful, Solr should not blow up without a useful
> error message, and in this case, I think it should have worked, only emitting
> a WARN message and assuming a default name.
--
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-10786) Add DBSCAN clustering Streaming Evaluator
[ https://issues.apache.org/jira/browse/SOLR-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-10786: -- Attachment: SOLR-10786.patch Added a testcase for dbscan clustering. Will do some manual testing on larger data sets now. > Add DBSCAN clustering Streaming Evaluator > - > > Key: SOLR-10786 > URL: https://issues.apache.org/jira/browse/SOLR-10786 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Fix For: master (8.0), 7.1 > > Attachments: SOLR-10786.patch, SOLR-10786.patch, SOLR-10786.patch > > > The DBSCAN clustering Stream Evaluator will cluster numeric vectors using the > DBSCAN clustering algorithm. > Clustering implementation will be provided by Apache Commons Math. -- 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-9910) Allow setting of additional jetty options in bin/solr and bin/solr.cmd
[
https://issues.apache.org/jira/browse/SOLR-9910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-9910:
Component/s: SolrCLI
> Allow setting of additional jetty options in bin/solr and bin/solr.cmd
> --
>
> Key: SOLR-9910
> URL: https://issues.apache.org/jira/browse/SOLR-9910
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Fix For: 7.0, 6.7
>
> Attachments: SOLR-9910.patch, SOLR-9910.patch
>
>
> Command line tools allow the option {{-a}} to add JVM options to start
> command. Proposing to add {{-j}} option to add additional config for jetty
> (the part after {{start.jar}}).
> Motivation: jetty can be configured with start.ini in server directory.
> Running multiple Solr instances, however, requires the configuration per
> instance that cannot share the start.ini with other instances.
--
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-10590) Add Cross Correlation Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-10590:
-
Component/s: streaming expressions
> Add Cross Correlation Stream Evaluator
> --
>
> Key: SOLR-10590
> URL: https://issues.apache.org/jira/browse/SOLR-10590
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Joel Bernstein
> Fix For: 7.0
>
>
> Now that we have basic correlation (SOLR-10582) implemented we can use it at
> as a basis for cross correlation. Apache commons math apparently does not
> have a cross correlation implementation, so it will need to be implemented.
> The basic approach taken will be to slide columnA along columnB and perform
> the correlation calculation until correlation is either 1.0 or max lag has
> been reached.
> Both *auto-correlation* and *auto-regression* can be built on top the
> cross-collation function.
> If anyone has an alternative more efficient approach or knows of an existing
> implementation that can be plugged in, please let me know.
> Syntax:
> {code}
> let(a=expr,
> b=expr,
> c=col(a, fieldName),
> d=col(b, fieldName),
> tuple(corr=xcorr(c,d,10)))
> {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] [Updated] (SOLR-10282) bin/solr support for enabling Kerberos security
[ https://issues.apache.org/jira/browse/SOLR-10282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-10282: - Component/s: SolrCLI > bin/solr support for enabling Kerberos security > --- > > Key: SOLR-10282 > URL: https://issues.apache.org/jira/browse/SOLR-10282 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCLI >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya > Fix For: 7.0 > > Attachments: SOLR-10282.patch, SOLR-10282.patch > > > This is in the same spirit as SOLR-8440. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10352) Low entropy warning in bin/solr script
[
https://issues.apache.org/jira/browse/SOLR-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-10352:
-
Component/s: SolrCLI
> Low entropy warning in bin/solr script
> --
>
> Key: SOLR-10352
> URL: https://issues.apache.org/jira/browse/SOLR-10352
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Reporter: Ishan Chattopadhyaya
> Fix For: 7.0
>
> Attachments: SOLR-10352.patch
>
>
> We should add a warning in the startup script for Linux, if the output of the
> following is below a certain threshold (maybe 300?). The warning could
> indicate that features like UUIDField, SSL etc. might not work properly (or
> be slow). As a hint, we could then suggest the user to configure a non
> blocking SecureRandom (SOLR-10338) or install rng-tools, haveged etc.
> {quote}
> cat /proc/sys/kernel/random/entropy_avail
> {quote}
> Original discussion:
> https://issues.apache.org/jira/browse/SOLR-10338?focusedCommentId=15938904=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15938904
--
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-10734) Multithreaded test/support for AtomicURP broken
[
https://issues.apache.org/jira/browse/SOLR-10734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102167#comment-16102167
]
Amrit Sarkar commented on SOLR-10734:
-
[~noble.paul] [~ichattopadhyaya],
Let me know if we need to do anything else apart from the above to rectify the
test class.
> Multithreaded test/support for AtomicURP broken
> ---
>
> Key: SOLR-10734
> URL: https://issues.apache.org/jira/browse/SOLR-10734
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
> Attachments: log-snippet, Screen Shot 2017-05-31 at 4.50.23 PM.png,
> SOLR-10734.patch
>
>
> The multithreaded test doesn't actually start the threads, but only invokes
> the run directly. The join afterwards doesn't do anything, hence.
> {code}
> diff --git
> a/solr/core/src/test/org/apache/solr/update/processor/AtomicUpdateProcessorFactoryTest.java
>
> b/solr/core/src/test/org/apache/solr/update/processor/AtomicUpdateProcessorFactoryTest.java
> index f3f833d..10b7770 100644
> ---
> a/solr/core/src/test/org/apache/solr/update/processor/AtomicUpdateProcessorFactoryTest.java
> +++
> b/solr/core/src/test/org/apache/solr/update/processor/AtomicUpdateProcessorFactoryTest.java
> @@ -238,7 +238,7 @@ public class AtomicUpdateProcessorFactoryTest extends
> SolrTestCaseJ4 {
>}
> }
>};
> - t.run();
> + t.run(); // red flag, shouldn't this be t.start?
>threads.add(t);
>finalCount += index; //int_i
> }
> {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-11151) SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value goes from null -> non-null
[
https://issues.apache.org/jira/browse/SOLR-11151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102186#comment-16102186
]
ASF subversion and git services commented on SOLR-11151:
Commit 42c6703726f52752ad9273acf61361504b4141c1 in lucene-solr's branch
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=42c6703 ]
SOLR-11151: remove unused imports
> SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value
> goes from null -> non-null
>
>
> Key: SOLR-11151
> URL: https://issues.apache.org/jira/browse/SOLR-11151
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-11151.patch
>
>
> {{MBeansHandler.testDiff()}} has been failing regularly on Jenkins, e.g.
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20192/]:
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=MBeansHandlerTest
> -Dtests.method=testDiff -Dtests.seed=CD7B1EB232DD9490 -Dtests.multiplier=3
> -Dtests.slow=true -Dtests.locale=es-PA -Dtests.timezone=Asia/Phnom_Penh
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR 0.02s J0 | MBeansHandlerTest.testDiff <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([CD7B1EB232DD9490:86DDA29226BACF0]:0)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
>[junit4]> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>[junit4]> at
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2473)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:337)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:319)
>[junit4]> at
> org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
> {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] [Updated] (SOLR-11140) (private) SolrMetricManager.prepareCloudPlugins has unused parameter
[
https://issues.apache.org/jira/browse/SOLR-11140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-11140:
-
Component/s: metrics
> (private) SolrMetricManager.prepareCloudPlugins has unused parameter
>
>
> Key: SOLR-11140
> URL: https://issues.apache.org/jira/browse/SOLR-11140
> Project: Solr
> Issue Type: Task
> Components: metrics
>Reporter: Christine Poerschke
>Priority: Minor
>
> {{SolrMetricManager.prepareCloudPlugins}} is a private method and its last
> parameter ({{defaultPlugin}}) is always passed in as {{null}} leading to an
> effectively dead/unreachable block of code in the method implementation.
> This ticket proposes to remove the unused parameter and associated
> unreachable block of 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
[JENKINS] Lucene-Solr-7.0-Linux (32bit/jdk1.8.0_141) - Build # 91 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/91/ Java: 32bit/jdk1.8.0_141 -client -XX:+UseParallelGC 12 tests failed. FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExpandComponent Error Message: Error from server at http://127.0.0.1:34363/solr/collection1: ERROR: [doc=1] unknown field 'test_ti' Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:34363/solr/collection1: ERROR: [doc=1] unknown field 'test_ti' at __randomizedtesting.SeedInfo.seed([C823BEAC51A01A5A:3AC5381FBE079650]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85) at org.apache.solr.client.solrj.SolrExampleTests.testExpandComponent(SolrExampleTests.java:1949) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at
[JENKINS] Lucene-Solr-Tests-7.x - Build # 104 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/104/ 14 tests failed. FAILED: org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete Error Message: Error from server at http://127.0.0.1:49368/solr/testcollection_shard1_replica_n3: Expected mime type application/octet-stream but got text/html.Error 404HTTP ERROR: 404 Problem accessing /solr/testcollection_shard1_replica_n3/update. Reason: Can not find: /solr/testcollection_shard1_replica_n3/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.14.v20161028 Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at http://127.0.0.1:49368/solr/testcollection_shard1_replica_n3: Expected mime type application/octet-stream but got text/html. Error 404 HTTP ERROR: 404 Problem accessing /solr/testcollection_shard1_replica_n3/update. Reason: Can not find: /solr/testcollection_shard1_replica_n3/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.14.v20161028 at __randomizedtesting.SeedInfo.seed([77E6A111AC81CE6C:D41C0FB42B6924C9]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233) at org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:167) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at
[jira] [Updated] (SOLR-11150) When V2Request is sent to the wrong node, it throws NPE
[ https://issues.apache.org/jira/browse/SOLR-11150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-11150: - Component/s: v2 API > When V2Request is sent to the wrong node, it throws NPE > --- > > Key: SOLR-11150 > URL: https://issues.apache.org/jira/browse/SOLR-11150 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: v2 API >Affects Versions: 6.6, 7.0 >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 7.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
[jira] [Updated] (SOLR-11144) Analytics Component Documentation
[ https://issues.apache.org/jira/browse/SOLR-11144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-11144: - Component/s: documentation > Analytics Component Documentation > - > > Key: SOLR-11144 > URL: https://issues.apache.org/jira/browse/SOLR-11144 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 7.0, 7.1 >Reporter: Houston Putman >Priority: Critical > > Adding a Solr Reference Guide page for the Analytics Component. -- 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-8492) Add LogisticRegressionQuery and LogitStream
[
https://issues.apache.org/jira/browse/SOLR-8492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-8492:
Component/s: streaming expressions
> Add LogisticRegressionQuery and LogitStream
> ---
>
> Key: SOLR-8492
> URL: https://issues.apache.org/jira/browse/SOLR-8492
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
> Fix For: 6.2, 7.0
>
> Attachments: logit.csv, SOLR-8492.diff, SOLR-8492.diff,
> SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch,
> SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch
>
>
> This ticket is to add a new query called a LogisticRegressionQuery (LRQ).
> The LRQ extends AnalyticsQuery
> (http://joelsolr.blogspot.com/2015/12/understanding-solrs-analyticsquery.html)
> and returns a DelegatingCollector that implements a Stochastic Gradient
> Descent (SGD) optimizer for Logistic Regression.
> This ticket also adds the LogitStream which leverages Streaming Expressions
> to provide iteration over the shards. Each call to LogitStream.read() calls
> down to the shards and executes the LogisticRegressionQuery. The model data
> is collected from the shards and the weights are averaged and sent back to
> the shards with the next iteration. Each call to read() returns a Tuple with
> the averaged weights and error from the shards. With this approach the
> LogitStream streams the changing model back to the client after each
> iteration.
> The LogitStream will return the EOF Tuple when it reaches the defined
> maxIterations. When sent as a Streaming Expression to the Stream handler this
> provides parallel iterative behavior. This same approach can be used to
> implement other parallel iterative algorithms.
> The initial patch has a test which simply tests the mechanics of the
> iteration. More work will need to be done to ensure the SGD is properly
> implemented. The distributed approach of the SGD will also need to be
> reviewed.
> This implementation is designed for use cases with a small number of features
> because each feature is it's own discreet field.
> An implementation which supports a higher number of features would be
> possible by packing features into a byte array and storing as binary
> DocValues.
> This implementation is designed to support a large sample set. With a large
> number of shards, a sample set into the billions may be possible.
> sample Streaming Expression Syntax:
> {code}
> logit(collection1, features="a,b,c,d,e,f" outcome="x" maxIterations="80")
> {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-11151) SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value goes from null -> non-null
[
https://issues.apache.org/jira/browse/SOLR-11151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102185#comment-16102185
]
ASF subversion and git services commented on SOLR-11151:
Commit 1d77e4cb2e835f6ece4af99c61772f9a5d02497f in lucene-solr's branch
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1d77e4c ]
SOLR-11151: remove unused imports
> SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value
> goes from null -> non-null
>
>
> Key: SOLR-11151
> URL: https://issues.apache.org/jira/browse/SOLR-11151
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-11151.patch
>
>
> {{MBeansHandler.testDiff()}} has been failing regularly on Jenkins, e.g.
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20192/]:
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=MBeansHandlerTest
> -Dtests.method=testDiff -Dtests.seed=CD7B1EB232DD9490 -Dtests.multiplier=3
> -Dtests.slow=true -Dtests.locale=es-PA -Dtests.timezone=Asia/Phnom_Penh
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR 0.02s J0 | MBeansHandlerTest.testDiff <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([CD7B1EB232DD9490:86DDA29226BACF0]:0)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
>[junit4]> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>[junit4]> at
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2473)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:337)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:319)
>[junit4]> at
> org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
> {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-11151) SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value goes from null -> non-null
[
https://issues.apache.org/jira/browse/SOLR-11151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102184#comment-16102184
]
ASF subversion and git services commented on SOLR-11151:
Commit fc356c8a300df370d56bb7fb2e9b7659faa17ff7 in lucene-solr's branch
refs/heads/branch_7_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fc356c8 ]
SOLR-11151: remove unused imports
> SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value
> goes from null -> non-null
>
>
> Key: SOLR-11151
> URL: https://issues.apache.org/jira/browse/SOLR-11151
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-11151.patch
>
>
> {{MBeansHandler.testDiff()}} has been failing regularly on Jenkins, e.g.
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20192/]:
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=MBeansHandlerTest
> -Dtests.method=testDiff -Dtests.seed=CD7B1EB232DD9490 -Dtests.multiplier=3
> -Dtests.slow=true -Dtests.locale=es-PA -Dtests.timezone=Asia/Phnom_Penh
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR 0.02s J0 | MBeansHandlerTest.testDiff <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([CD7B1EB232DD9490:86DDA29226BACF0]:0)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
>[junit4]> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>[junit4]> at
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2473)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:337)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:319)
>[junit4]> at
> org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
> {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] [Updated] (SOLR-10831) Document Replica Types
[ https://issues.apache.org/jira/browse/SOLR-10831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-10831: - Description: Write up documentation for the new replica types added with SOLR-10233. > Document Replica Types > -- > > Key: SOLR-10831 > URL: https://issues.apache.org/jira/browse/SOLR-10831 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Tomás Fernández Löbbe >Assignee: Tomás Fernández Löbbe > Fix For: 7.0 > > > Write up documentation for the new replica types added with SOLR-10233. -- 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-11151) SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value goes from null -> non-null
[
https://issues.apache.org/jira/browse/SOLR-11151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101876#comment-16101876
]
ASF subversion and git services commented on SOLR-11151:
Commit 615cc38b18105951e0c12ec8a9851c0baee13d19 in lucene-solr's branch
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=615cc38 ]
SOLR-11151: SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a
bean value goes from null -> non-null
> SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value
> goes from null -> non-null
>
>
> Key: SOLR-11151
> URL: https://issues.apache.org/jira/browse/SOLR-11151
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-11151.patch
>
>
> {{MBeansHandler.testDiff()}} has been failing regularly on Jenkins, e.g.
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20192/]:
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=MBeansHandlerTest
> -Dtests.method=testDiff -Dtests.seed=CD7B1EB232DD9490 -Dtests.multiplier=3
> -Dtests.slow=true -Dtests.locale=es-PA -Dtests.timezone=Asia/Phnom_Penh
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR 0.02s J0 | MBeansHandlerTest.testDiff <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([CD7B1EB232DD9490:86DDA29226BACF0]:0)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
>[junit4]> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>[junit4]> at
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2473)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:337)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:319)
>[junit4]> at
> org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
> {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-11151) SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value goes from null -> non-null
[
https://issues.apache.org/jira/browse/SOLR-11151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101875#comment-16101875
]
ASF subversion and git services commented on SOLR-11151:
Commit 85258370c25a5c646a4eaa274dca2add4e3888a0 in lucene-solr's branch
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8525837 ]
SOLR-11151: SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a
bean value goes from null -> non-null
> SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value
> goes from null -> non-null
>
>
> Key: SOLR-11151
> URL: https://issues.apache.org/jira/browse/SOLR-11151
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-11151.patch
>
>
> {{MBeansHandler.testDiff()}} has been failing regularly on Jenkins, e.g.
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20192/]:
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=MBeansHandlerTest
> -Dtests.method=testDiff -Dtests.seed=CD7B1EB232DD9490 -Dtests.multiplier=3
> -Dtests.slow=true -Dtests.locale=es-PA -Dtests.timezone=Asia/Phnom_Penh
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR 0.02s J0 | MBeansHandlerTest.testDiff <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([CD7B1EB232DD9490:86DDA29226BACF0]:0)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
>[junit4]> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>[junit4]> at
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2473)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:337)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:319)
>[junit4]> at
> org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
> {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-11151) SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value goes from null -> non-null
[
https://issues.apache.org/jira/browse/SOLR-11151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101874#comment-16101874
]
ASF subversion and git services commented on SOLR-11151:
Commit 117f60fb6a1d1004fdd5a863f7a8c7e3c5fa501f in lucene-solr's branch
refs/heads/branch_7_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=117f60f ]
SOLR-11151: SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a
bean value goes from null -> non-null
> SolrInfoMBeanHandler.getDiff() ADD case non-functional: NPE when a bean value
> goes from null -> non-null
>
>
> Key: SOLR-11151
> URL: https://issues.apache.org/jira/browse/SOLR-11151
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-11151.patch
>
>
> {{MBeansHandler.testDiff()}} has been failing regularly on Jenkins, e.g.
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20192/]:
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=MBeansHandlerTest
> -Dtests.method=testDiff -Dtests.seed=CD7B1EB232DD9490 -Dtests.multiplier=3
> -Dtests.slow=true -Dtests.locale=es-PA -Dtests.timezone=Asia/Phnom_Penh
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR 0.02s J0 | MBeansHandlerTest.testDiff <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([CD7B1EB232DD9490:86DDA29226BACF0]:0)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
>[junit4]> at
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
>[junit4]> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>[junit4]> at
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2473)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:337)
>[junit4]> at
> org.apache.solr.util.TestHarness.query(TestHarness.java:319)
>[junit4]> at
> org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
> {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-10926) increase the odds of randomly choosing point fields in our SolrTestCaseJ4 numeric type randomization
[
https://issues.apache.org/jira/browse/SOLR-10926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101923#comment-16101923
]
Steve Rowe commented on SOLR-10926:
---
If there are no objections, tomorrow I'll commit the patch below to increase
randomized points/trie testing ratio from 1:1 to 4:1. I plan on making this
ratio the same on master, branch_7x and branch_7_0.
{noformat}
diff --git a/solr/test-framework/src/java/org/apache/solr/SolrTestCaseJ4.java
b/solr/test-framework/src/java/org/apache/solr/SolrTestCaseJ4.java
index 6e23d45d30..0446093324 100644
--- a/solr/test-framework/src/java/org/apache/solr/SolrTestCaseJ4.java
+++ b/solr/test-framework/src/java/org/apache/solr/SolrTestCaseJ4.java
@@ -2705,7 +2705,7 @@ public abstract class SolrTestCaseJ4 extends
LuceneTestCase {
System.setProperty(NUMERIC_DOCVALUES_SYSPROP, ""+useDV);
// consume a consistent amount of random data even if sysprop/annotation
is set
-final boolean randUsePoints = random().nextBoolean();
+final boolean randUsePoints = 0 != random().nextInt(5); // 80% likelihood
final String usePointsStr = System.getProperty(USE_NUMERIC_POINTS_SYSPROP);
final boolean usePoints = (null == usePointsStr) ? randUsePoints :
Boolean.parseBoolean(usePointsStr);
{noformat}
> increase the odds of randomly choosing point fields in our SolrTestCaseJ4
> numeric type randomization
>
>
> Key: SOLR-10926
> URL: https://issues.apache.org/jira/browse/SOLR-10926
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Priority: Blocker
> Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> currently it's a 50/50 chance of using point fields vs trie fields ... once
> we are more confident in the utility/reliability of point fields and/or they
> are the "default" in our example configsets, we should tweak those odds so
> Point fields get tested much more often then TrieFields
--
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-11070) DocValues range query behaves different than Trie/Point range queries for Float/Double "Infinity"
[ https://issues.apache.org/jira/browse/SOLR-11070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101945#comment-16101945 ] ASF subversion and git services commented on SOLR-11070: Commit 847ab9e326e9462aab9c5b6429cc6f1ee93acb1d in lucene-solr's branch refs/heads/master from [~tomasflobbe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=847ab9e ] SOLR-11070, SOLR-11056: Make docValues range queries behave the same as Trie/Point fields for Double/Float Infinity cases > DocValues range query behaves different than Trie/Point range queries for > Float/Double "Infinity" > - > > Key: SOLR-11070 > URL: https://issues.apache.org/jira/browse/SOLR-11070 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Tomás Fernández Löbbe >Assignee: Tomás Fernández Löbbe > Fix For: 7.0 > > Attachments: SOLR-11070.patch, SOLR-11070.patch, SOLR-11070.patch, > SOLR-11070.patch, SOLR-11070.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] [Commented] (SOLR-11056) Add random range query test for PointFields
[ https://issues.apache.org/jira/browse/SOLR-11056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101948#comment-16101948 ] ASF subversion and git services commented on SOLR-11056: Commit e9cf285baf88628a994c2f2a9b1a8d54867b636c in lucene-solr's branch refs/heads/branch_7x from [~tomasflobbe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e9cf285 ] SOLR-11070, SOLR-11056: Make docValues range queries behave the same as Trie/Point fields for Double/Float Infinity cases > Add random range query test for PointFields > --- > > Key: SOLR-11056 > URL: https://issues.apache.org/jira/browse/SOLR-11056 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Tomás Fernández Löbbe >Assignee: Tomás Fernández Löbbe > Attachments: SOLR-11056.patch, SOLR-11056.patch > > > While working on SOLR-11043 I had some issues with range queries. I'm working > on adding a random test for range queries in points -- 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-11070) DocValues range query behaves different than Trie/Point range queries for Float/Double "Infinity"
[ https://issues.apache.org/jira/browse/SOLR-11070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101947#comment-16101947 ] ASF subversion and git services commented on SOLR-11070: Commit e9cf285baf88628a994c2f2a9b1a8d54867b636c in lucene-solr's branch refs/heads/branch_7x from [~tomasflobbe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e9cf285 ] SOLR-11070, SOLR-11056: Make docValues range queries behave the same as Trie/Point fields for Double/Float Infinity cases > DocValues range query behaves different than Trie/Point range queries for > Float/Double "Infinity" > - > > Key: SOLR-11070 > URL: https://issues.apache.org/jira/browse/SOLR-11070 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Tomás Fernández Löbbe >Assignee: Tomás Fernández Löbbe > Fix For: 7.0 > > Attachments: SOLR-11070.patch, SOLR-11070.patch, SOLR-11070.patch, > SOLR-11070.patch, SOLR-11070.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] [Commented] (SOLR-11056) Add random range query test for PointFields
[ https://issues.apache.org/jira/browse/SOLR-11056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101946#comment-16101946 ] ASF subversion and git services commented on SOLR-11056: Commit 847ab9e326e9462aab9c5b6429cc6f1ee93acb1d in lucene-solr's branch refs/heads/master from [~tomasflobbe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=847ab9e ] SOLR-11070, SOLR-11056: Make docValues range queries behave the same as Trie/Point fields for Double/Float Infinity cases > Add random range query test for PointFields > --- > > Key: SOLR-11056 > URL: https://issues.apache.org/jira/browse/SOLR-11056 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Tomás Fernández Löbbe >Assignee: Tomás Fernández Löbbe > Attachments: SOLR-11056.patch, SOLR-11056.patch > > > While working on SOLR-11043 I had some issues with range queries. I'm working > on adding a random test for range queries in points -- 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-SmokeRelease-master - Build # 824 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/824/ No tests ran. Build Log: [...truncated 25698 lines...] prepare-release-no-sign: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist [copy] Copying 476 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 215 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.02 sec (14.5 MB/sec) [smoker] check changes HTML... [smoker] download lucene-8.0.0-src.tgz... [smoker] 28.9 MB in 0.03 sec (837.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-8.0.0.tgz... [smoker] 68.9 MB in 0.08 sec (865.5 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-8.0.0.zip... [smoker] 79.2 MB in 0.09 sec (854.8 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 6128 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 6128 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 213 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 (226.7 MB/sec) [smoker] check changes HTML... [smoker] download solr-8.0.0-src.tgz... [smoker] 49.6 MB in 0.06 sec (769.6 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-8.0.0.tgz... [smoker] 141.6 MB in 0.18 sec (770.3 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-8.0.0.zip... [smoker] 142.6 MB in 0.18 sec (814.1 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 /x1/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 /x1/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=/x1/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 /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8 [smoker] Creating Solr home directory /x1/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] Started Solr server on port 8983 (pid=573). Happy searching! [smoker]
[jira] [Commented] (SOLR-10760) Remove trie field types and fields from example schemas
[ https://issues.apache.org/jira/browse/SOLR-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101890#comment-16101890 ] ASF subversion and git services commented on SOLR-10760: Commit a95168caf50524796a94d91b0adea86b1d09e767 in lucene-solr's branch refs/heads/branch_7_0 from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a95168c ] SOLR-10760: Remove trie field types and fields from example schemas > Remove trie field types and fields from example schemas > --- > > Key: SOLR-10760 > URL: https://issues.apache.org/jira/browse/SOLR-10760 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: 7.0 > > Attachments: SOLR-10760.patch, SOLR-10760.patch > > > In order to make points fields the default, we should remove all trie field > types and fields from example schemas. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11153) Incomplete schema results in mysterious error
[
https://issues.apache.org/jira/browse/SOLR-11153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101952#comment-16101952
]
Shawn Heisey edited comment on SOLR-11153 at 7/26/17 5:37 PM:
--
Patch to have Solr assume "example" for the schema name and "1.0" for the
version, if they are not provided. When one is missing, a WARN message will be
logged.
was (Author: elyograg):
Patch to have Solr assume "example" for the schema name and "1.0" for the
version, if they are not provided. If these values are used, a WARN message
will be logged.
> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a
> very minimal solrconfig and schema. The error was ultimately caused by NPE
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top
> level XML "schema" element in the file.
> {code}
>
>
>
> required="true"/>
> required="true"/>
>
> _id
>
>
>
>
> {code}
> As written, the code will explode with an NPE if either the name or version
> is missing from the schema. Although I can state that the user's minimal
> config/schema are not very useful, Solr should not blow up without a useful
> error message, and in this case, I think it should have worked, only emitting
> a WARN message and assuming a default name.
--
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-11153) Incomplete schema results in mysterious error
[
https://issues.apache.org/jira/browse/SOLR-11153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101977#comment-16101977
]
Shawn Heisey commented on SOLR-11153:
-
If anyone sees anywhere else where a missing value causes a problem that cannot
be easily diagnosed by a novice, please speak up and let's get it fixed.
> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a
> very minimal solrconfig and schema. The error was ultimately caused by NPE
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top
> level XML "schema" element in the file.
> {code}
>
>
>
> required="true"/>
> required="true"/>
>
> _id
>
>
>
>
> {code}
> As written, the code will explode with an NPE if either the name or version
> is missing from the schema. Although I can state that the user's minimal
> config/schema are not very useful, Solr should not blow up without a useful
> error message, and in this case, I think it should have worked, only emitting
> a WARN message and assuming a default name.
--
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
