[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1946 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1946/ No tests ran. Build Log: [...truncated 25 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
payload text is parsed in a backward order
I followed https://lucidworks.com/post/end-to-end-payload-example-in-solr/ to add a payload field for my solr schema and found out that the DelimitedPayloadTokenFilter used to parse payload input is parsing it in a backward order, which will let it always find the first delimiter ('|' in my case) to split on, which will result in parsing error for inputs like "abc|def|0.5" (`def|0.5` is not a float). And it makes sense if my key for this payload happen to contain a '|'. Is it possible to change it to split on the last delimiter or provide an option for this as the sub-string after the last delimiter is guaranteed to be a payload score? Many thanks, W
[JENKINS] Lucene-Solr-Tests-master - Build # 3652 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3652/ All tests passed Build Log: [...truncated 63924 lines...] -ecj-javadoc-lint-src: [mkdir] Created dir: /tmp/ecj286057262 [ecj-lint] Compiling 1289 source files to /tmp/ecj286057262 [ecj-lint] Processing annotations [ecj-lint] Annotations processed [ecj-lint] Processing annotations [ecj-lint] No elements to process [ecj-lint] invalid Class-Path header in manifest of jar file: /home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar [ecj-lint] invalid Class-Path header in manifest of jar file: /home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar [ecj-lint] -- [ecj-lint] 1. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java (at line 219) [ecj-lint] return (NamedList) new JavaBinCodec(resolver).unmarshal(in); [ecj-lint]^^ [ecj-lint] Resource leak: '' is never closed [ecj-lint] -- [ecj-lint] -- [ecj-lint] 2. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java (at line 232) [ecj-lint] ReplicationHandler replicationHandler = (ReplicationHandler) handler; [ecj-lint]^^ [ecj-lint] Resource leak: 'replicationHandler' is never closed [ecj-lint] -- [ecj-lint] 3. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java (at line 628) [ecj-lint] PeerSyncWithLeader peerSyncWithLeader = new PeerSyncWithLeader(core, [ecj-lint]^^ [ecj-lint] Resource leak: 'peerSyncWithLeader' is never closed [ecj-lint] -- [ecj-lint] -- [ecj-lint] 4. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java (at line 186) [ecj-lint] PeerSync peerSync = new PeerSync(core, syncWith, core.getUpdateHandler().getUpdateLog().getNumRecordsToKeep(), true, peerSyncOnlyWithActive, false); [ecj-lint] [ecj-lint] Resource leak: 'peerSync' is never closed [ecj-lint] -- [ecj-lint] -- [ecj-lint] 5. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java (at line 788) [ecj-lint] throw new UnsupportedOperationException("must add at least 1 node first"); [ecj-lint] ^^ [ecj-lint] Resource leak: 'queryRequest' is not closed at this location [ecj-lint] -- [ecj-lint] 6. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java (at line 794) [ecj-lint] throw new UnsupportedOperationException("must add at least 1 node first"); [ecj-lint] ^^ [ecj-lint] Resource leak: 'queryRequest' is not closed at this location [ecj-lint] -- [ecj-lint] -- [ecj-lint] 7. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/CoreContainer.java (at line 726) [ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean(); [ecj-lint]^^ [ecj-lint] Resource leak: 'fieldCacheBean' is never closed [ecj-lint] -- [ecj-lint] -- [ecj-lint] 8. ERROR in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java (at line 19) [ecj-lint] import javax.naming.Context; [ecj-lint] [ecj-lint] The type javax.naming.Context is not accessible [ecj-lint] -- [ecj-lint] 9. ERROR in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java (at line 20) [ecj-lint] import javax.naming.InitialContext; [ecj-lint]^^^ [ecj-lint] The type javax.naming.InitialContext is not accessible [ecj-lint] -- [ecj-lint] 10. ERROR in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java (at line 21) [ecj-lint] import javax.naming.NamingException; [ecj-lint] [ecj-lint] The type javax.naming.NamingException is not accessible [ecj-lint] -- [ecj-lint] 11. ERROR in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java (a
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 461 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/461/ 1 tests failed. FAILED: org.apache.solr.cloud.ReindexCollectionTest.testSameTargetReindexing Error Message: Solr11035BandAid failed, counts differ after updates: expected:<199> but was:<200> Stack Trace: java.lang.AssertionError: Solr11035BandAid failed, counts differ after updates: expected:<199> but was:<200> at __randomizedtesting.SeedInfo.seed([15B345B130871AD:B422DF8C146EE9E9]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.apache.solr.SolrTestCaseJ4.Solr11035BandAid(SolrTestCaseJ4.java:3144) at org.apache.solr.cloud.ReindexCollectionTest.indexDocs(ReindexCollectionTest.java:405) at org.apache.solr.cloud.ReindexCollectionTest.doTestSameTargetReindexing(ReindexCollectionTest.java:166) at org.apache.solr.cloud.ReindexCollectionTest.testSameTargetReindexing(ReindexCollectionTest.java:158) 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:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) 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:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$
[GitHub] [lucene-solr] megancarey opened a new pull request #850: SOLR-13727: Bug fix for V2Request handling in HttpSolrClient
megancarey opened a new pull request #850: SOLR-13727: Bug fix for V2Request handling in HttpSolrClient URL: https://github.com/apache/lucene-solr/pull/850 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I am authorized to contribute this code to the ASF and have removed any code I do not have a license to distribute. - [x] I have developed this patch against the `master` branch. - [x] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-NightlyTests-master - Build # 77 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-master/77/ 2 tests failed. FAILED: org.apache.lucene.codecs.simpletext.TestSimpleTextDocValuesFormat.testSparseLongNumericsVsStoredFields Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([3DEA610DC88B642E]:0) FAILED: junit.framework.TestSuite.org.apache.lucene.codecs.simpletext.TestSimpleTextDocValuesFormat Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([3DEA610DC88B642E]:0) Build Log: [...truncated 7915 lines...] [junit4] Suite: org.apache.lucene.codecs.simpletext.TestSimpleTextDocValuesFormat [junit4] 2> ao?t 30, 2019 1:02:21 PM com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate [junit4] 2> WARNING: Suite execution timed out: org.apache.lucene.codecs.simpletext.TestSimpleTextDocValuesFormat [junit4] 2>1) Thread[id=11, name=JUnit4-serializer-daemon, state=TIMED_WAITING, group=main] [junit4] 2> at java.base@11.0.1/java.lang.Thread.sleep(Native Method) [junit4] 2> at app//com.carrotsearch.ant.tasks.junit4.events.Serializer$1.run(Serializer.java:50) [junit4] 2>2) Thread[id=1, name=main, state=WAITING, group=main] [junit4] 2> at java.base@11.0.1/java.lang.Object.wait(Native Method) [junit4] 2> at java.base@11.0.1/java.lang.Thread.join(Thread.java:1305) [junit4] 2> at java.base@11.0.1/java.lang.Thread.join(Thread.java:1379) [junit4] 2> at app//com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:639) [junit4] 2> at app//com.carrotsearch.randomizedtesting.RandomizedRunner.run(RandomizedRunner.java:496) [junit4] 2> at app//com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:269) [junit4] 2> at app//com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:394) [junit4] 2> at app//com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13) [junit4] 2>3) Thread[id=762, name=TEST-TestSimpleTextDocValuesFormat.testSparseLongNumericsVsStoredFields-seed#[3DEA610DC88B642E], state=TIMED_WAITING, group=TGRP-TestSimpleTextDocValuesFormat] [junit4] 2> at java.base@11.0.1/java.lang.Object.wait(Native Method) [junit4] 2> at app//org.apache.lucene.index.IndexWriter.doWait(IndexWriter.java:4672) [junit4] 2> at app//org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1997) [junit4] 2> at app//org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1923) [junit4] 2> at app//org.apache.lucene.index.RandomIndexWriter.forceMerge(RandomIndexWriter.java:500) [junit4] 2> at app//org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestNumericsVsStoredFields(BaseDocValuesFormatTestCase.java:1250) [junit4] 2> at app//org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestNumericsVsStoredFields(BaseDocValuesFormatTestCase.java:1207) [junit4] 2> at app//org.apache.lucene.index.BaseDocValuesFormatTestCase.testSparseLongNumericsVsStoredFields(BaseDocValuesFormatTestCase.java:1417) [junit4] 2> at java.base@11.0.1/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4] 2> at java.base@11.0.1/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [junit4] 2> at java.base@11.0.1/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit4] 2> at java.base@11.0.1/java.lang.reflect.Method.invoke(Method.java:566) [junit4] 2> at app//com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) [junit4] 2> at app//com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) [junit4] 2> at app//com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) [junit4] 2> at app//com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) [junit4] 2> at app//org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) [junit4] 2> at app//org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) [junit4] 2> at app//org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) [junit4] 2> at app//org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) [junit4]
[jira] [Created] (SOLR-13730) payload text is parsed in a backward order
Weijie Wang created SOLR-13730: -- Summary: payload text is parsed in a backward order Key: SOLR-13730 URL: https://issues.apache.org/jira/browse/SOLR-13730 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: query parsers Affects Versions: 8.2 Reporter: Weijie Wang I followed [this|[https://lucidworks.com/post/end-to-end-payload-example-in-solr/]] to add a payload field for my solr schema and find out that DelimitedPayloadTokenFilter used to parse payload input is parsing it in a backward order, which will let it always find the first delimiter ('|' in my case) to split on, which will result in parsing error for inputs like "abc|def|0.5" (`def|0.5` is not a float). And it makes sense if my key for this payload happen to contain a '|'. Is it possible to change it to split on the last delimiter or provide an option for this as the sub-string after the last delimiter is guaranteed to be a payload score? -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13722) A cluster-wide blob upload package option
[ https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13722: -- Labels: package (was: ) > A cluster-wide blob upload package option > - > > Key: SOLR-13722 > URL: https://issues.apache.org/jira/browse/SOLR-13722 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Labels: package > > This ticket totally eliminates the need for an external service to host the > jars. So a url will no longer be required. > > Add a jar to cluster as follows > {code:java} > curl -X POST -H 'Content-Type: application/octet-stream' --data-binary > @myjar.jar http://localhost:8983/api/cluster/blob > {code} > This does the following operations > * Upload this jar to all the live nodes in the system > > Subsequently, when a node is started, it tries to get all the available blobs > from one of the live nodes where it is available. > > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13722) A cluster-wide blob upload package option
[ https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-13722: - Assignee: Noble Paul > A cluster-wide blob upload package option > - > > Key: SOLR-13722 > URL: https://issues.apache.org/jira/browse/SOLR-13722 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > This ticket totally eliminates the need for an external service to host the > jars. So a url will no longer be required. > > Add a jar to cluster as follows > {code:java} > curl -X POST -H 'Content-Type: application/octet-stream' --data-binary > @myjar.jar http://localhost:8983/api/cluster/blob > {code} > This does the following operations > * Upload this jar to all the live nodes in the system > > Subsequently, when a node is started, it tries to get all the available blobs > from one of the live nodes where it is available. > > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13722) A cluster-wide upload package option
[ https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13722: -- Description: This ticket totally eliminates the need for an external service to host the jars. So a url will no longer be required. Add a jar to cluster as follows {code:java} curl -X POST -H 'Content-Type: application/octet-stream' --data-binary @myjar.jar http://localhost:8983/api/cluster/blob {code} This does the following operations * Upload this jar to all the live nodes in the system Subsequently, when a node is started, it tries to get all the available blobs from one of the live nodes where it is available. was: This ticket totally eliminates the need for an external service to host the jars. So a url will no longer be required. Add a jar to cluster as follows {code:java} curl -X POST -H 'Content-Type: application/octet-stream' --data-binary @myjar.jar http://localhost:8983/api/cluster/package/mypkg {code} This does the following operations * Check if a package {{mypkg}} is already available , if yes , it is equivalent to an {{update-package}} command. if not, this is like an {{add-package}} * Upload this jar to all the live nodes in the system * Creates a package called {{mypkg}} with appropriate sha256 the end-point {{/api/cluster/package}} to list all the available packages Subsequently, when a node is started, it tries to get all the available packages from one of the live nodes where it is available. > A cluster-wide upload package option > > > Key: SOLR-13722 > URL: https://issues.apache.org/jira/browse/SOLR-13722 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > This ticket totally eliminates the need for an external service to host the > jars. So a url will no longer be required. > > Add a jar to cluster as follows > {code:java} > curl -X POST -H 'Content-Type: application/octet-stream' --data-binary > @myjar.jar http://localhost:8983/api/cluster/blob > {code} > This does the following operations > * Upload this jar to all the live nodes in the system > > Subsequently, when a node is started, it tries to get all the available blobs > from one of the live nodes where it is available. > > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13722) A cluster-wide blob upload package option
[ https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13722: -- Summary: A cluster-wide blob upload package option (was: A cluster-wide upload package option) > A cluster-wide blob upload package option > - > > Key: SOLR-13722 > URL: https://issues.apache.org/jira/browse/SOLR-13722 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > This ticket totally eliminates the need for an external service to host the > jars. So a url will no longer be required. > > Add a jar to cluster as follows > {code:java} > curl -X POST -H 'Content-Type: application/octet-stream' --data-binary > @myjar.jar http://localhost:8983/api/cluster/blob > {code} > This does the following operations > * Upload this jar to all the live nodes in the system > > Subsequently, when a node is started, it tries to get all the available blobs > from one of the live nodes where it is available. > > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13729) Add the caution that schemaless is not suitable for production to the "Schemaless Mode" section of the ref guide
[ https://issues.apache.org/jira/browse/SOLR-13729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-13729: -- Attachment: SOLR-13729.patch Status: Open (was: Open) Proposed wording for discouraging schemaless mode. I'll check it in over the weekend unless there are objections. > Add the caution that schemaless is not suitable for production to the > "Schemaless Mode" section of the ref guide > > > Key: SOLR-13729 > URL: https://issues.apache.org/jira/browse/SOLR-13729 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-13729.patch > > > I was asked "where do we point out that schemaless isn't recommended for > production?" and realized about the only place it comes up that a user can > reasonable be expected to see is when you use bin/solr to create a collection. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13691) Add example field type configurations using "name" attributes to Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919672#comment-16919672 ] Tomoko Uchida commented on SOLR-13691: -- Updated the patch. Will commit it to the master in shortly. > Add example field type configurations using "name" attributes to Ref Guide > -- > > Key: SOLR-13691 > URL: https://issues.apache.org/jira/browse/SOLR-13691 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-13691.patch, SOLR-13691.patch, Screenshot from > 2019-08-30 14-19-01.png, Screenshot from 2019-08-30 14-19-09.png > > > This is a follow-up task for SOLR-13593. > To encourage users to use the "name" attribute in field type configurations, > we should add examples that includes "name" instead of "class" (and mark > "Legacy" to the old examples). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13691) Add example field type configurations using "name" attributes to Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated SOLR-13691: - Attachment: SOLR-13691.patch > Add example field type configurations using "name" attributes to Ref Guide > -- > > Key: SOLR-13691 > URL: https://issues.apache.org/jira/browse/SOLR-13691 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-13691.patch, SOLR-13691.patch, Screenshot from > 2019-08-30 14-19-01.png, Screenshot from 2019-08-30 14-19-09.png > > > This is a follow-up task for SOLR-13593. > To encourage users to use the "name" attribute in field type configurations, > we should add examples that includes "name" instead of "class" (and mark > "Legacy" to the old examples). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8758) Class Field levelN is not populated correctly in QuadPrefixTree
[ https://issues.apache.org/jira/browse/LUCENE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-8758: - Fix Version/s: (was: 8.x) 8.3 Resolution: Fixed Status: Resolved (was: Patch Available) Thanks Amish. > Class Field levelN is not populated correctly in QuadPrefixTree > --- > > Key: LUCENE-8758 > URL: https://issues.apache.org/jira/browse/LUCENE-8758 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Affects Versions: 4.0, 5.0, 6.0, 7.0, 8.0 >Reporter: Dominic Page >Assignee: David Smiley >Priority: Trivial > Labels: beginner > Fix For: 8.3 > > Attachments: LUCENE-8758.patch > > > QuadPrefixTree in Lucene prepopulates these arrays: > {{levelW = new double[maxLevels];}} > {{levelH = new double[maxLevels];}} > {{*levelS = new int[maxLevels];*}} > {{*levelN = new int[maxLevels];*}} > Like this > {{for (int i = 1; i < levelW.length; i++) {}} > {{ levelW[i] = levelW[i - 1] / 2.0;}} > {{ levelH[i] = levelH[i - 1] / 2.0;}} > {{ *levelS[i] = levelS[i - 1] * 2;*}} > {{ *levelN[i] = levelN[i - 1] * 4;*}} > {{}}} > The field > {{levelN[]}} > overflows after level 14 = 1073741824 where maxLevels is limited to > {{MAX_LEVELS_POSSIBLE = 50;}} > The field levelN appears not to be used anywhere. Likewise, the field > {{levelS[] }} > is only used in the > {{printInfo}} > method. I would propose either to remove both > {{levelN[],}}{{levelS[]}} > or to change the datatype > {{levelN = new long[maxLevels];}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8758) Class Field levelN is not populated correctly in QuadPrefixTree
[ https://issues.apache.org/jira/browse/LUCENE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919588#comment-16919588 ] ASF subversion and git services commented on LUCENE-8758: - Commit f3b2358bc73b688341920d1753aecc39e6a9494a in lucene-solr's branch refs/heads/branch_8x from Amish Shah [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f3b2358 ] LUCENE-8758 Remove unused fields in QuadPrefixTree (cherry picked from commit ea67d9c8c65c6c883ef2ebb3c061fcc6b251a360) > Class Field levelN is not populated correctly in QuadPrefixTree > --- > > Key: LUCENE-8758 > URL: https://issues.apache.org/jira/browse/LUCENE-8758 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Affects Versions: 4.0, 5.0, 6.0, 7.0, 8.0 >Reporter: Dominic Page >Assignee: David Smiley >Priority: Trivial > Labels: beginner > Fix For: 8.x > > Attachments: LUCENE-8758.patch > > > QuadPrefixTree in Lucene prepopulates these arrays: > {{levelW = new double[maxLevels];}} > {{levelH = new double[maxLevels];}} > {{*levelS = new int[maxLevels];*}} > {{*levelN = new int[maxLevels];*}} > Like this > {{for (int i = 1; i < levelW.length; i++) {}} > {{ levelW[i] = levelW[i - 1] / 2.0;}} > {{ levelH[i] = levelH[i - 1] / 2.0;}} > {{ *levelS[i] = levelS[i - 1] * 2;*}} > {{ *levelN[i] = levelN[i - 1] * 4;*}} > {{}}} > The field > {{levelN[]}} > overflows after level 14 = 1073741824 where maxLevels is limited to > {{MAX_LEVELS_POSSIBLE = 50;}} > The field levelN appears not to be used anywhere. Likewise, the field > {{levelS[] }} > is only used in the > {{printInfo}} > method. I would propose either to remove both > {{levelN[],}}{{levelS[]}} > or to change the datatype > {{levelN = new long[maxLevels];}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8758) Class Field levelN is not populated correctly in QuadPrefixTree
[ https://issues.apache.org/jira/browse/LUCENE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919581#comment-16919581 ] ASF subversion and git services commented on LUCENE-8758: - Commit ea67d9c8c65c6c883ef2ebb3c061fcc6b251a360 in lucene-solr's branch refs/heads/master from Amish Shah [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ea67d9c ] LUCENE-8758 Remove unused fields in QuadPrefixTree > Class Field levelN is not populated correctly in QuadPrefixTree > --- > > Key: LUCENE-8758 > URL: https://issues.apache.org/jira/browse/LUCENE-8758 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Affects Versions: 4.0, 5.0, 6.0, 7.0, 8.0 >Reporter: Dominic Page >Assignee: David Smiley >Priority: Trivial > Labels: beginner > Fix For: 8.x > > Attachments: LUCENE-8758.patch > > > QuadPrefixTree in Lucene prepopulates these arrays: > {{levelW = new double[maxLevels];}} > {{levelH = new double[maxLevels];}} > {{*levelS = new int[maxLevels];*}} > {{*levelN = new int[maxLevels];*}} > Like this > {{for (int i = 1; i < levelW.length; i++) {}} > {{ levelW[i] = levelW[i - 1] / 2.0;}} > {{ levelH[i] = levelH[i - 1] / 2.0;}} > {{ *levelS[i] = levelS[i - 1] * 2;*}} > {{ *levelN[i] = levelN[i - 1] * 4;*}} > {{}}} > The field > {{levelN[]}} > overflows after level 14 = 1073741824 where maxLevels is limited to > {{MAX_LEVELS_POSSIBLE = 50;}} > The field levelN appears not to be used anywhere. Likewise, the field > {{levelS[] }} > is only used in the > {{printInfo}} > method. I would propose either to remove both > {{levelN[],}}{{levelS[]}} > or to change the datatype > {{levelN = new long[maxLevels];}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13729) Add the caution that schemaless is not suitable for production to the "Schemaless Mode" section of the ref guide
Erick Erickson created SOLR-13729: - Summary: Add the caution that schemaless is not suitable for production to the "Schemaless Mode" section of the ref guide Key: SOLR-13729 URL: https://issues.apache.org/jira/browse/SOLR-13729 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Erick Erickson Assignee: Erick Erickson I was asked "where do we point out that schemaless isn't recommended for production?" and realized about the only place it comes up that a user can reasonable be expected to see is when you use bin/solr to create a collection. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11185) Make DIH work with Schemaless mode.
[ https://issues.apache.org/jira/browse/SOLR-11185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-11185. --- Resolution: Duplicate > Make DIH work with Schemaless mode. > --- > > Key: SOLR-11185 > URL: https://issues.apache.org/jira/browse/SOLR-11185 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler, Data-driven Schema, Schema > and Analysis >Reporter: Kshitij Shukla >Priority: Minor > Labels: features > > Hello Everyone, > Hope you are all doing well. > Recently I have trying to make work a solr schemaless configuration with > DIH(mysql 5.6). After working on it around 4-5 Hrs I realized that schemaless > with DIH wont work. It might be my assumptions and chances are any of you > might know a way to make them together work. If so, please let me know how, > if not can this be treated as the improvement? > Best regards -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries
[ https://issues.apache.org/jira/browse/SOLR-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919526#comment-16919526 ] Dr Oleg Savrasov commented on SOLR-6930: Request Parameters are supposed to be configured like {code:java} {"params":{ "circuit.breaker":{ "circuit.breaker.enabled":"true", "threshold.unInvertedField":"30%", "":{"v":0} } }}{code} > Provide "Circuit Breakers" For Expensive Solr Queries > - > > Key: SOLR-6930 > URL: https://issues.apache.org/jira/browse/SOLR-6930 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Mike Drob >Priority: Major > Attachments: SOLR-6930.patch, SOLR-6930.patch, SOLR-6930.patch, > SOLR-6930.patch > > > Ref: > http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html > ES currently allows operators to configure "circuit breakers" to preemptively > fail queries that are estimated too large rather than allowing an OOM > Exception to happen. We might be able to do the same thing. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919512#comment-16919512 ] Rodney Aaron Stainback commented on SOLR-13434: --- Just curious if there is a target release for this feature, would really like it. > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries
[ https://issues.apache.org/jira/browse/SOLR-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911237#comment-16911237 ] Dr Oleg Savrasov edited comment on SOLR-6930 at 8/30/19 12:47 PM: -- Our customers very often experience OOM because of caching too large UnInvertedField items. This happens when they try to count facets or sort by not docvalues field. We don't want to fully disable UnInvertedFields usage because in some cases they work better than docvalues. For example, if the field is sparse and defined just in a few documents out of the millions, it seems better to create and cache relatively small UnInvertedField rather than traverse full docvalues structure. So to prevent OOM we need a kind of circuit breaker which would count memory utilized by UnInvertedField items and forbid caching them, when some configured threshold is exceeded. As you can see, with such an approach we are not trying to predict memory consumption, we're just restricting UnInvertedField cache by consumed memory. Since such a breakers try to control memory usage, ideally they should be part of some Global Resource Manager, see https://issues.apache.org/jira/browse/SOLR-13578. But we don't have such a manager so far, so for the time being we've tried to rely on existing Metric framework. Memory consumption is controlled by custom MetricReporter, so to enable circuit breaker it's necessary to configure appropriate unInvertedField metric reporter in solr.xml, for example: {code:java} 20% {code} was (Author: osavrasov): Our customers very often experience OOM because of caching too large UnInvertedField items. This happens when they try to count facets or sort by not docvalues field. We don't want to fully disable UnInvertedFields usage because in some cases they work better than docvalues. For example, if the field is sparse and defined just in a few documents out of the millions, it seems better to create and cache relatively small UnInvertedField rather than traverse full docvalues structure. So to prevent OOM we need a kind of circuit breaker which would count memory utilized by UnInvertedField items and forbid caching them, when some configured threshold is exceeded. As you can see, with such an approach we are not trying to predict memory consumption, we're just restricting UnInvertedField cache by consumed memory. Since such a breakers try to control memory usage, ideally they should be part of some Global Resource Manager, see https://issues.apache.org/jira/browse/SOLR-13578. But we don't have such a manager so far, so for the time being we've tried to rely on existing Metric framework. Memory consumption is controlled by custom MetricReporter, so to enable circuit breaker it's necessary to configure appropriate unInvertedField metric reporter in solr.xml, for example: {code:java} 20% {code} > Provide "Circuit Breakers" For Expensive Solr Queries > - > > Key: SOLR-6930 > URL: https://issues.apache.org/jira/browse/SOLR-6930 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Mike Drob >Priority: Major > Attachments: SOLR-6930.patch, SOLR-6930.patch, SOLR-6930.patch, > SOLR-6930.patch > > > Ref: > http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html > ES currently allows operators to configure "circuit breakers" to preemptively > fail queries that are estimated too large rather than allowing an OOM > Exception to happen. We might be able to do the same thing. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13122) Ability to query aliases in Solr Admin UI
[ https://issues.apache.org/jira/browse/SOLR-13122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-13122. Resolution: Fixed > Ability to query aliases in Solr Admin UI > - > > Key: SOLR-13122 > URL: https://issues.apache.org/jira/browse/SOLR-13122 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Reporter: mosh >Assignee: Jan Høydahl >Priority: Major > Labels: UI > Fix For: 8.3 > > Attachments: alias-collection-menu-selected.png, > alias-collection-view.png, alias-collections-menu.png, > alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, > alias-properties.png, alias-select-double.png, alias-view.png, > new-collection-dropdown.png, new-oll-overview.png > > Time Spent: 20m > Remaining Estimate: 0h > > After having recently toyed with Time Routed Alias in SolrCloud, > we have noticed there is no way to query an alias from the admin UI, > since the combo box only contains the current collection in the cluster. > Solr Admin UI ought to have a way to query these aliases, for better > convenience. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI
[ https://issues.apache.org/jira/browse/SOLR-13122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919500#comment-16919500 ] ASF subversion and git services commented on SOLR-13122: Commit e8c2b6af2abfe86196e15ebefc25337bb8536b1c in lucene-solr's branch refs/heads/branch_8x from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e8c2b6a ] SOLR-13122: Ability to query aliases in Solr Admin UI (cherry picked from commit 52be32d4addbead8536dbde84ed8c80af4993b8b) > Ability to query aliases in Solr Admin UI > - > > Key: SOLR-13122 > URL: https://issues.apache.org/jira/browse/SOLR-13122 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Reporter: mosh >Assignee: Jan Høydahl >Priority: Major > Labels: UI > Fix For: 8.3 > > Attachments: alias-collection-menu-selected.png, > alias-collection-view.png, alias-collections-menu.png, > alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, > alias-properties.png, alias-select-double.png, alias-view.png, > new-collection-dropdown.png, new-oll-overview.png > > Time Spent: 20m > Remaining Estimate: 0h > > After having recently toyed with Time Routed Alias in SolrCloud, > we have noticed there is no way to query an alias from the admin UI, > since the combo box only contains the current collection in the cluster. > Solr Admin UI ought to have a way to query these aliases, for better > convenience. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries
[ https://issues.apache.org/jira/browse/SOLR-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919491#comment-16919491 ] Dr Oleg Savrasov commented on SOLR-6930: Patch is reworked to use Request Parameters API in order to modify Memory Circuit Breaker configuration on the fly. > Provide "Circuit Breakers" For Expensive Solr Queries > - > > Key: SOLR-6930 > URL: https://issues.apache.org/jira/browse/SOLR-6930 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Mike Drob >Priority: Major > Attachments: SOLR-6930.patch, SOLR-6930.patch, SOLR-6930.patch, > SOLR-6930.patch > > > Ref: > http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html > ES currently allows operators to configure "circuit breakers" to preemptively > fail queries that are estimated too large rather than allowing an OOM > Exception to happen. We might be able to do the same thing. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries
[ https://issues.apache.org/jira/browse/SOLR-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dr Oleg Savrasov updated SOLR-6930: --- Attachment: SOLR-6930.patch > Provide "Circuit Breakers" For Expensive Solr Queries > - > > Key: SOLR-6930 > URL: https://issues.apache.org/jira/browse/SOLR-6930 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Mike Drob >Priority: Major > Attachments: SOLR-6930.patch, SOLR-6930.patch, SOLR-6930.patch, > SOLR-6930.patch > > > Ref: > http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html > ES currently allows operators to configure "circuit breakers" to preemptively > fail queries that are estimated too large rather than allowing an OOM > Exception to happen. We might be able to do the same thing. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI
[ https://issues.apache.org/jira/browse/SOLR-13122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919490#comment-16919490 ] ASF subversion and git services commented on SOLR-13122: Commit 52be32d4addbead8536dbde84ed8c80af4993b8b in lucene-solr's branch refs/heads/master from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=52be32d ] SOLR-13122: Ability to query aliases in Solr Admin UI > Ability to query aliases in Solr Admin UI > - > > Key: SOLR-13122 > URL: https://issues.apache.org/jira/browse/SOLR-13122 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Reporter: mosh >Assignee: Jan Høydahl >Priority: Major > Labels: UI > Fix For: 8.3 > > Attachments: alias-collection-menu-selected.png, > alias-collection-view.png, alias-collections-menu.png, > alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, > alias-properties.png, alias-select-double.png, alias-view.png, > new-collection-dropdown.png, new-oll-overview.png > > Time Spent: 20m > Remaining Estimate: 0h > > After having recently toyed with Time Routed Alias in SolrCloud, > we have noticed there is no way to query an alias from the admin UI, > since the combo box only contains the current collection in the cluster. > Solr Admin UI ought to have a way to query these aliases, for better > convenience. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy closed pull request #745: SOLR-13122: Ability to query aliases in Solr Admin UI
janhoy closed pull request #745: SOLR-13122: Ability to query aliases in Solr Admin UI URL: https://github.com/apache/lucene-solr/pull/745 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13728) Fail partial updates if it would inadvertently remove nested docs
[ https://issues.apache.org/jira/browse/SOLR-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919466#comment-16919466 ] Lucene/Solr QA commented on SOLR-13728: --- | (/) *{color:green}+1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | || || || || {color:brown} master Compile Tests {color} || | {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 38s{color} | {color:green} master passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 58s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 58s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} Release audit (RAT) {color} | {color:green} 3m 58s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} Check forbidden APIs {color} | {color:green} 3m 58s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} Validate source patterns {color} | {color:green} 3m 58s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 47m 39s{color} | {color:green} core in the patch passed. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 57m 38s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | JIRA Issue | SOLR-13728 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12978939/SOLR-13728.patch | | Optional Tests | compile javac unit ratsources checkforbiddenapis validatesourcepatterns | | uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | ant | | Personality | /home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh | | git revision | master / 6dea678 | | ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 | | Default Java | LTS | | Test Results | https://builds.apache.org/job/PreCommit-SOLR-Build/543/testReport/ | | modules | C: solr/core U: solr/core | | Console output | https://builds.apache.org/job/PreCommit-SOLR-Build/543/console | | Powered by | Apache Yetus 0.7.0 http://yetus.apache.org | This message was automatically generated. > Fail partial updates if it would inadvertently remove nested docs > - > > Key: SOLR-13728 > URL: https://issues.apache.org/jira/browse/SOLR-13728 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: SOLR-13728.patch > > > In SOLR-12638 Solr gained the ability to do partial updates (aka atomic > updates) to nested documents. However this feature only works if the schema > meets certain circumstances. We can know we don't support it and fail the > request – what I propose here. This is much friendlier than wiping out > existing documents. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 195 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/195/ No tests ran. Build Log: [...truncated 24871 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2594 links (2120 relative) to 3410 anchors in 259 files [echo] Validated Links & Anchors via: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked [untar] Expanding: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/solr-8.3.0.tgz into /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:c
[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-526540019 Thanks @jimczi ! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - 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 # 3649 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3649/ All tests passed Build Log: [...truncated 63909 lines...] -ecj-javadoc-lint-src: [mkdir] Created dir: /tmp/ecj237353181 [ecj-lint] Compiling 1289 source files to /tmp/ecj237353181 [ecj-lint] Processing annotations [ecj-lint] Annotations processed [ecj-lint] Processing annotations [ecj-lint] No elements to process [ecj-lint] invalid Class-Path header in manifest of jar file: /home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar [ecj-lint] invalid Class-Path header in manifest of jar file: /home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar [ecj-lint] -- [ecj-lint] 1. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java (at line 219) [ecj-lint] return (NamedList) new JavaBinCodec(resolver).unmarshal(in); [ecj-lint]^^ [ecj-lint] Resource leak: '' is never closed [ecj-lint] -- [ecj-lint] -- [ecj-lint] 2. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java (at line 232) [ecj-lint] ReplicationHandler replicationHandler = (ReplicationHandler) handler; [ecj-lint]^^ [ecj-lint] Resource leak: 'replicationHandler' is never closed [ecj-lint] -- [ecj-lint] 3. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java (at line 628) [ecj-lint] PeerSyncWithLeader peerSyncWithLeader = new PeerSyncWithLeader(core, [ecj-lint]^^ [ecj-lint] Resource leak: 'peerSyncWithLeader' is never closed [ecj-lint] -- [ecj-lint] -- [ecj-lint] 4. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java (at line 186) [ecj-lint] PeerSync peerSync = new PeerSync(core, syncWith, core.getUpdateHandler().getUpdateLog().getNumRecordsToKeep(), true, peerSyncOnlyWithActive, false); [ecj-lint] [ecj-lint] Resource leak: 'peerSync' is never closed [ecj-lint] -- [ecj-lint] -- [ecj-lint] 5. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java (at line 788) [ecj-lint] throw new UnsupportedOperationException("must add at least 1 node first"); [ecj-lint] ^^ [ecj-lint] Resource leak: 'queryRequest' is not closed at this location [ecj-lint] -- [ecj-lint] 6. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java (at line 794) [ecj-lint] throw new UnsupportedOperationException("must add at least 1 node first"); [ecj-lint] ^^ [ecj-lint] Resource leak: 'queryRequest' is not closed at this location [ecj-lint] -- [ecj-lint] -- [ecj-lint] 7. WARNING in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/CoreContainer.java (at line 726) [ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean(); [ecj-lint]^^ [ecj-lint] Resource leak: 'fieldCacheBean' is never closed [ecj-lint] -- [ecj-lint] -- [ecj-lint] 8. ERROR in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java (at line 19) [ecj-lint] import javax.naming.Context; [ecj-lint] [ecj-lint] The type javax.naming.Context is not accessible [ecj-lint] -- [ecj-lint] 9. ERROR in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java (at line 20) [ecj-lint] import javax.naming.InitialContext; [ecj-lint]^^^ [ecj-lint] The type javax.naming.InitialContext is not accessible [ecj-lint] -- [ecj-lint] 10. ERROR in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java (at line 21) [ecj-lint] import javax.naming.NamingException; [ecj-lint] [ecj-lint] The type javax.naming.NamingException is not accessible [ecj-lint] -- [ecj-lint] 11. ERROR in /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java (a