[GitHub] lucene-solr pull request: Customize number of logs and records to ...
Github user andyetitmoves closed the pull request at: https://github.com/apache/lucene-solr/pull/83 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: Customize number of logs and records to ...
Github user andyetitmoves commented on the pull request: https://github.com/apache/lucene-solr/pull/83#issuecomment-86399314 There's no guarantee of further releases to 4.x and this release should be in 5.1 which should come out in the next few weeks. That said, the patch should apply reasonably cleanly to 4x afaik, you just have to do it yourself. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6359) Allow customization of the number of records and logs kept by UpdateLog
[
https://issues.apache.org/jira/browse/SOLR-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381563#comment-14381563
]
ASF GitHub Bot commented on SOLR-6359:
--
Github user andyetitmoves closed the pull request at:
https://github.com/apache/lucene-solr/pull/83
Allow customization of the number of records and logs kept by UpdateLog
---
Key: SOLR-6359
URL: https://issues.apache.org/jira/browse/SOLR-6359
Project: Solr
Issue Type: Improvement
Reporter: Ramkumar Aiyengar
Assignee: Ramkumar Aiyengar
Priority: Minor
Fix For: Trunk, 5.1
Attachments: SOLR-6359.patch
Currently {{UpdateLog}} hardcodes the number of logs and records it keeps,
and the hardcoded numbers (100 records, 10 logs) can be quite low (esp. the
records) in an heavily indexing setup, leading to full recovery even if Solr
was just stopped and restarted.
These values should be customizable (even if only present as expert options).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7307) Make it easier to create an EmbeddedSolrServer
[ https://issues.apache.org/jira/browse/SOLR-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381612#comment-14381612 ] ASF subversion and git services commented on SOLR-7307: --- Commit 1669305 from [~romseygeek] in branch 'dev/trunk' [ https://svn.apache.org/r1669305 ] SOLR-7307: Add constructors to EmbeddedSolrServer taking Path or NodeConfig Make it easier to create an EmbeddedSolrServer -- Key: SOLR-7307 URL: https://issues.apache.org/jira/browse/SOLR-7307 Project: Solr Issue Type: Improvement Reporter: Alan Woodward Attachments: SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch At the moment, if you want to create an EmbeddedSolrServer you have to instantiate a CoreContainer and then pass it in to the ESS constructor, which involves a fair amount of ceremony. You should be able to just pass a path to a solr home directory, or a NodeConfig object. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7307) Make it easier to create an EmbeddedSolrServer
[ https://issues.apache.org/jira/browse/SOLR-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381629#comment-14381629 ] ASF subversion and git services commented on SOLR-7307: --- Commit 1669308 from [~romseygeek] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1669308 ] SOLR-7307: Add constructors to EmbeddedSolrServer taking Path or NodeConfig Make it easier to create an EmbeddedSolrServer -- Key: SOLR-7307 URL: https://issues.apache.org/jira/browse/SOLR-7307 Project: Solr Issue Type: Improvement Reporter: Alan Woodward Attachments: SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch At the moment, if you want to create an EmbeddedSolrServer you have to instantiate a CoreContainer and then pass it in to the ESS constructor, which involves a fair amount of ceremony. You should be able to just pass a path to a solr home directory, or a NodeConfig object. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7307) Make it easier to create an EmbeddedSolrServer
[ https://issues.apache.org/jira/browse/SOLR-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved SOLR-7307. - Resolution: Fixed Assignee: Alan Woodward Thanks all. Make it easier to create an EmbeddedSolrServer -- Key: SOLR-7307 URL: https://issues.apache.org/jira/browse/SOLR-7307 Project: Solr Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Attachments: SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch At the moment, if you want to create an EmbeddedSolrServer you have to instantiate a CoreContainer and then pass it in to the ESS constructor, which involves a fair amount of ceremony. You should be able to just pass a path to a solr home directory, or a NodeConfig object. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7296) Reconcile facetting implementations
[ https://issues.apache.org/jira/browse/SOLR-7296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381615#comment-14381615 ] Toke Eskildsen commented on SOLR-7296: -- Shai: For me the main concern is not the sidecar part, but the central part. I am thinking about distributed search here. Is Lucene faceting with taxonomy index capable of merging facet results across installations (needed for SolrCloud) and if so, do they each have their own independent taxonomy indexes or do they need to share a single one? As for hierarchical faceting, then Solr currently does not have real support for that. Being the author of LUCENE-2369 SOLR-2412 I would like to see it happen, both for Solr and Lucene DV. That is for another JIRA, so I'll just add that the technique I used was to have an auxiliary structure with a numeric entry for each ordinal, which was calculated from a single pass through all paths. Reconcile facetting implementations --- Key: SOLR-7296 URL: https://issues.apache.org/jira/browse/SOLR-7296 Project: Solr Issue Type: Task Components: faceting Reporter: Steve Molloy SOLR-7214 introduced a new way of controlling faceting, the unmbrella SOLR-6348 brings a lot of improvements in facet functionality, namely around pivots. Both make a lot of sense from a user perspective, but currently have completely different implementations. With the analytics components, this makes 3 implementation of the same logic, which is bound to behave differently as time goes by. We should reconcile all implementations to ease maintenance and offer consistent behaviour no matter how parameters are passed to the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_40) - Build # 4596 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4596/ Java: 32bit/jdk1.8.0_40 -client -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestSolrConfigHandler Error Message: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010\collection1\conf\configoverlay.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010\collection1\conf\configoverlay.json: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010\collection1\conf\configoverlay.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010\collection1\conf\configoverlay.json: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 2DF619A50A6022A7-001: java.nio.file.DirectoryNotEmptyException:
Re: Guidelines for backporting to 4x?
Thanks guys. To be clear, I don't think that this change is worth a release. If at all, I was planning to just go on the back of a 4.10.5 if there was one (I know at least of one thread where it was mentioned sometime back, but I realise it might not happen..) On 25 Mar 2015 15:48, Erick Erickson erickerick...@gmail.com wrote: Shawn pretty well nailed it. Especially this bit: ...unless you are also volunteering to be the release manager. There'll be some push-back even if you're willing to be the RM if it's a big change, but that's a discussion for we'll have when there's a concrete proposal. Best, Erick On Wed, Mar 25, 2015 at 7:34 AM, Shawn Heisey apa...@elyograg.org wrote: On 3/25/2015 3:24 AM, Ramkumar R. Aiyengar wrote: I know patches are generally for bug fixes, but given that it is the end of line branch for 4x, do we accommodate requests for back porting small features, or just ask them to patch it themselves? I would appreciate a sanity check from someone who has a longer history with the project, but this is my understanding: If there is a critical or trivial bugfix, or a very useful usability enhancement that can be considered an easy and safe change (a small patch that doesn't affect API compatibility at all), then it might make sense to backport, but unless you are also volunteering to be the release manager, it may be quite a while before users actually see a 4.10.x release with the change. As time passes and branch_5x diverges further from the 4.10 branch (which is now considered to be in maintenance mode), it will become increasingly difficult to backport. In some ways, this means that 4x will be effectively dead as soon as we have a battle-tested 5.x version that we are willing to recommend for even a conservative novice user. For the most part, unless the patch addresses a serious problem that affects a lot of users, the user will need to patch the 4.x code themselves. This info should probably be in the wiki, if it is not already. I didn't look. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2836 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2836/ 4 tests failed. REGRESSION: org.apache.solr.handler.component.DistributedMLTComponentTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:45361/hxqr/o/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:45361/hxqr/o/collection1 at __randomizedtesting.SeedInfo.seed([77E3E74BCE072F65:FFB7D89160FB429D]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:594) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:236) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:228) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958) at org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:556) at org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:604) at org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:586) at org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:565) at org.apache.solr.handler.component.DistributedMLTComponentTest.test(DistributedMLTComponentTest.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:958) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:933) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_40) - Build # 4479 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4479/ Java: 32bit/jdk1.8.0_40 -client -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestSolrConfigHandler Error Message: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010\collection1\conf\params.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010\collection1\conf\params.json: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010\collection1\conf\params.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010\collection1\conf\params.json: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler ABD4D7A637EA8B77-001: java.nio.file.DirectoryNotEmptyException:
[jira] [Commented] (SOLR-7296) Reconcile facetting implementations
[ https://issues.apache.org/jira/browse/SOLR-7296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381651#comment-14381651 ] Shai Erera commented on SOLR-7296: -- bq. Is Lucene faceting with taxonomy index capable of merging facet results across installations (needed for SolrCloud) and if so, do they each have their own independent taxonomy indexes or do they need to share a single one? Yes, definitely though the code isn't part of Lucene facet module. There are two options: * Share a single taxonomy index for all shards. This was done in cases where the indexes were created via MapReduce, and then left read-only. The taxonomy index was still collocated with each shard (copied), but it was never updated. This I admit is not the common case, but it's doable. * Have each shard manage its own taxonomy index. When you ask for top-K values of the facet Author you get the top-K values from each shard and merge them. Obviously this is simpler than what really happens, since you need to make sure that you return the true global top-K values, but I believe Solr already handles that. I don't know the full details of the Solr implementation, but I believe it involves two phases, where in the first phase each shard returns its top-K (or top-cK) values, and then the merger decides if it needs to go back to some shards, since they may contribute to same of the facet values that didn't make it to the top-K, while they should. I read your blogs on Solr faceting, so I'm sure you know the details better than me :). I would like to assume that the second phase of distributed faceted search is rather generic and shouldn't depend on one facet implementation or another. I.e. if it receives a ranked list of facet values and counts/weights (String + Integer/Float), it shouldn't care which facet impl generated these correct? So to answer your question, it is doable, but lucene-facet currently don't offer tools to do that. However, I hope the Solr implementation can be ported/reused straightforwardly. If you know which code in Solr does that, I'd be happy to take a look. Reconcile facetting implementations --- Key: SOLR-7296 URL: https://issues.apache.org/jira/browse/SOLR-7296 Project: Solr Issue Type: Task Components: faceting Reporter: Steve Molloy SOLR-7214 introduced a new way of controlling faceting, the unmbrella SOLR-6348 brings a lot of improvements in facet functionality, namely around pivots. Both make a lot of sense from a user perspective, but currently have completely different implementations. With the analytics components, this makes 3 implementation of the same logic, which is bound to behave differently as time goes by. We should reconcile all implementations to ease maintenance and offer consistent behaviour no matter how parameters are passed to the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6894) Introduce SolrNodeClient API
[ https://issues.apache.org/jira/browse/SOLR-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved SOLR-6894. - Resolution: Won't Fix SOLR-7155 solved this. Introduce SolrNodeClient API Key: SOLR-6894 URL: https://issues.apache.org/jira/browse/SOLR-6894 Project: Solr Issue Type: New Feature Components: SolrJ Affects Versions: 5.0, Trunk Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Attachments: SOLR-6894.patch At the moment, it isn't possible to use a single SolrServer instance to create new cores via CoreAdmin on an empty node, and then query those nodes. MultiCoreSolrServer is a utility class that does just that, by allowing you to create child SolrServer instances for individual cores that share the underlying HttpClient. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4988) Upgrade svnkit to version compatible with svn 1.8
[ https://issues.apache.org/jira/browse/SOLR-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved SOLR-4988. - Resolution: Duplicate Resolved by LUCENE-5385 Upgrade svnkit to version compatible with svn 1.8 - Key: SOLR-4988 URL: https://issues.apache.org/jira/browse/SOLR-4988 Project: Solr Issue Type: Task Reporter: Alan Woodward Assignee: Alan Woodward Attachments: SOLR-4988.patch If you've got subversion 1.8 installed, ant precommit fails due to svn version incompatibilities. It looks as though there isn't an svnkit release yet that supports 1.8. Once one is available, we should upgrade our dependencies. See http://subversion.1072662.n5.nabble.com/ETA-on-1-8-support-td181632.html -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7203) NoHttpResponseException handling in HttpSolrClient is wrong
[ https://issues.apache.org/jira/browse/SOLR-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381697#comment-14381697 ] ASF subversion and git services commented on SOLR-7203: --- Commit 1669316 from [~romseygeek] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1669316 ] SOLR-7203: Remove buggy no-op retries in HttpSolrClient NoHttpResponseException handling in HttpSolrClient is wrong --- Key: SOLR-7203 URL: https://issues.apache.org/jira/browse/SOLR-7203 Project: Solr Issue Type: Bug Reporter: Alan Woodward Assignee: Alan Woodward Attachments: SOLR-7203.patch, SOLR-7203.patch, SOLR-7203.patch We've got logic in HttpSolrClient to catch NoHttpResponseException and retry. However, this logic appears to be in the wrong place - it's in the createMethod function, which doesn't actually execute any http requests at all. It ought to be in executeMethod. Fixing this might help sort out the persistent Jenkins failures as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: jhighlight-1.0 contains LGPL-only files
Looks like 5.1 release process will start soon - should we remove this .jar
before the release? I see there's some progress on TIKA-1581, but it
doesn't look like it's going to be resolved that soon.
Shai
On Fri, Mar 20, 2015 at 2:59 PM, Karl Wright daddy...@gmail.com wrote:
I suspect that the classes in question are in fact *not* used by Tika in
any capacity, but they are in the jar nonetheless. So one solution would
be to simply repackage the jar. I'd like to see what the Tika team says.
Karl
On Fri, Mar 20, 2015 at 7:47 AM, Shai Erera ser...@gmail.com wrote:
although it might be easier to work with Tika to fix that and then
upgrade again.
If jhighlight was brought into Solr distribution as a transitive
dependency then you're right, but since we pull it in explicitly (even if
for runtime purposes only), I think we should remove it, whether Tika
corrects the problem or not. We can put a note in our NOTICE file for users
to download the jar themselves until Tika fixes the problem.
If people agree, I will remove it from our code.
Shai
On Fri, Mar 20, 2015 at 10:40 AM, Karl Wright daddy...@gmail.com wrote:
I have created a ticket: TIKA-1581. ManifoldCF also has a Tika
dependency, so thank you for noting the problem.
Karl
On Fri, Mar 20, 2015 at 4:03 AM, Upayavira u...@odoko.co.uk wrote:
You are right -both projects need to remove it, although it might be
easier to work with Tika to fix that and then upgrade again.
Upayavira
On Fri, Mar 20, 2015, at 05:26 AM, Shai Erera wrote:
Sorry for the spam, just wanted to note that this dependency was
added by
Steve in SOLR-6130 to resolve improper Tika 1.4-1.5 upgrade.
The core issue lies with Tika IMO (they shouldn't rely on LGPL code
too I
believe), but I am not sure if it's OK that we distribute this .jar
ourselves.
Shai
On Fri, Mar 20, 2015 at 7:17 AM, Shai Erera ser...@gmail.com wrote:
One update, I did find this dependency is explicitly set in
solr/contrib/extraction/ivy.xml, under the Tika dependencies
section:
!-- Tika dependencies - see
http://tika.apache.org/1.3/gettingstarted.html#Using_Tika_as_a_Maven_dependency
--
!-- When upgrading Tika, upgrade dependencies versions and add
any
new ones
(except slf4j-api, commons-codec, commons-logging,
commons-httpclient, geronimo-stax-api_1.0_spec, jcip-annotations,
xml-apis,
asm)
WARNING: Don't add netcdf / unidataCommon (partially LGPL
code)
--
...
dependency org=com.uwyn name=jhighlight
rev=${/com.uwyn/jhighlight} conf=compile/
So it does seem like needed by Tika only and I guess it's a runtime
dependency, so if we don't want to release this LGPL library, we
can omit
it and put a section in the NOTICE file?
Shai
On Fri, Mar 20, 2015 at 7:11 AM, Shai Erera ser...@gmail.com
wrote:
Hi
Solr's contrib/extraction contains jhighlight-1.0.jar which
declares
itself as dual CDDL or LGPL license. However, some of its classes
are
distributed only under LGPL, e.g.
com.uwyn.jhighlight.highlighter.
CppHighlighter.java
GroovyHighlighter.java
JavaHighlighter.java
XmlHighlighter.java
I downloaded the sources from Maven (
http://search.maven.org/remotecontent?filepath=com/uwyn/jhighlight/1.0/jhighlight-1.0-sources.jar
)
to confirm that, and also found this SVN repo:
http://svn.rifers.org/jhighlight/tags/release-1.0, though the
project's
website seems to not exist anymore (
https://jhighlight.dev.java.net/).
I didn't find any direct usage of it in our code, so I guess it's
probably needed by a 3rd party dependency, such as Tika. Therefore
if we
e.g. omit it, things will compile, but may fail at runtime.
Is it OK that we distribute this .jar?
Shai
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7203) NoHttpResponseException handling in HttpSolrClient is wrong
[ https://issues.apache.org/jira/browse/SOLR-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381682#comment-14381682 ] ASF subversion and git services commented on SOLR-7203: --- Commit 1669313 from [~romseygeek] in branch 'dev/trunk' [ https://svn.apache.org/r1669313 ] SOLR-7203: Remove buggy no-op retries in HttpSolrClient NoHttpResponseException handling in HttpSolrClient is wrong --- Key: SOLR-7203 URL: https://issues.apache.org/jira/browse/SOLR-7203 Project: Solr Issue Type: Bug Reporter: Alan Woodward Assignee: Alan Woodward Attachments: SOLR-7203.patch, SOLR-7203.patch, SOLR-7203.patch We've got logic in HttpSolrClient to catch NoHttpResponseException and retry. However, this logic appears to be in the wrong place - it's in the createMethod function, which doesn't actually execute any http requests at all. It ought to be in executeMethod. Fixing this might help sort out the persistent Jenkins failures as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6709) ClassCastException in QueryResponse after applying XMLResponseParser on a response containing an expanded section
[
https://issues.apache.org/jira/browse/SOLR-6709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker updated SOLR-6709:
Fix Version/s: 5.1
Trunk
ClassCastException in QueryResponse after applying XMLResponseParser on a
response containing an expanded section
---
Key: SOLR-6709
URL: https://issues.apache.org/jira/browse/SOLR-6709
Project: Solr
Issue Type: Bug
Components: SolrJ
Reporter: Simon Endele
Assignee: Varun Thacker
Fix For: Trunk, 5.1
Attachments: SOLR-6709.patch, SOLR-6709.patch, test-response.xml
Shouldn't the following code work on the attached input file?
It matches the structure of a Solr response with wt=xml.
{code}import java.io.InputStream;
import org.apache.solr.client.solrj.ResponseParser;
import org.apache.solr.client.solrj.impl.XMLResponseParser;
import org.apache.solr.client.solrj.response.QueryResponse;
import org.apache.solr.common.util.NamedList;
import org.junit.Test;
public class ParseXmlExpandedTest {
@Test
public void test() {
ResponseParser responseParser = new XMLResponseParser();
InputStream inStream = getClass()
.getResourceAsStream(test-response.xml);
NamedListObject response = responseParser
.processResponse(inStream, UTF-8);
QueryResponse queryResponse = new QueryResponse(response, null);
}
}{code}
Unexpectedly (for me), it throws a
java.lang.ClassCastException: org.apache.solr.common.util.SimpleOrderedMap
cannot be cast to java.util.Map
at
org.apache.solr.client.solrj.response.QueryResponse.setResponse(QueryResponse.java:126)
Am I missing something, is XMLResponseParser deprecated or something?
We use a setup like this to mock a QueryResponse for unit tests in our
service that post-processes the Solr response.
Obviously, it works with the javabin format which SolrJ uses internally.
But that is no appropriate format for unit tests, where the response should
be human readable.
I think there's some conversion missing in QueryResponse or XMLResponseParser.
Note: The null value supplied as SolrServer argument to the constructor of
QueryResponse shouldn't have an effect as the error occurs before the
parameter is even used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-6709) ClassCastException in QueryResponse after applying XMLResponseParser on a response containing an expanded section
[
https://issues.apache.org/jira/browse/SOLR-6709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker reassigned SOLR-6709:
---
Assignee: Varun Thacker
ClassCastException in QueryResponse after applying XMLResponseParser on a
response containing an expanded section
---
Key: SOLR-6709
URL: https://issues.apache.org/jira/browse/SOLR-6709
Project: Solr
Issue Type: Bug
Components: SolrJ
Reporter: Simon Endele
Assignee: Varun Thacker
Fix For: Trunk, 5.1
Attachments: SOLR-6709.patch, SOLR-6709.patch, test-response.xml
Shouldn't the following code work on the attached input file?
It matches the structure of a Solr response with wt=xml.
{code}import java.io.InputStream;
import org.apache.solr.client.solrj.ResponseParser;
import org.apache.solr.client.solrj.impl.XMLResponseParser;
import org.apache.solr.client.solrj.response.QueryResponse;
import org.apache.solr.common.util.NamedList;
import org.junit.Test;
public class ParseXmlExpandedTest {
@Test
public void test() {
ResponseParser responseParser = new XMLResponseParser();
InputStream inStream = getClass()
.getResourceAsStream(test-response.xml);
NamedListObject response = responseParser
.processResponse(inStream, UTF-8);
QueryResponse queryResponse = new QueryResponse(response, null);
}
}{code}
Unexpectedly (for me), it throws a
java.lang.ClassCastException: org.apache.solr.common.util.SimpleOrderedMap
cannot be cast to java.util.Map
at
org.apache.solr.client.solrj.response.QueryResponse.setResponse(QueryResponse.java:126)
Am I missing something, is XMLResponseParser deprecated or something?
We use a setup like this to mock a QueryResponse for unit tests in our
service that post-processes the Solr response.
Obviously, it works with the javabin format which SolrJ uses internally.
But that is no appropriate format for unit tests, where the response should
be human readable.
I think there's some conversion missing in QueryResponse or XMLResponseParser.
Note: The null value supplied as SolrServer argument to the constructor of
QueryResponse shouldn't have an effect as the error occurs before the
parameter is even used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2096 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2096/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.test Error Message: Error from server at http://127.0.0.1:61191/_s/checkStateVerCol: no servers hosting shard: Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:61191/_s/checkStateVerCol: no servers hosting shard: at __randomizedtesting.SeedInfo.seed([C5E7A3466780673:840A45EEC8846B8B]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:584) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:236) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:228) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.stateVersionParamTest(CloudSolrClientTest.java:554) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:127) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Resolved] (SOLR-7203) NoHttpResponseException handling in HttpSolrClient is wrong
[ https://issues.apache.org/jira/browse/SOLR-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved SOLR-7203. - Resolution: Fixed NoHttpResponseException handling in HttpSolrClient is wrong --- Key: SOLR-7203 URL: https://issues.apache.org/jira/browse/SOLR-7203 Project: Solr Issue Type: Bug Reporter: Alan Woodward Assignee: Alan Woodward Attachments: SOLR-7203.patch, SOLR-7203.patch, SOLR-7203.patch We've got logic in HttpSolrClient to catch NoHttpResponseException and retry. However, this logic appears to be in the wrong place - it's in the createMethod function, which doesn't actually execute any http requests at all. It ought to be in executeMethod. Fixing this might help sort out the persistent Jenkins failures as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7203) NoHttpResponseException handling in HttpSolrClient is wrong
[ https://issues.apache.org/jira/browse/SOLR-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated SOLR-7203: Fix Version/s: 5.1 NoHttpResponseException handling in HttpSolrClient is wrong --- Key: SOLR-7203 URL: https://issues.apache.org/jira/browse/SOLR-7203 Project: Solr Issue Type: Bug Reporter: Alan Woodward Assignee: Alan Woodward Fix For: 5.1 Attachments: SOLR-7203.patch, SOLR-7203.patch, SOLR-7203.patch We've got logic in HttpSolrClient to catch NoHttpResponseException and retry. However, this logic appears to be in the wrong place - it's in the createMethod function, which doesn't actually execute any http requests at all. It ought to be in executeMethod. Fixing this might help sort out the persistent Jenkins failures as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2837 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2837/ 4 tests failed. FAILED: org.apache.solr.handler.component.DistributedMLTComponentTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:29409//collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:29409//collection1 at __randomizedtesting.SeedInfo.seed([321BC4118A4F6ACA:BA4FFBCB24B30732]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:566) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:233) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:225) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958) at org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:556) at org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:604) at org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:586) at org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:565) at org.apache.solr.handler.component.DistributedMLTComponentTest.test(DistributedMLTComponentTest.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:958) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:933) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_40) - Build # 4597 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4597/ Java: 64bit/jdk1.8.0_40 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test Error Message: There were too many update fails (30 20) - we expect it can happen, but shouldn't easily Stack Trace: java.lang.AssertionError: There were too many update fails (30 20) - we expect it can happen, but shouldn't easily at __randomizedtesting.SeedInfo.seed([D021BCBB66EB4B4C:58758361C81726B4]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:230) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at
[jira] [Commented] (SOLR-7304) SyntaxError in SpellcheckComponent
[ https://issues.apache.org/jira/browse/SOLR-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381803#comment-14381803 ] Hakim commented on SOLR-7304: - It seems that spellcheck.collate is causing this error, because when I set it to false the error disappeared from log files. SyntaxError in SpellcheckComponent -- Key: SOLR-7304 URL: https://issues.apache.org/jira/browse/SOLR-7304 Project: Solr Issue Type: Bug Components: spellchecker Affects Versions: 4.9 Environment: Jetty Debian Reporter: Hakim Priority: Minor Labels: range, spellchecker Fix For: 4.9 I have an error with SpellCheckComponent since I have added this SearchComponent to /select RequestHandler (see solrconfig.xml). requestHandler name=/select class=solr.SearchHandler !-- default values for query parameters can be specified, these will be overridden by parameters in the request -- lst name=defaults str name=echoParamsexplicit/str int name=rows10/int str name=dftitre/str !-- h4k1m: configure spellcheck if enabled -- str name=spellcheckon/str str name=spellcheck.dictionarydefault/str str name=spellcheck.extendedResultstrue/str str name=spellcheck.count3/str str name=spellcheck.alternativeTermCount3/str str name=spellcheck.maxResultsForSuggest5/str str name=spellcheck.collatetrue/str str name=spellcheck.collateExtendedResultstrue/str str name=spellcheck.maxCollationTries10/str str name=spellcheck.maxCollations1/str str name=spellcheck.onlyMorePopularfalse/str str name=combineWordsfalse/str /lst The error seems to be related to range queries, with the [.. to ..] written in lowercase. The query performed by the SpellCheck component using 'to' in lower case throws the RANGE_GOOP error. 101615 [qtp2145626092-38] WARN org.apache.solr.spelling.SpellCheckCollator - Exception trying to re-query to check if a spell check possibility would return any hits. org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError: Cannot parse 'offredemande:offre AND categorieparente:audi AND prix:[216 to 2250008} AND anneemodele:[2003 to 2008} AND etat:nauf': Encountered RANGE_GOOP 2250008 at line 1, column 68. Was expecting one of: ] ... } ... at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:205) at org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:141) at org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:230) at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:197) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1962) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1645) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:564) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:498) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1045) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:199) at org.eclipse.jetty.server.handler.IPAccessHandler.handle(IPAccessHandler.java:220) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:98) at org.eclipse.jetty.server.Server.handle(Server.java:461) at
[jira] [Comment Edited] (SOLR-6673) MDC based logging of collection, shard etc.
[
https://issues.apache.org/jira/browse/SOLR-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381812#comment-14381812
]
Joel Bernstein edited comment on SOLR-6673 at 3/26/15 12:48 PM:
I did a fresh 5x checkout this morning and ran the cloud-dev/solrcloud-start.sh
script and got the error below when I accessed /solr from the servers. Not sure
if this reflects an error in how solrcloud-start.sh is doing things or a bug in
Solr.
trace=java.lang.NullPointerException
at
org.apache.solr.servlet.SolrDispatchFilter.addMDCValues(SolrDispatchFilter.java:497)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:366)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
,code=500
was (Author: joel.bernstein):
I did a fresh 5x checkout this morning and ran the cloud-dev/solrcloud-start.sh
script and got the error below when I accessed /solr from the servers. Not sure
if this reflects an error in how solrcloud-start.sh is doing things or a bug in
Solr.
{trace=java.lang.NullPointerException
at
org.apache.solr.servlet.SolrDispatchFilter.addMDCValues(SolrDispatchFilter.java:497)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:366)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
[jira] [Created] (PYLUCENE-34) Pylucene and multiprocessing
Jose Lopez Veiga created PYLUCENE-34: Summary: Pylucene and multiprocessing Key: PYLUCENE-34 URL: https://issues.apache.org/jira/browse/PYLUCENE-34 Project: PyLucene Issue Type: Question Environment: pylucene 4.10, java 7, python 2.7.9, jcc 2.21, OS Mac Reporter: Jose Lopez Veiga Priority: Minor I've built a index that will be used for searching in a multiprocessing python program. When I try to search in the index, some queries are ok(first ones), but then the program is blocked in the first seconds of the execution when I use QueryParser.parse or IndexSearcher.search I tried all that I can think off but or the program is blocked or I get errors What is the best way to use multiprocessing and pylucene? Thank you for your help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SOLR-6673) MDC based logging of collection, shard etc.
[
https://issues.apache.org/jira/browse/SOLR-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381828#comment-14381828
]
Varun Thacker commented on SOLR-6673:
-
bq. 34093 T174 C:collection1 S:shard1 R:core_node6 c:collection1 C17 P62757
oasup.LogUpdateProcessor.finish [collection1] webapp=/ar path=/update
params={update.distrib=FROMLEADERdistrib.from=http://127.0.0.1:62746/ar/collection1/wt=javabinversion=2}
{add=[10478 (1496644420418666496), 10479 (1496644420419715072)]} 0 1
Can we be more verbose about it? Call 'C' 'Collection' and 'c' 'core'?
{{981970 T4850 C:collection1 c:collection1 oasc.ZkController.watchZKConfDir
watch zkdir /configs/conf1}}
Lines like this could confuse someone.
Don't have a strong opinion about it though.
MDC based logging of collection, shard etc.
---
Key: SOLR-6673
URL: https://issues.apache.org/jira/browse/SOLR-6673
Project: Solr
Issue Type: Improvement
Reporter: Ishan Chattopadhyaya
Assignee: Noble Paul
Labels: logging
Fix For: Trunk, 5.1
Attachments: SOLR-6673-log-more.patch, SOLR-6673.patch,
SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch,
SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, log4j.properties,
log4j.properties
In cloud mode, the many log items don't contain the collection name, shard
name, core name etc. Debugging becomes specially difficult when many
collections/shards are hosted on the same node.
The proposed solution adds MDC based stamping of collection, shard, core to
the thread.
See also: SOLR-5969, SOLR-5277
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1387) Add more search options for filtering field facets.
[ https://issues.apache.org/jira/browse/SOLR-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381786#comment-14381786 ] ASF subversion and git services commented on SOLR-1387: --- Commit 1669335 from [~romseygeek] in branch 'dev/trunk' [ https://svn.apache.org/r1669335 ] SOLR-1387: Add facet.contains and facet.contains.ignoreCase Add more search options for filtering field facets. --- Key: SOLR-1387 URL: https://issues.apache.org/jira/browse/SOLR-1387 Project: Solr Issue Type: New Feature Components: search Reporter: Anil Khadka Assignee: Alan Woodward Fix For: 4.9, Trunk Attachments: SOLR-1387.patch Currently for filtering the facets, we have to use prefix (which use String.startsWith() in java). We can add some parameters like * facet.iPrefix : this would act like case-insensitive search. (or --- facet.prefix=afacet.caseinsense=on) * facet.regex : this is pure regular expression search (which obviously would be expensive if issued). Moreover, allowing multiple filtering for same field would be great like facet.prefix=a OR facet.prefix=A ... sth like this. All above concepts could be equally applicable to TermsComponent. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7314) Constants missing in Solrj
Simon Endele created SOLR-7314: -- Summary: Constants missing in Solrj Key: SOLR-7314 URL: https://issues.apache.org/jira/browse/SOLR-7314 Project: Solr Issue Type: Wish Components: SolrJ Reporter: Simon Endele There are some parameter names/values, for which constants are missing in SolrJ. One has always to declare constants for them by herself (or hard-code them). * defType * edismax (value for defType) * dismax (value for defType) * lucene (value for defType) * spellcheck (there's SpellingParams.SPELLCHECK_PREFIX = spellcheck., but none without dot) See http://lucene.apache.org/solr/5_0_0/solr-solrj/constant-values.html Maybe there are even more, but these are the ones I always stumble upon. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5944) Support updates of numeric DocValues
[ https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381840#comment-14381840 ] Yonik Seeley commented on SOLR-5944: bq. Is it possible to not deal with reordering if we put a big fat warning on requirements that the indexing program has to follow and work on other problems later? Too hard for us to try and figure out what can result in reordered docs, much less a user. For example, I think maybe even peer-sync could cause trouble here. Support updates of numeric DocValues Key: SOLR-5944 URL: https://issues.apache.org/jira/browse/SOLR-5944 Project: Solr Issue Type: New Feature Reporter: Ishan Chattopadhyaya Assignee: Shalin Shekhar Mangar Attachments: SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch LUCENE-5189 introduced support for updates to numeric docvalues. It would be really nice to have Solr support this. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1387) Add more search options for filtering field facets.
[ https://issues.apache.org/jira/browse/SOLR-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated SOLR-1387: Fix Version/s: (was: 4.9) 5.1 Add more search options for filtering field facets. --- Key: SOLR-1387 URL: https://issues.apache.org/jira/browse/SOLR-1387 Project: Solr Issue Type: New Feature Components: search Reporter: Anil Khadka Assignee: Alan Woodward Fix For: Trunk, 5.1 Attachments: SOLR-1387.patch Currently for filtering the facets, we have to use prefix (which use String.startsWith() in java). We can add some parameters like * facet.iPrefix : this would act like case-insensitive search. (or --- facet.prefix=afacet.caseinsense=on) * facet.regex : this is pure regular expression search (which obviously would be expensive if issued). Moreover, allowing multiple filtering for same field would be great like facet.prefix=a OR facet.prefix=A ... sth like this. All above concepts could be equally applicable to TermsComponent. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6359) Allow customization of the number of records and logs kept by UpdateLog
[
https://issues.apache.org/jira/browse/SOLR-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381798#comment-14381798
]
Forest Soup commented on SOLR-6359:
---
We have a SolrCloud with 5 solr servers of Solr 4.7.0. There are one collection
with 80 shards(2 replicas per shard) on those 5 servers. And we made a patch by
merge the code of this fix to 4.7.0 stream. And after applied the patch to our
servers with the config changing uploaded to ZooKeeper, we did a restart on one
of the 5 solr server, we met some issues on that server. Below is the details
-
The solrconfig.xml we changed:
updateLog
str name=dir$
{solr.ulog.dir:}
/str
int name=numRecordsToKeep1/int
int name=maxNumLogsToKeep100/int
/updateLog
After we restarted one solr server without other 4 servers are running, we met
below exceptions in the restarted one:
ERROR - 2015-03-16 20:48:48.214; org.apache.solr.common.SolrException;
org.apache.solr.common.SolrException: Exception writing document id
Q049bGx0bWFpbDIxL089bGxwX3VzMQ==41703656!B68BF5EC5A4A650D85257E0A00724A3B to
the index; possible analysis error.
at
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
at
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:703)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:857)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:556)
at
org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:96)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:166)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:136)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:225)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:121)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:190)
at
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:116)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:173)
at
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:106)
at
org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:58)
at
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1916)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:780)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:427)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:804)
Caused by:
[jira] [Updated] (SOLR-7314) Constants missing in Solrj
[ https://issues.apache.org/jira/browse/SOLR-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Endele updated SOLR-7314: --- Description: There are some parameter names/values, for which constants are missing in SolrJ. One has always to declare constants for them by herself (or hard-code them). * defType * edismax (value for defType) * dismax (value for defType) * lucene (value for defType) * spellcheck (there's SpellingParams.SPELLCHECK_PREFIX = spellcheck., but none without dot) See http://lucene.apache.org/solr/5_0_0/solr-solrj/constant-values.html Maybe there are even more, but these are the ones I always stumble upon. Of course there are constants in the Solr Core code, but typically one doesn't want to have a dependency on it when implementing a client. was: There are some parameter names/values, for which constants are missing in SolrJ. One has always to declare constants for them by herself (or hard-code them). * defType * edismax (value for defType) * dismax (value for defType) * lucene (value for defType) * spellcheck (there's SpellingParams.SPELLCHECK_PREFIX = spellcheck., but none without dot) See http://lucene.apache.org/solr/5_0_0/solr-solrj/constant-values.html Maybe there are even more, but these are the ones I always stumble upon. Constants missing in Solrj -- Key: SOLR-7314 URL: https://issues.apache.org/jira/browse/SOLR-7314 Project: Solr Issue Type: Wish Components: SolrJ Reporter: Simon Endele There are some parameter names/values, for which constants are missing in SolrJ. One has always to declare constants for them by herself (or hard-code them). * defType * edismax (value for defType) * dismax (value for defType) * lucene (value for defType) * spellcheck (there's SpellingParams.SPELLCHECK_PREFIX = spellcheck., but none without dot) See http://lucene.apache.org/solr/5_0_0/solr-solrj/constant-values.html Maybe there are even more, but these are the ones I always stumble upon. Of course there are constants in the Solr Core code, but typically one doesn't want to have a dependency on it when implementing a client. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6359) Allow customization of the number of records and logs kept by UpdateLog
[
https://issues.apache.org/jira/browse/SOLR-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381799#comment-14381799
]
Forest Soup commented on SOLR-6359:
---
It looks like https://issues.apache.org/jira/browse/SOLR-4605, but I guess it's
not the case...
Allow customization of the number of records and logs kept by UpdateLog
---
Key: SOLR-6359
URL: https://issues.apache.org/jira/browse/SOLR-6359
Project: Solr
Issue Type: Improvement
Reporter: Ramkumar Aiyengar
Assignee: Ramkumar Aiyengar
Priority: Minor
Fix For: Trunk, 5.1
Attachments: SOLR-6359.patch
Currently {{UpdateLog}} hardcodes the number of logs and records it keeps,
and the hardcoded numbers (100 records, 10 logs) can be quite low (esp. the
records) in an heavily indexing setup, leading to full recovery even if Solr
was just stopped and restarted.
These values should be customizable (even if only present as expert options).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1387) Add more search options for filtering field facets.
[ https://issues.apache.org/jira/browse/SOLR-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381805#comment-14381805 ] ASF subversion and git services commented on SOLR-1387: --- Commit 1669336 from [~romseygeek] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1669336 ] SOLR-1387: Add facet.contains and facet.contains.ignoreCase Add more search options for filtering field facets. --- Key: SOLR-1387 URL: https://issues.apache.org/jira/browse/SOLR-1387 Project: Solr Issue Type: New Feature Components: search Reporter: Anil Khadka Assignee: Alan Woodward Fix For: Trunk, 5.1 Attachments: SOLR-1387.patch Currently for filtering the facets, we have to use prefix (which use String.startsWith() in java). We can add some parameters like * facet.iPrefix : this would act like case-insensitive search. (or --- facet.prefix=afacet.caseinsense=on) * facet.regex : this is pure regular expression search (which obviously would be expensive if issued). Moreover, allowing multiple filtering for same field would be great like facet.prefix=a OR facet.prefix=A ... sth like this. All above concepts could be equally applicable to TermsComponent. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6673) MDC based logging of collection, shard etc.
[
https://issues.apache.org/jira/browse/SOLR-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381812#comment-14381812
]
Joel Bernstein commented on SOLR-6673:
--
I did a fresh 5x checkout this morning and ran the cloud-dev/solrcloud-start.sh
script and got the error below when I accessed /solr from the servers. Not sure
if this reflects an error in how solrcloud-start.sh is doing things or a bug in
Solr.
{trace=java.lang.NullPointerException
at
org.apache.solr.servlet.SolrDispatchFilter.addMDCValues(SolrDispatchFilter.java:497)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:366)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
,code=500}
MDC based logging of collection, shard etc.
---
Key: SOLR-6673
URL: https://issues.apache.org/jira/browse/SOLR-6673
Project: Solr
Issue Type: Improvement
Reporter: Ishan Chattopadhyaya
Assignee: Noble Paul
Labels: logging
Fix For: Trunk, 5.1
Attachments: SOLR-6673-log-more.patch, SOLR-6673.patch,
SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch,
SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, log4j.properties,
log4j.properties
In cloud mode, the many log items don't contain the collection name, shard
name, core name etc. Debugging becomes specially difficult when many
collections/shards are hosted on the same node.
The proposed solution adds MDC based stamping of collection, shard, core to
the thread.
See also: SOLR-5969, SOLR-5277
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6673) MDC based logging of collection, shard etc.
[
https://issues.apache.org/jira/browse/SOLR-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381812#comment-14381812
]
Joel Bernstein edited comment on SOLR-6673 at 3/26/15 12:46 PM:
I did a fresh 5x checkout this morning and ran the cloud-dev/solrcloud-start.sh
script and got the error below when I accessed /solr from the servers. Not sure
if this reflects an error in how solrcloud-start.sh is doing things or a bug in
Solr.
{trace=java.lang.NullPointerException
at
org.apache.solr.servlet.SolrDispatchFilter.addMDCValues(SolrDispatchFilter.java:497)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:366)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
,code=500}
was (Author: joel.bernstein):
I did a fresh 5x checkout this morning and ran the cloud-dev/solrcloud-start.sh
script and got the error below when I accessed /solr from the servers. Not sure
if this reflects an error in how solrcloud-start.sh is doing things or a bug in
Solr.
{trace=java.lang.NullPointerException
at
org.apache.solr.servlet.SolrDispatchFilter.addMDCValues(SolrDispatchFilter.java:497)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:366)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
[jira] [Commented] (SOLR-6673) MDC based logging of collection, shard etc.
[ https://issues.apache.org/jira/browse/SOLR-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381847#comment-14381847 ] Yonik Seeley commented on SOLR-6673: bq. Can we be more verbose about it? Call 'C' 'Collection' and 'c' 'core'? If this stuff will be repeated in every log line, I like the fact that it's short, and that should actually enhance readability once you get used to it. There is some other redundant info now though: C17 P62757 That's the core number and the port number. Both where important in the past (along with the thread number) to figuring out chaos monkey test fails. But they don't seem important for production? The port number should be different for diff log files in production, and the collection name we already have. MDC based logging of collection, shard etc. --- Key: SOLR-6673 URL: https://issues.apache.org/jira/browse/SOLR-6673 Project: Solr Issue Type: Improvement Reporter: Ishan Chattopadhyaya Assignee: Noble Paul Labels: logging Fix For: Trunk, 5.1 Attachments: SOLR-6673-log-more.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, log4j.properties, log4j.properties In cloud mode, the many log items don't contain the collection name, shard name, core name etc. Debugging becomes specially difficult when many collections/shards are hosted on the same node. The proposed solution adds MDC based stamping of collection, shard, core to the thread. See also: SOLR-5969, SOLR-5277 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7318) AbstractFullDistribZkTestBase.getRelativeSolrHomePath doesn't work on Windows
Shai Erera created SOLR-7318: Summary: AbstractFullDistribZkTestBase.getRelativeSolrHomePath doesn't work on Windows Key: SOLR-7318 URL: https://issues.apache.org/jira/browse/SOLR-7318 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Shai Erera From here: http://markmail.org/message/662jtoxaztbsl3sp. The problem is that if the working directory and temp directory are on different roots (e.g. C: and D:), relativizing the path cannot happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5911) Cannot store term vector payloads
[ https://issues.apache.org/jira/browse/SOLR-5911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14383218#comment-14383218 ] ASF subversion and git services commented on SOLR-5911: --- Commit 1669494 from [~dsmiley] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1669494 ] SOLR-5911: term vector payload support in schema TermVectorComponent LukeRequestHandler Cannot store term vector payloads - Key: SOLR-5911 URL: https://issues.apache.org/jira/browse/SOLR-5911 Project: Solr Issue Type: Improvement Reporter: Michael McCandless Fix For: 4.9, Trunk Attachments: SOLR-5911.patch, SOLR-5911.patch Lucene's term vectors can now store payloads, but it looks like this was never exposed in Solr. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2841 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2841/ 3 tests failed. FAILED: org.apache.solr.cloud.LeaderInitiatedRecoveryOnCommitTest.test Error Message: IOException occured when talking to server at: http://127.0.0.1:27158/c8n_1x3_commits_shard1_replica1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:27158/c8n_1x3_commits_shard1_replica1 at __randomizedtesting.SeedInfo.seed([F7A90672CD0B846F:7FFD39A863F7E997]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:570) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:233) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:225) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:483) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:464) at org.apache.solr.cloud.LeaderInitiatedRecoveryOnCommitTest.oneShardTest(LeaderInitiatedRecoveryOnCommitTest.java:130) at org.apache.solr.cloud.LeaderInitiatedRecoveryOnCommitTest.test(LeaderInitiatedRecoveryOnCommitTest.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:958) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:933) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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
[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_40) - Build # 4483 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4483/ Java: 64bit/jdk1.8.0_40 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestSolrConfigHandler Error Message: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010\collection1\conf\params.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010\collection1\conf\params.json: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010\collection1\conf\params.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010\collection1\conf\params.json: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 68EEC1195B859E89-001: java.nio.file.DirectoryNotEmptyException:
[jira] [Resolved] (SOLR-5911) Cannot store term vector payloads
[ https://issues.apache.org/jira/browse/SOLR-5911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-5911. Resolution: Fixed Fix Version/s: (was: 4.9) 5.1 Assignee: David Smiley One additional slight change in the committed version is a comment to document termPayloads in the techproducts schema.xml (a kitchen sink schema) because it acts as documentation for the various options. Cannot store term vector payloads - Key: SOLR-5911 URL: https://issues.apache.org/jira/browse/SOLR-5911 Project: Solr Issue Type: Improvement Reporter: Michael McCandless Assignee: David Smiley Fix For: Trunk, 5.1 Attachments: SOLR-5911.patch, SOLR-5911.patch Lucene's term vectors can now store payloads, but it looks like this was never exposed in Solr. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14383278#comment-14383278 ] Noble Paul commented on SOLR-7312: -- We are not saying the GET for write is good. But conforming to pure REST is much more . We need to make things more secure REST API is not REST -- Key: SOLR-7312 URL: https://issues.apache.org/jira/browse/SOLR-7312 Project: Solr Issue Type: Improvement Components: Server Affects Versions: 5.0 Reporter: Mark Haase Assignee: Noble Paul The documentation refers to a REST API over and over, and yet I don't see a REST API. I see an HTTP API but not a REST API. Here are a few things the HTTP API does that are not RESTful: * Offers RPC verbs instead of resources/nouns. (E.g. schema API has commands like add-field, add-copy-field, etc.) * Tunnels non-idempotent requests (like creating a core) through idempotent HTTP verb (GET). * Tunnels deletes through HTTP GET. * PUT/POST confusion, POST used to update a named resource, such as the Blob API. * Returns `200 OK` HTTP code even when the command fails. (Try adding a field to your schema that already exists. You get `200 OK` and an error message hidden in the payload. Try calling a collections API when you're using non-cloud mode: `200 OK` and an error message in the payload. Gah.) * Does not provide link relations. * HTTP status line contains a JSON payload (!) and no 'Content-Type' header for some failed commands, like `curl -X DELETE http://solr:8983/solr/admin/cores/foo` * Content negotiation is done via query parameter (`wt=json`), instead of `Accept` header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_40) - Build # 4600 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4600/ Java: 64bit/jdk1.8.0_40 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestSolrConfigHandler Error Message: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010\collection1\conf\params.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010\collection1\conf\params.json: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010\collection1\conf\params.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010\collection1\conf\params.json: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrConfigHandler 150EE786079F0B0C-001: java.nio.file.DirectoryNotEmptyException:
Re: jhighlight-1.0 contains LGPL-only files
Yes, I've been monitoring that issue. So once TIKA-1581 is resolved we can
upgrade to the newer Tika version together with the proper jhighlight
package. If that happens before 5.1 is out, all the better.
Shai
On Fri, Mar 27, 2015 at 2:32 AM, Karl Wright daddy...@gmail.com wrote:
The jhighlight people just released a 1.0.2 jar which fixes the problem.
It has a different path in Maven, but otherwise it is compatible. See:
https://github.com/codelibs/jhighlight/issues/4
Karl
On Thu, Mar 26, 2015 at 3:09 PM, Shai Erera ser...@gmail.com wrote:
OK I opened SOLR-7317.
Shai
On Thu, Mar 26, 2015 at 8:58 PM, Upayavira u...@odoko.co.uk wrote:
We should remove it. It would not be a good thing to knowingly release
incompatible code. Then, upgrade to the latest Tika when we can.
Upayavira
On Thu, Mar 26, 2015, at 04:41 PM, Steve Rowe wrote:
+1 to remove.
On Mar 26, 2015, at 4:43 AM, Shai Erera ser...@gmail.com wrote:
Looks like 5.1 release process will start soon - should we remove
this .jar before the release? I see there's some progress on TIKA-1581, but
it doesn't look like it's going to be resolved that soon.
Shai
On Fri, Mar 20, 2015 at 2:59 PM, Karl Wright daddy...@gmail.com
wrote:
I suspect that the classes in question are in fact *not* used by
Tika in any capacity, but they are in the jar nonetheless. So one solution
would be to simply repackage the jar. I'd like to see what the Tika team
says.
Karl
On Fri, Mar 20, 2015 at 7:47 AM, Shai Erera ser...@gmail.com
wrote:
although it might be easier to work with Tika to fix that and then
upgrade again.
If jhighlight was brought into Solr distribution as a transitive
dependency then you're right, but since we pull it in explicitly (even if
for runtime purposes only), I think we should remove it, whether Tika
corrects the problem or not. We can put a note in our NOTICE file for users
to download the jar themselves until Tika fixes the problem.
If people agree, I will remove it from our code.
Shai
On Fri, Mar 20, 2015 at 10:40 AM, Karl Wright daddy...@gmail.com
wrote:
I have created a ticket: TIKA-1581. ManifoldCF also has a Tika
dependency, so thank you for noting the problem.
Karl
On Fri, Mar 20, 2015 at 4:03 AM, Upayavira u...@odoko.co.uk wrote:
You are right -both projects need to remove it, although it might be
easier to work with Tika to fix that and then upgrade again.
Upayavira
On Fri, Mar 20, 2015, at 05:26 AM, Shai Erera wrote:
Sorry for the spam, just wanted to note that this dependency was
added by
Steve in SOLR-6130 to resolve improper Tika 1.4-1.5 upgrade.
The core issue lies with Tika IMO (they shouldn't rely on LGPL
code too I
believe), but I am not sure if it's OK that we distribute this .jar
ourselves.
Shai
On Fri, Mar 20, 2015 at 7:17 AM, Shai Erera ser...@gmail.com
wrote:
One update, I did find this dependency is explicitly set in
solr/contrib/extraction/ivy.xml, under the Tika dependencies
section:
!-- Tika dependencies - see
http://tika.apache.org/1.3/gettingstarted.html#Using_Tika_as_a_Maven_dependency
--
!-- When upgrading Tika, upgrade dependencies versions and
add any
new ones
(except slf4j-api, commons-codec, commons-logging,
commons-httpclient, geronimo-stax-api_1.0_spec,
jcip-annotations, xml-apis,
asm)
WARNING: Don't add netcdf / unidataCommon (partially
LGPL code)
--
...
dependency org=com.uwyn name=jhighlight
rev=${/com.uwyn/jhighlight} conf=compile/
So it does seem like needed by Tika only and I guess it's a
runtime
dependency, so if we don't want to release this LGPL library, we
can omit
it and put a section in the NOTICE file?
Shai
On Fri, Mar 20, 2015 at 7:11 AM, Shai Erera ser...@gmail.com
wrote:
Hi
Solr's contrib/extraction contains jhighlight-1.0.jar which
declares
itself as dual CDDL or LGPL license. However, some of its
classes are
distributed only under LGPL, e.g.
com.uwyn.jhighlight.highlighter.
CppHighlighter.java
GroovyHighlighter.java
JavaHighlighter.java
XmlHighlighter.java
I downloaded the sources from Maven (
http://search.maven.org/remotecontent?filepath=com/uwyn/jhighlight/1.0/jhighlight-1.0-sources.jar
)
to confirm that, and also found this SVN repo:
http://svn.rifers.org/jhighlight/tags/release-1.0, though the
project's
website seems to not exist anymore (
https://jhighlight.dev.java.net/).
I didn't find any direct usage of it in our code, so I guess
it's
probably needed by a 3rd party dependency, such as Tika.
Therefore if we
e.g. omit it, things will compile, but may fail at runtime.
Is it OK that we distribute this .jar?
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b54) - Build # 11941 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11941/
Java: 32bit/jdk1.9.0-ea-b54 -server -XX:+UseG1GC
1 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 3 ms!
ClusterState: { collection1:{ replicationFactor:1, shards:{
shard1:{ range:8000-, state:active,
replicas:{core_node2:{ core:collection1,
base_url:http://127.0.0.1:59274;,
node_name:127.0.0.1:59274_, state:active,
leader:true}}}, shard2:{ range:0-7fff,
state:active, replicas:{ core_node1:{
core:collection1, base_url:http://127.0.0.1:54360;,
node_name:127.0.0.1:54360_, state:active,
leader:true}, core_node3:{ core:collection1,
base_url:http://127.0.0.1:35891;,
node_name:127.0.0.1:35891_, state:active,
router:{name:compositeId}, maxShardsPerNode:1,
autoAddReplicas:false, autoCreated:true}, control_collection:{
replicationFactor:1, shards:{shard1:{
range:8000-7fff, state:active,
replicas:{core_node1:{ core:collection1,
base_url:http://127.0.0.1:50655;,
node_name:127.0.0.1:50655_, state:active,
leader:true, router:{name:compositeId},
maxShardsPerNode:1, autoAddReplicas:false,
autoCreated:true}, c8n_1x2:{ replicationFactor:2,
shards:{shard1:{ range:8000-7fff,
state:active, replicas:{ core_node1:{
core:c8n_1x2_shard1_replica2,
base_url:http://127.0.0.1:35891;,
node_name:127.0.0.1:35891_, state:active,
leader:true}, core_node2:{
core:c8n_1x2_shard1_replica1,
base_url:http://127.0.0.1:59274;,
node_name:127.0.0.1:59274_, state:recovering,
router:{name:compositeId}, maxShardsPerNode:1,
autoAddReplicas:false}}
Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in c8n_1x2
come up within 3 ms! ClusterState: {
collection1:{
replicationFactor:1,
shards:{
shard1:{
range:8000-,
state:active,
replicas:{core_node2:{
core:collection1,
base_url:http://127.0.0.1:59274;,
node_name:127.0.0.1:59274_,
state:active,
leader:true}}},
shard2:{
range:0-7fff,
state:active,
replicas:{
core_node1:{
core:collection1,
base_url:http://127.0.0.1:54360;,
node_name:127.0.0.1:54360_,
state:active,
leader:true},
core_node3:{
core:collection1,
base_url:http://127.0.0.1:35891;,
node_name:127.0.0.1:35891_,
state:active,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false,
autoCreated:true},
control_collection:{
replicationFactor:1,
shards:{shard1:{
range:8000-7fff,
state:active,
replicas:{core_node1:{
core:collection1,
base_url:http://127.0.0.1:50655;,
node_name:127.0.0.1:50655_,
state:active,
leader:true,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false,
autoCreated:true},
c8n_1x2:{
replicationFactor:2,
shards:{shard1:{
range:8000-7fff,
state:active,
replicas:{
core_node1:{
core:c8n_1x2_shard1_replica2,
base_url:http://127.0.0.1:35891;,
node_name:127.0.0.1:35891_,
state:active,
leader:true},
core_node2:{
core:c8n_1x2_shard1_replica1,
base_url:http://127.0.0.1:59274;,
node_name:127.0.0.1:59274_,
state:recovering,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false}}
at
__randomizedtesting.SeedInfo.seed([BE0146527267B078:36557988DC9BDD80]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.ensureAllReplicasAreActive(AbstractFullDistribZkTestBase.java:1995)
at
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:238)
at
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b06) - Build # 12108 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12108/
Java: 64bit/jdk1.8.0_60-ea-b06 -XX:-UseCompressedOops -XX:+UseParallelGC
1 tests failed.
FAILED: org.apache.solr.core.TestDynamicLoading.testDynamicLoading
Error Message:
Could not get expected value 'X val changed' for path 'x' full output: {
responseHeader:{ status:0, QTime:0}, params:{wt:json},
context:{ webapp:/qw_/s, path:/test1,
httpMethod:GET},
class:org.apache.solr.core.BlobStoreTestRequestHandler, x:X val}
Stack Trace:
java.lang.AssertionError: Could not get expected value 'X val changed' for
path 'x' full output: {
responseHeader:{
status:0,
QTime:0},
params:{wt:json},
context:{
webapp:/qw_/s,
path:/test1,
httpMethod:GET},
class:org.apache.solr.core.BlobStoreTestRequestHandler,
x:X val}
at
__randomizedtesting.SeedInfo.seed([99BE1BA5C3FB5C5C:41F336F23426F9FC]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:415)
at
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:260)
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:497)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
[jira] [Created] (LUCENE-6372) hashCode/equals for SpanPositionCheckQuery and subclasses
Paul Elschot created LUCENE-6372: Summary: hashCode/equals for SpanPositionCheckQuery and subclasses Key: LUCENE-6372 URL: https://issues.apache.org/jira/browse/LUCENE-6372 Project: Lucene - Core Issue Type: Improvement Reporter: Paul Elschot Spin off from LUCENE-6308, see the comments there from around 23 March 2015. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7226) Make /query/* jmx/* , requestDispatcher/*, listener initParams properties in solrconfig.xml editable
[ https://issues.apache.org/jira/browse/SOLR-7226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382173#comment-14382173 ] ASF subversion and git services commented on SOLR-7226: --- Commit 1669368 from [~noble.paul] in branch 'dev/trunk' [ https://svn.apache.org/r1669368 ] SOLR-7226: Make /query/* jmx/* , requestDispatcher/*, listener initParams properties in solrconfig.xml editable Make /query/* jmx/* , requestDispatcher/*, listener initParams properties in solrconfig.xml editable Key: SOLR-7226 URL: https://issues.apache.org/jira/browse/SOLR-7226 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul The list of properties are query/useFilterForSortedQuery query/queryResultWindowSize query/queryResultMaxDocsCached query/enableLazyFieldLoading query/boolTofilterOptimizer query/maxBooleanClauses -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6370) UninvertingReader cannot be used with ControlledRealTimeReopenThread
[
https://issues.apache.org/jira/browse/LUCENE-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382195#comment-14382195
]
Dave Borowitz commented on LUCENE-6370:
---
I think we might be ok on refcounts? Here's my thinking.
SearcherManager.refreshIfNeeded calls DirectoryReader.openIfChanged on the
result of referenceToRefresh.getIndexReader(). But I think that particular
IndexReader is always the UninvertingReader, or more precisely, the result of
getSearcher(searcherFactory, reader).getIndexReader(). I don't think we ever
touch the refcount of the original reader. (Except in the failure case from
getSearcher--should that be changed to wrapped.decRef() perhaps?)
UninvertingReader cannot be used with ControlledRealTimeReopenThread
Key: LUCENE-6370
URL: https://issues.apache.org/jira/browse/LUCENE-6370
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 5.0
Reporter: Dave Borowitz
Attachments: LUCENE-6370.patch
In order to sort over non-DocValues fields in 5.0 we need to use an
UninvertingReader to get the old FieldCache behavior back. However,
UninvertingReader cannot be (easily) used with a
ControlledRealTimeReopenThread.
Specifically, the easiest way to construct a ControlledRealTimeReopenThread
is with a SearcherManager. The only way I found to wire an UninvertingReader
into SearcherManager is to implement a SearcherFactory that wraps the
passed-in reader. Unfortunately, that runs afoul of the check in
SearcherManager.getSearcher that requires SearcherFactory must wrap exactly
the provided reader. So, as long as this check is there, I simply don't see
a way to use UninvertingReader with NRT functionality.
I think this is a serious issue for programs that need to be able to use NRT
search features on indexes created with previous Lucene versions, for whom
upgrading the index is not an easy option. If they were previously relying on
sorting implicitly via FieldCache, the _only_ ways to upgrade are:
a) rebuild the index using DocValues fields, or
b) use UninvertingReader
Right now there's a catch-22, as (a) is assumed to be not an option and (b)
is broken due to this bug.
I have a hacky workaround for Gerrit Code Review up for review here:
https://gerrit-review.googlesource.com/#/c/66613/6/gerrit-lucene/src/main/java/com/google/gerrit/lucene/WrappableSearcherManager.java@191
Basically, it loosens the restriction on the newSearcher result to allow
Filtered{Directory,Leaf}Readers that wrap the original reader. This appears
to work fine for us, and I don't see anything in UninvertingReader that would
cause me to believe it doesn't work. However, I'm no expert on Lucene
internals and I don't know why that identity check was there in the first
place, so I may be missing something.
Please do not take that patch directly until I have gotten permission from my
employer to contribute it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_60-ea-b06) - Build # 11934 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11934/ Java: 32bit/jdk1.8.0_60-ea-b06 -server -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.update.AutoCommitTest.testMaxTime Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([37A3D4B7AF676434:AD57A95531FDF808]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:794) at org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:237) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeaderint name=status0/intint name=QTime1/int/lstresult name=response numFound=0 start=0/result /response request was:q=id:529qt=standardstart=0rows=20version=2.2 at
[jira] [Updated] (PYLUCENE-34) Pylucene and multiprocessing
[ https://issues.apache.org/jira/browse/PYLUCENE-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jose Lopez Veiga updated PYLUCENE-34: - Description: I've built a index that will be used for searching in a multiprocessing python program. When I try to search in the index, some queries are ok(first ones), but then the program is blocked in the first seconds of the execution when I use QueryParser.parse or IndexSearcher.search I tried all that I can think off but or the program is blocked or I get errors What is the best way to use multiprocessing and pylucene? I can't find a example or tutorial about this. Thank you for your help. EDIT: I found that the block happend when I import nltk, only in multriprocessing. is this a reported bug? was: I've built a index that will be used for searching in a multiprocessing python program. When I try to search in the index, some queries are ok(first ones), but then the program is blocked in the first seconds of the execution when I use QueryParser.parse or IndexSearcher.search I tried all that I can think off but or the program is blocked or I get errors What is the best way to use multiprocessing and pylucene? I can't find a example or tutorial about this. Thank you for your help. EDIT: I found that the block happend when I import nltk, only in multriprocessing. This is a reported bug? Pylucene and multiprocessing Key: PYLUCENE-34 URL: https://issues.apache.org/jira/browse/PYLUCENE-34 Project: PyLucene Issue Type: Bug Environment: pylucene 4.10, java 7, python 2.7.9, jcc 2.21, OS Mac Reporter: Jose Lopez Veiga Priority: Minor I've built a index that will be used for searching in a multiprocessing python program. When I try to search in the index, some queries are ok(first ones), but then the program is blocked in the first seconds of the execution when I use QueryParser.parse or IndexSearcher.search I tried all that I can think off but or the program is blocked or I get errors What is the best way to use multiprocessing and pylucene? I can't find a example or tutorial about this. Thank you for your help. EDIT: I found that the block happend when I import nltk, only in multriprocessing. is this a reported bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LUCENE-6308) SpansEnum, deprecate Spans
[ https://issues.apache.org/jira/browse/LUCENE-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382229#comment-14382229 ] Paul Elschot commented on LUCENE-6308: -- I created some spinoff issues from this to allow easier progress here: LUCENE-6371, LUCENE-6372 and LUCENE-6373. That leaves Spans.cost(), the minimum number of subqueries for SpanNear, and NO_MORE_POSITIONS to be resolved here, SpansEnum, deprecate Spans -- Key: LUCENE-6308 URL: https://issues.apache.org/jira/browse/LUCENE-6308 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: Trunk Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-6308-changeapi.patch, LUCENE-6308-changeapi.patch, LUCENE-6308-changeapi.patch, LUCENE-6308-changeapi.patch, LUCENE-6308.patch, LUCENE-6308.patch, LUCENE-6308.patch, LUCENE-6308.patch, LUCENE-6308.patch, LUCENE-6308.patch An alternative for Spans that looks more like PositionsEnum and adds two phase doc id iteration -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382264#comment-14382264 ] Mark Haase commented on SOLR-7312: -- Hey Paul, I support the idea of changing the docs. `s/REST API/HTTP API/g` would be a fine start. I don't want to start an argument about what REST means and whether Solr should have a RESTful interface, but most of your reasons for not having it aren't great reasons. It's not a standard. Think of REST as a set of properties for API design (in the abstract, not necessarily just APIs implemented on HTTP). Of course, like any word that doesn't have standardized meaning, REST also means differnet things to different people. Solr isn't the first project to misuse the word by any means. (Many people seem to think REST API is synonymous with HTTP API, but it's not. If it was, that would imply that SOAP-over-HTTP == REST, which is false.) * You can certainly have bulk commands, except that command isn't the right word in a resourceful API. You could post an array of schema fields to the schema collection, and that would be a RESTful way to add multiple fields in a single transaction. * You can also have RESTful transactions. Instead of thinking of transactions as verbs with statefulness (START TRANSACTIONCOMMIT), think of the transaction as a resource itself. * I don't understand the comment about different payload for unix, windows, web interface. Do you mean the request body? Why would that change on different platforms? How does RPC payloads differently than REST? * I also don't know what you mean about interlacing shell commands. That's completely orthogonal to REST vs RPC... Again, I'm not saying Solr should do this. I realize that Solr/Lucene is a huge project with finite resources and this probably isn't a high priority, otherwise I wouldn't be the first to report it. I just want to correct the misperception that REST isn't practical from an ops point of view. For example, Microsoft Azure has a RESTful API for managing infrastructure: https://msdn.microsoft.com/en-us/library/azure/jj157206.aspx. REST API is not REST -- Key: SOLR-7312 URL: https://issues.apache.org/jira/browse/SOLR-7312 Project: Solr Issue Type: Improvement Components: Server Affects Versions: 5.0 Reporter: Mark Haase Assignee: Noble Paul The documentation refers to a REST API over and over, and yet I don't see a REST API. I see an HTTP API but not a REST API. Here are a few things the HTTP API does that are not RESTful: * Offers RPC verbs instead of resources/nouns. (E.g. schema API has commands like add-field, add-copy-field, etc.) * Tunnels non-idempotent requests (like creating a core) through idempotent HTTP verb (GET). * Tunnels deletes through HTTP GET. * PUT/POST confusion, POST used to update a named resource, such as the Blob API. * Returns `200 OK` HTTP code even when the command fails. (Try adding a field to your schema that already exists. You get `200 OK` and an error message hidden in the payload. Try calling a collections API when you're using non-cloud mode: `200 OK` and an error message in the payload. Gah.) * Does not provide link relations. * HTTP status line contains a JSON payload (!) and no 'Content-Type' header for some failed commands, like `curl -X DELETE http://solr:8983/solr/admin/cores/foo` * Content negotiation is done via query parameter (`wt=json`), instead of `Accept` header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7316) API to create a core is broken
Mark Haase created SOLR-7316:
Summary: API to create a core is broken
Key: SOLR-7316
URL: https://issues.apache.org/jira/browse/SOLR-7316
Project: Solr
Issue Type: Bug
Components: Server
Affects Versions: 5.0
Reporter: Mark Haase
Steps to reproduce:
1. curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
Expected result:
Create a core called new_core
Actual result:
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
My response:
{quote}
From an API consumer's point of view, I'm not really interested in being
forced to learn the history of the project to use the API. *The whole point of
creating APIs is to abstract out details that the caller doesn't need to know,
and yet this API requires an understanding of Solr's internal file structure
and history of the project?*
{quote}
(Emphasis added.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6816) Review SolrCloud Indexing Performance.
[
https://issues.apache.org/jira/browse/SOLR-6816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382306#comment-14382306
]
Timothy Potter commented on SOLR-6816:
--
bq. Can you tell what part is taking so much time?
If you already knew the answer, why did you ask? ;-) your assumption was
correct -- it spends most of the time is spent doing {{long lookup =
searcher.lookupId(idBytes);}} ... this is explains why docValues for version
didn't help because the doc doesn't exist so we never get to the ValueSource
code where the docValues would help ;-)
bq. If we could initialize the highest versions correctly (would need to get
from the index) ...
Can you expand on this a bit? I'm not clear how we would get the latest version
of the bucket from the index?
Review SolrCloud Indexing Performance.
--
Key: SOLR-6816
URL: https://issues.apache.org/jira/browse/SOLR-6816
Project: Solr
Issue Type: Task
Components: SolrCloud
Reporter: Mark Miller
Priority: Critical
Attachments: SolrBench.pdf
We have never really focused on indexing performance, just correctness and
low hanging fruit. We need to vet the performance and try to address any
holes.
Note: A common report is that adding any replication is very slow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Created] (PYLUCENE-34) Pylucene and multiprocessing
On Thu, 26 Mar 2015, Jose Lopez Veiga (JIRA) wrote: I've built a index that will be used for searching in a multiprocessing python program. When I try to search in the index, some queries are ok(first ones), but then the program is blocked in the first seconds of the execution when I use QueryParser.parse or IndexSearcher.search I tried all that I can think off but or the program is blocked or I get errors Without telling us what you tried or what the actual errors are, there is very little I can do to help. Andi.. What is the best way to use multiprocessing and pylucene? Thank you for your help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PYLUCENE-34) Pylucene and multiprocessing
[ https://issues.apache.org/jira/browse/PYLUCENE-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andi Vajda resolved PYLUCENE-34. Resolution: Cannot Reproduce Please use the pylucene-dev@lucene.apache.org mailing list to ask usage questions. Send mail to pylucene-dev-subscr...@lucene.apache.org and follow the instructions in the response. Pylucene and multiprocessing Key: PYLUCENE-34 URL: https://issues.apache.org/jira/browse/PYLUCENE-34 Project: PyLucene Issue Type: Bug Environment: pylucene 4.10, java 7, python 2.7.9, jcc 2.21, OS Mac Reporter: Jose Lopez Veiga Priority: Minor I've built a index that will be used for searching in a multiprocessing python program. When I try to search in the index, some queries are ok(first ones), but then the program is blocked in the first seconds of the execution when I use QueryParser.parse or IndexSearcher.search I tried all that I can think off but or the program is blocked or I get errors What is the best way to use multiprocessing and pylucene? I can't find a example or tutorial about this. Thank you for your help. EDIT: I found that the block happend when I import nltk, only in multriprocessing. is this a reported bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: How can I create my own TokenFilter in PyLucene inherited from PythonTokenFilter
On Wed, 25 Mar 2015, ?? wrote: everyone: I'm developing my own Analyzer in PyLucene 4.9.0 and created a TokenFilter for CompoundTokenFilter for compound word splitting in the analyzer as the DictionaryCompoundWordTokenFilter not performing very well. DictionaryCompoundWordTokenFilter uses a brute algorithm, but I'd like to split compound words only when the subwords in the compound word are all in the dictionary, like breastcancer is split when breast and cancer are both in the given dictionary. Actually the whole code is based on CompoundWordTokenFilterBase and I just edited the docompose() method in DictionaryCompoundWordTokenFilter class. But when running the program, it show that the attribute 'length' of 'CharTermAttribute' objects is not readable, and I cannot find what's wrong with it. And I've searched for how to inherit java classes in pylucene with jcc, but cannot work it out, could someone share some experiences or give some help? Thanks! from __future__ import division import lucene, math, itertools from java.lang importCharSequencefrom java.io importIOExceptionfrom java.util importLinkedListfrom org.apache.pylucene.analysis importPythonTokenStreamfrom org.apache.lucene.analysis importTokenFilterfrom org.apache.pylucene.analysis importPythonTokenFilterfrom org.apache.lucene.analysis importTokenStreamfrom org.apache.lucene.analysis.tokenattributes importCharTermAttributefrom org.apache.lucene.analysis.tokenattributes importOffsetAttributefrom org.apache.lucene.analysis.tokenattributes importPositionIncrementAttributefrom org.apache.lucene.analysis.util importCharArraySetfrom org.apache.lucene.util importAttributeSourcefrom org.apache.lucene.util importVersionclassCompoundTokenFilter(PythonTokenFilter):def __init__(self,matchVersion,input,dictionary,DEFAULT_MIN_WORD_SIZE,DEFAULT_MIN_SUBWORD_SIZE,DEFAULT_MAX_SUBWORD_SIZE):super(CompoundTokenFilter,self).__init__(input)self.matchVersion=matchVersion self.dictionary=dictionary self.tokens=LinkedList()self.minWordSize=DEFAULT_MIN_WORD_SIZE self.minSubwordSize=DEFAULT_MIN_SUBWORD_SIZE self.maxSubwordSize=DEFAULT_MAX_SUBWORD_SIZE self.current=AttributeSource.Stateself.termAtt=input.addAttribute(CharTermAttribute.class_)self.offsetAtt=input.addAttribute(OffsetAttribute.class_)self.posIncAtt=input.addAttribute(PositionIncrementAttribute.class_)self.input=input def decompose(self): l=self.termAtt.length() s=self.termAtt.subSequence(0,l)if s inself.dictionary:self.tokens.add(CompoundToken(self.matchVersion,self.input,self.dictionary,self.minWordSize,self.minSubwordSize,self.maxSubwordSize,0,l))else: d=filter(lambda x:len(x)=self.minSubwordSize and len(x)=self.maxSubwordSize in s,this.dictionary)if len(d)0: start=int(math.floor(l/self.maxSubwordSize))end=int(math.ceil(l/self.minSubwordSize)) subwords_combinations=[]for i in xrange(start,end+1): subwords_combinations.extend(itertools.permutations(d,i)) subwords_combinations=filter(lambda x:''.join(x)==s,subwords_combinations) subwords=sorted(set(reduce(lambda x,y:x+y,subwords_combinations)),key=lambda x:-1*len(x))for subword in subwords: tokens.add(CompoundToken(self.matchVersion,self.input,self.dictionary,self.minWordSize,self.minSubwordSize,self.maxSubwordSize,s.find(subword),s.find(subword)+len(subword)))def incrementToken(self):if(notself.tokens.isEmpty()):assertself.current!=None token=self.tokens.removeFirst()AttributeSource.restoreState(self.current)self.termAtt.setEmpty().append(token.txt)self.offsetAttribute.setOffset(token.startOffset, token.endOffset)self.posIncAtt.setPositionIncrement(0)returnTrueself.current=Noneif(self.input.incrementToken()):ifself.termAtt.length()=self.minWordSize: decompose()ifnot tokens.isEmpty():self.current=AttributeSource.captureState()returnTrueelse:returnFalsedef reset(self):super(CompoundTokenFilter,self).reset()self.tokens.clear()self.current=NoneclassCompoundToken:def __init__(self,matchVersion,input,dictionary,DEFAULT_MIN_WORD_SIZE,DEFAULT_MIN_SUBWORD_SIZE,DEFAULT_MAX_SUBWORD_SIZE,offset,length): compoundTokenFilter=CompoundTokenFilter(matchVersion,input,dictionary,DEFAULT_MIN_WORD_SIZE,DEFAULT_MIN_SUBWORD_SIZE,DEFAULT_MAX_SUBWORD_SIZE)self.txt=compoundTokenFilter.termAtt.subSequence(offset, offset + length) startOff = compoundWordTokenFilterBase.this.offsetAtt.startOffset() endOff = compoundWordTokenFilterBase.this.offsetAtt.endOffset()if matchVersion.onOrAfter(Version.LUCENE_4_4)or endOff - startOff != compoundTokenFilter.termAtt.length():self.startOffset = startOff self.endOffset = endOff else: newStart = startOff + offset self.startOffset = newStart self.endOffset = newStart + length I don't know enough about the particular
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b54) - Build # 12100 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12100/ Java: 64bit/jdk1.9.0-ea-b54 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test Error Message: org.apache.solr.common.SolrException: Not enough nodes to handle the request Stack Trace: org.apache.solr.client.solrj.SolrServerException: org.apache.solr.common.SolrException: Not enough nodes to handle the request at __randomizedtesting.SeedInfo.seed([10C6AA06BB9E5418:989295DC156239E0]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:929) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:782) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:485) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:464) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1568) at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:218) 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:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54)
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 798 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/798/ 3 tests failed. FAILED: org.apache.solr.cloud.LeaderInitiatedRecoveryOnCommitTest.test Error Message: IOException occured when talking to server at: http://127.0.0.1:51483/c8n_1x3_commits_shard1_replica2 Stack Trace: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:51483/c8n_1x3_commits_shard1_replica2 at __randomizedtesting.SeedInfo.seed([806EDD83CDD8EC98:83AE25963248160]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:570) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:233) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:225) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:483) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:464) at org.apache.solr.cloud.LeaderInitiatedRecoveryOnCommitTest.oneShardTest(LeaderInitiatedRecoveryOnCommitTest.java:130) at org.apache.solr.cloud.LeaderInitiatedRecoveryOnCommitTest.test(LeaderInitiatedRecoveryOnCommitTest.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:958) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:933) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Updated] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-7312: - Issue Type: Wish (was: Bug) REST API is not REST -- Key: SOLR-7312 URL: https://issues.apache.org/jira/browse/SOLR-7312 Project: Solr Issue Type: Wish Components: Server Affects Versions: 5.0 Reporter: Mark Haase Assignee: Noble Paul The documentation refers to a REST API over and over, and yet I don't see a REST API. I see an HTTP API but not a REST API. Here are a few things the HTTP API does that are not RESTful: * Offers RPC verbs instead of resources/nouns. (E.g. schema API has commands like add-field, add-copy-field, etc.) * Tunnels non-idempotent requests (like creating a core) through idempotent HTTP verb (GET). * Tunnels deletes through HTTP GET. * PUT/POST confusion, POST used to update a named resource, such as the Blob API. * Returns `200 OK` HTTP code even when the command fails. (Try adding a field to your schema that already exists. You get `200 OK` and an error message hidden in the payload. Try calling a collections API when you're using non-cloud mode: `200 OK` and an error message in the payload. Gah.) * Does not provide link relations. * HTTP status line contains a JSON payload (!) and no 'Content-Type' header for some failed commands, like `curl -X DELETE http://solr:8983/solr/admin/cores/foo` * Content negotiation is done via query parameter (`wt=json`), instead of `Accept` header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-7312: - Issue Type: Improvement (was: Wish) REST API is not REST -- Key: SOLR-7312 URL: https://issues.apache.org/jira/browse/SOLR-7312 Project: Solr Issue Type: Improvement Components: Server Affects Versions: 5.0 Reporter: Mark Haase Assignee: Noble Paul The documentation refers to a REST API over and over, and yet I don't see a REST API. I see an HTTP API but not a REST API. Here are a few things the HTTP API does that are not RESTful: * Offers RPC verbs instead of resources/nouns. (E.g. schema API has commands like add-field, add-copy-field, etc.) * Tunnels non-idempotent requests (like creating a core) through idempotent HTTP verb (GET). * Tunnels deletes through HTTP GET. * PUT/POST confusion, POST used to update a named resource, such as the Blob API. * Returns `200 OK` HTTP code even when the command fails. (Try adding a field to your schema that already exists. You get `200 OK` and an error message hidden in the payload. Try calling a collections API when you're using non-cloud mode: `200 OK` and an error message in the payload. Gah.) * Does not provide link relations. * HTTP status line contains a JSON payload (!) and no 'Content-Type' header for some failed commands, like `curl -X DELETE http://solr:8983/solr/admin/cores/foo` * Content negotiation is done via query parameter (`wt=json`), instead of `Accept` header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (PYLUCENE-34) Pylucene and multiprocessing
[ https://issues.apache.org/jira/browse/PYLUCENE-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jose Lopez Veiga updated PYLUCENE-34: - Issue Type: Bug (was: Question) Pylucene and multiprocessing Key: PYLUCENE-34 URL: https://issues.apache.org/jira/browse/PYLUCENE-34 Project: PyLucene Issue Type: Bug Environment: pylucene 4.10, java 7, python 2.7.9, jcc 2.21, OS Mac Reporter: Jose Lopez Veiga Priority: Minor I've built a index that will be used for searching in a multiprocessing python program. When I try to search in the index, some queries are ok(first ones), but then the program is blocked in the first seconds of the execution when I use QueryParser.parse or IndexSearcher.search I tried all that I can think off but or the program is blocked or I get errors What is the best way to use multiprocessing and pylucene? I can't find a example or tutorial about this. Thank you for your help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (LUCENE-6371) Improve Spans payload collection
Paul Elschot created LUCENE-6371: Summary: Improve Spans payload collection Key: LUCENE-6371 URL: https://issues.apache.org/jira/browse/LUCENE-6371 Project: Lucene - Core Issue Type: Improvement Reporter: Paul Elschot Priority: Minor Spin off from LUCENE-6308, see the comments there from around 23 March 2015. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7315) SSL options don't seem to be working on trunk
[
https://issues.apache.org/jira/browse/SOLR-7315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382283#comment-14382283
]
Hoss Man commented on SOLR-7315:
here's what i tried, using {{secret}} anyplace i was prompted for a
password/passphrase...
{noformat}
hossman@frisbee:~/lucene/dev/solr/server/etc$ keytool -genkeypair -alias
solr-ssl -keyalg RSA -keysize 2048 -keypass secret -storepass secret -validity
-keystore solr-ssl.keystore.jks -ext
SAN=DNS:localhost,IP:192.168.1.3,IP:127.0.0.1 -dname CN=localhost,
OU=Organizational Unit, O=Organization, L=Location, ST=State, C=Country
hossman@frisbee:~/lucene/dev/solr/server/etc$ keytool -importkeystore
-srckeystore solr-ssl.keystore.jks -destkeystore solr-ssl.keystore.p12
-srcstoretype jks -deststoretype pkcs12
Enter destination keystore password:
Re-enter new password:
Enter source keystore password:
Entry for alias solr-ssl successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or
cancelled
hossman@frisbee:~/lucene/dev/solr/server/etc$ openssl pkcs12 -in
solr-ssl.keystore.p12 -out solr-ssl.pem
Enter Import Password:
MAC verified OK
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
hossman@frisbee:~/lucene/dev/solr/server/etc$ openssl pkcs12 -nokeys -in
solr-ssl.keystore.p12 -out solr-ssl.cacert.pem
Enter Import Password:
MAC verified OK
hossman@frisbee:~/lucene/dev/solr/server/etc$ svn diff ../../bin/solr.in.sh
Index: ../../bin/solr.in.sh
===
--- ../../bin/solr.in.sh(revision 1669370)
+++ ../../bin/solr.in.sh(working copy)
@@ -101,3 +101,8 @@
# Uncomment to set a specific SSL port (-Djetty.ssl.port=N); if not set
# and you are using SSL, then the start script will use SOLR_PORT for the SSL
port
#SOLR_SSL_PORT=
+
+SOLR_SSL_OPTS=-Djavax.net.ssl.keyStore=etc/solr-ssl.keystore.jks \
+ -Djavax.net.ssl.keyStorePassword=secret \
+ -Djavax.net.ssl.trustStore=etc/solr-ssl.keystore.jks \
+ -Djavax.net.ssl.trustStorePassword=secret
{noformat}
Then i started solr in another window using {{bin/solr -p 8984}} and now solr
is running with out SSL on port 8984...
{noformat}
hossman@frisbee:~/lucene/dev/solr/server/etc$ curl -E solr-ssl.pem:secret
--cacert solr-ssl.pem
https://localhost:8984/solr/admin/collections?action=CLUSTERSTATUSwt=jsonindent=on;
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
hossman@frisbee:~/lucene/dev/solr/server/etc$ curl -E solr-ssl.pem:secret
--cacert solr-ssl.pem
http://localhost:8984/solr/admin/collections?action=CLUSTERSTATUSwt=jsonindent=on;
{
responseHeader:{
status:400,
QTime:4},
error:{
msg:Solr instance is not running in SolrCloud mode.,
code:400}}
{noformat}
SSL options don't seem to be working on trunk
-
Key: SOLR-7315
URL: https://issues.apache.org/jira/browse/SOLR-7315
Project: Solr
Issue Type: Bug
Affects Versions: Trunk
Reporter: Hoss Man
Assignee: Steve Rowe
while trying to review another patch affecting bin/solr, i attempted to
verify that things were working with SSL, and then realized that even with an
unmodified trunk, the documented steps for enabling SSL don't seem to work --
*THEY DO WORK ON 5X, JUST NOT TRUNK*
i'll post full details in a comment
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7316) API to create a core is broken
[
https://issues.apache.org/jira/browse/SOLR-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Haase updated SOLR-7316:
-
Description:
h1. Steps To Reproduce
{code}
curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
{code}
h1. Expected Result
Create a core called new_core.
h1. Actual Result
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
My response:
{quote}
*The whole point of creating APIs is to abstract out details that the caller
doesn't need to know, and yet this API requires an understanding of Solr's
internal file structure and history of the project?*
{quote}
was:
h1. Steps To Reproduce
{code}
curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
{code}
h1. Expected Result
Create a core called new_core.
h1. Actual Result
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
My response:
{quote}
From an API consumer's point of view, I'm not really interested in being
forced to learn the history of the project to use the API. *The whole point of
creating APIs is to abstract out details that the caller doesn't need to know,
and yet this API requires an understanding of Solr's internal file structure
and history of the project?*
{quote}
(Emphasis added.)
API to create a core is broken
--
Key: SOLR-7316
URL: https://issues.apache.org/jira/browse/SOLR-7316
Project: Solr
Issue Type: Bug
Components: Server
Affects Versions: 5.0
Reporter: Mark Haase
h1. Steps To Reproduce
{code}
curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
{code}
h1. Expected Result
Create a core called new_core.
h1. Actual Result
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
My response:
{quote}
*The whole point of creating APIs is to abstract out details that the caller
doesn't need to know, and yet this API requires an understanding of Solr's
internal file structure and history of the project?*
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6673) MDC based logging of collection, shard etc.
[ https://issues.apache.org/jira/browse/SOLR-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382289#comment-14382289 ] ASF subversion and git services commented on SOLR-6673: --- Commit 1669375 from sha...@apache.org in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1669375 ] SOLR-6673: Fix NPE MDC based logging of collection, shard etc. --- Key: SOLR-6673 URL: https://issues.apache.org/jira/browse/SOLR-6673 Project: Solr Issue Type: Improvement Reporter: Ishan Chattopadhyaya Assignee: Noble Paul Labels: logging Fix For: Trunk, 5.1 Attachments: SOLR-6673-log-more.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673_NPE_fix.patch, log4j.properties, log4j.properties In cloud mode, the many log items don't contain the collection name, shard name, core name etc. Debugging becomes specially difficult when many collections/shards are hosted on the same node. The proposed solution adds MDC based stamping of collection, shard, core to the thread. See also: SOLR-5969, SOLR-5277 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7316) API to create a core is broken
[
https://issues.apache.org/jira/browse/SOLR-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Haase updated SOLR-7316:
-
Description:
h1. Steps To Reproduce
{code}
curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
{code}
h1. Expected Result
Create a core called new_core.
h1. Actual Result
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
*The whole point of creating APIs is to abstract out details that the caller
doesn't need to know, and yet this API requires an understanding of Solr's
internal file structure and history of the project?* I'm speechless.
was:
h1. Steps To Reproduce
{code}
curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
{code}
h1. Expected Result
Create a core called new_core.
h1. Actual Result
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
My response:
{quote}
*The whole point of creating APIs is to abstract out details that the caller
doesn't need to know, and yet this API requires an understanding of Solr's
internal file structure and history of the project?*
{quote}
API to create a core is broken
--
Key: SOLR-7316
URL: https://issues.apache.org/jira/browse/SOLR-7316
Project: Solr
Issue Type: Bug
Components: Server
Affects Versions: 5.0
Reporter: Mark Haase
h1. Steps To Reproduce
{code}
curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
{code}
h1. Expected Result
Create a core called new_core.
h1. Actual Result
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
*The whole point of creating APIs is to abstract out details that the caller
doesn't need to know, and yet this API requires an understanding of Solr's
internal file structure and history of the project?* I'm speechless.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7312) REST API is not REST
[
https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382197#comment-14382197
]
Noble Paul commented on SOLR-7312:
--
bq.How about changing the API to actually conform to RESTful?
The choice was deliberate. pure REST was inconvenient and inefficient for those
commands . We needed bulk commands
* editing the schema/config would result in core reload and doing one at a time
means more reloads
* We need to ensure that the editing process is transactional. If I wish to do
10 operations all 10 must either succeed or fail. Partial success is not useful
* Using REST means different payload for unix, windows , web interface
* REST means you are interlacing shell commands in your payload curl etc.
Which means someone really has to verify if you are performing anything risky
because mostly the ops run commands as {{su}}
To be honest the REST paradigm is terrible from an ops point of view . We
should follow standards only if it helps our users
REST API is not REST
--
Key: SOLR-7312
URL: https://issues.apache.org/jira/browse/SOLR-7312
Project: Solr
Issue Type: Bug
Components: Server
Affects Versions: 5.0
Reporter: Mark Haase
Assignee: Noble Paul
The documentation refers to a REST API over and over, and yet I don't see a
REST API. I see an HTTP API but not a REST API. Here are a few things the
HTTP API does that are not RESTful:
* Offers RPC verbs instead of resources/nouns. (E.g. schema API has commands
like add-field, add-copy-field, etc.)
* Tunnels non-idempotent requests (like creating a core) through idempotent
HTTP verb (GET).
* Tunnels deletes through HTTP GET.
* PUT/POST confusion, POST used to update a named resource, such as the Blob
API.
* Returns `200 OK` HTTP code even when the command fails. (Try adding a field
to your schema that already exists. You get `200 OK` and an error message
hidden in the payload. Try calling a collections API when you're using
non-cloud mode: `200 OK` and an error message in the payload. Gah.)
* Does not provide link relations.
* HTTP status line contains a JSON payload (!) and no 'Content-Type' header
for some failed commands, like `curl -X DELETE
http://solr:8983/solr/admin/cores/foo`
* Content negotiation is done via query parameter (`wt=json`), instead of
`Accept` header.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7315) SSL options don't seem to be working on trunk
Hoss Man created SOLR-7315: -- Summary: SSL options don't seem to be working on trunk Key: SOLR-7315 URL: https://issues.apache.org/jira/browse/SOLR-7315 Project: Solr Issue Type: Bug Affects Versions: Trunk Reporter: Hoss Man Assignee: Steve Rowe while trying to review another patch affecting bin/solr, i attempted to verify that things were working with SSL, and then realized that even with an unmodified trunk, the documented steps for enabling SSL don't seem to work -- *THEY DO WORK ON 5X, JUST NOT TRUNK* i'll post full details in a comment -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382293#comment-14382293 ] Mark Haase commented on SOLR-7312: -- I will argue, though, that this is not a wish or an improvement. The documentation is buggy. It doesn't fail any unit tests or lints like broken code, _but the documentation is broken_. This is a bug. REST API is not REST -- Key: SOLR-7312 URL: https://issues.apache.org/jira/browse/SOLR-7312 Project: Solr Issue Type: Improvement Components: Server Affects Versions: 5.0 Reporter: Mark Haase Assignee: Noble Paul The documentation refers to a REST API over and over, and yet I don't see a REST API. I see an HTTP API but not a REST API. Here are a few things the HTTP API does that are not RESTful: * Offers RPC verbs instead of resources/nouns. (E.g. schema API has commands like add-field, add-copy-field, etc.) * Tunnels non-idempotent requests (like creating a core) through idempotent HTTP verb (GET). * Tunnels deletes through HTTP GET. * PUT/POST confusion, POST used to update a named resource, such as the Blob API. * Returns `200 OK` HTTP code even when the command fails. (Try adding a field to your schema that already exists. You get `200 OK` and an error message hidden in the payload. Try calling a collections API when you're using non-cloud mode: `200 OK` and an error message in the payload. Gah.) * Does not provide link relations. * HTTP status line contains a JSON payload (!) and no 'Content-Type' header for some failed commands, like `curl -X DELETE http://solr:8983/solr/admin/cores/foo` * Content negotiation is done via query parameter (`wt=json`), instead of `Accept` header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Updated] (PYLUCENE-34) Pylucene and multiprocessing
On Thu, 26 Mar 2015, Jose Lopez Veiga (JIRA) wrote: EDIT: I found that the block happend when I import nltk, only in multriprocessing. What is 'nltk' and what does it have to do with PyLucene ? Andi.. This is a reported bug? was: I've built a index that will be used for searching in a multiprocessing python program. When I try to search in the index, some queries are ok(first ones), but then the program is blocked in the first seconds of the execution when I use QueryParser.parse or IndexSearcher.search I tried all that I can think off but or the program is blocked or I get errors What is the best way to use multiprocessing and pylucene? I can't find a example or tutorial about this. Thank you for your help. Pylucene and multiprocessing Key: PYLUCENE-34 URL: https://issues.apache.org/jira/browse/PYLUCENE-34 Project: PyLucene Issue Type: Bug Environment: pylucene 4.10, java 7, python 2.7.9, jcc 2.21, OS Mac Reporter: Jose Lopez Veiga Priority: Minor I've built a index that will be used for searching in a multiprocessing python program. When I try to search in the index, some queries are ok(first ones), but then the program is blocked in the first seconds of the execution when I use QueryParser.parse or IndexSearcher.search I tried all that I can think off but or the program is blocked or I get errors What is the best way to use multiprocessing and pylucene? I can't find a example or tutorial about this. Thank you for your help. EDIT: I found that the block happend when I import nltk, only in multriprocessing. This is a reported bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382348#comment-14382348 ] Noble Paul commented on SOLR-7312: -- if you are asking if we could bend ourselves backwards and satisfy the REST standard? probably yes . And we will be able to do nothing more than we already do with the current set of APIs. So , the value add is questionable for an average Solr user REST API is not REST -- Key: SOLR-7312 URL: https://issues.apache.org/jira/browse/SOLR-7312 Project: Solr Issue Type: Improvement Components: Server Affects Versions: 5.0 Reporter: Mark Haase Assignee: Noble Paul The documentation refers to a REST API over and over, and yet I don't see a REST API. I see an HTTP API but not a REST API. Here are a few things the HTTP API does that are not RESTful: * Offers RPC verbs instead of resources/nouns. (E.g. schema API has commands like add-field, add-copy-field, etc.) * Tunnels non-idempotent requests (like creating a core) through idempotent HTTP verb (GET). * Tunnels deletes through HTTP GET. * PUT/POST confusion, POST used to update a named resource, such as the Blob API. * Returns `200 OK` HTTP code even when the command fails. (Try adding a field to your schema that already exists. You get `200 OK` and an error message hidden in the payload. Try calling a collections API when you're using non-cloud mode: `200 OK` and an error message in the payload. Gah.) * Does not provide link relations. * HTTP status line contains a JSON payload (!) and no 'Content-Type' header for some failed commands, like `curl -X DELETE http://solr:8983/solr/admin/cores/foo` * Content negotiation is done via query parameter (`wt=json`), instead of `Accept` header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6673) MDC based logging of collection, shard etc.
[ https://issues.apache.org/jira/browse/SOLR-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-6673: --- Attachment: SOLR-6673_NPE_fix.patch Added a patch for the NPE fix at SolrDispatchFilter (trunk). MDC based logging of collection, shard etc. --- Key: SOLR-6673 URL: https://issues.apache.org/jira/browse/SOLR-6673 Project: Solr Issue Type: Improvement Reporter: Ishan Chattopadhyaya Assignee: Noble Paul Labels: logging Fix For: Trunk, 5.1 Attachments: SOLR-6673-log-more.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673_NPE_fix.patch, log4j.properties, log4j.properties In cloud mode, the many log items don't contain the collection name, shard name, core name etc. Debugging becomes specially difficult when many collections/shards are hosted on the same node. The proposed solution adds MDC based stamping of collection, shard, core to the thread. See also: SOLR-5969, SOLR-5277 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b54) - Build # 12101 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12101/ Java: 64bit/jdk1.9.0-ea-b54 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.handler.TestSolrConfigHandlerCloud.test Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([63C9C3CF4FA055C7:EB9DFC15E15C383F]:0) at org.apache.solr.core.TestSolrConfigHandler.reqhandlertests(TestSolrConfigHandler.java:382) at org.apache.solr.handler.TestSolrConfigHandlerCloud.testReqHandlerAPIs(TestSolrConfigHandlerCloud.java:91) at org.apache.solr.handler.TestSolrConfigHandlerCloud.test(TestSolrConfigHandlerCloud.java:77) 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:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-6816) Review SolrCloud Indexing Performance.
[
https://issues.apache.org/jira/browse/SOLR-6816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382123#comment-14382123
]
Yonik Seeley commented on SOLR-6816:
bq. I didn't think the lookupVersion would be that much of an overhead, but my
testing shows that it is, even when using docValues for the version field.
Can you tell what part is taking so much time? Looking up the ID to find the
internal lucene docid? Obtaining the docvalues reference? or using it to look
up the version? My guess would be that it's the external-id to internal-id
translation that is the slowest.
There's another way to safely transparently speed up indexing for everyone:
maintain-highest version-per-bucket. It's been the plan since the beginning...
see VersionBucket:
{code}
public class VersionBucket {
public long highest;
public void updateHighest(long val) {
if (highest != 0) {
highest = Math.max(highest, Math.abs(val));
}
}
}
{code}
Right now, we start off with highest=0 (which essentially means unknown), so
we never update it.
If we could initialize the highest versions correctly (would need to get from
the index) then we would only need to check versions when a reorder happened on
the same bucket.
Review SolrCloud Indexing Performance.
--
Key: SOLR-6816
URL: https://issues.apache.org/jira/browse/SOLR-6816
Project: Solr
Issue Type: Task
Components: SolrCloud
Reporter: Mark Miller
Priority: Critical
Attachments: SolrBench.pdf
We have never really focused on indexing performance, just correctness and
low hanging fruit. We need to vet the performance and try to address any
holes.
Note: A common report is that adding any replication is very slow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7316) API to create a core is broken
[
https://issues.apache.org/jira/browse/SOLR-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Haase updated SOLR-7316:
-
Description:
h1. Steps To Reproduce
# curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
h1. Expected Result
Create a core called new_core.
h1. Actual Result
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
My response:
{quote}
From an API consumer's point of view, I'm not really interested in being
forced to learn the history of the project to use the API. *The whole point of
creating APIs is to abstract out details that the caller doesn't need to know,
and yet this API requires an understanding of Solr's internal file structure
and history of the project?*
{quote}
(Emphasis added.)
was:
Steps to reproduce:
1. curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
Expected result:
Create a core called new_core
Actual result:
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
My response:
{quote}
From an API consumer's point of view, I'm not really interested in being
forced to learn the history of the project to use the API. *The whole point of
creating APIs is to abstract out details that the caller doesn't need to know,
and yet this API requires an understanding of Solr's internal file structure
and history of the project?*
{quote}
(Emphasis added.)
API to create a core is broken
--
Key: SOLR-7316
URL: https://issues.apache.org/jira/browse/SOLR-7316
Project: Solr
Issue Type: Bug
Components: Server
Affects Versions: 5.0
Reporter: Mark Haase
h1. Steps To Reproduce
# curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
h1. Expected Result
Create a core called new_core.
h1. Actual Result
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
My response:
{quote}
From an API consumer's point of view, I'm not really interested in being
forced to learn the history of the project to use the API. *The whole point
of creating APIs is to abstract out details that the caller doesn't need to
know, and yet this API requires an understanding of Solr's internal file
structure and history of the project?*
{quote}
(Emphasis added.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6673) MDC based logging of collection, shard etc.
[ https://issues.apache.org/jira/browse/SOLR-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382286#comment-14382286 ] ASF subversion and git services commented on SOLR-6673: --- Commit 1669374 from sha...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1669374 ] SOLR-6673: Fix NPE MDC based logging of collection, shard etc. --- Key: SOLR-6673 URL: https://issues.apache.org/jira/browse/SOLR-6673 Project: Solr Issue Type: Improvement Reporter: Ishan Chattopadhyaya Assignee: Noble Paul Labels: logging Fix For: Trunk, 5.1 Attachments: SOLR-6673-log-more.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673.patch, SOLR-6673_NPE_fix.patch, log4j.properties, log4j.properties In cloud mode, the many log items don't contain the collection name, shard name, core name etc. Debugging becomes specially difficult when many collections/shards are hosted on the same node. The proposed solution adds MDC based stamping of collection, shard, core to the thread. See also: SOLR-5969, SOLR-5277 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7316) API to create a core is broken
[
https://issues.apache.org/jira/browse/SOLR-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Haase updated SOLR-7316:
-
Description:
h1. Steps To Reproduce
{code}
curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
{code}
h1. Expected Result
Create a core called new_core.
h1. Actual Result
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
My response:
{quote}
From an API consumer's point of view, I'm not really interested in being
forced to learn the history of the project to use the API. *The whole point of
creating APIs is to abstract out details that the caller doesn't need to know,
and yet this API requires an understanding of Solr's internal file structure
and history of the project?*
{quote}
(Emphasis added.)
was:
h1. Steps To Reproduce
# curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
h1. Expected Result
Create a core called new_core.
h1. Actual Result
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
My response:
{quote}
From an API consumer's point of view, I'm not really interested in being
forced to learn the history of the project to use the API. *The whole point of
creating APIs is to abstract out details that the caller doesn't need to know,
and yet this API requires an understanding of Solr's internal file structure
and history of the project?*
{quote}
(Emphasis added.)
API to create a core is broken
--
Key: SOLR-7316
URL: https://issues.apache.org/jira/browse/SOLR-7316
Project: Solr
Issue Type: Bug
Components: Server
Affects Versions: 5.0
Reporter: Mark Haase
h1. Steps To Reproduce
{code}
curl
'http://localhost:8983/solr/admin/cores?action=CREATEname=new_coreinstanceDir=new_core'
{code}
h1. Expected Result
Create a core called new_core.
h1. Actual Result
{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused
by: Can't find resource 'solrconfig.xml' in classpath or
'/var/solr/data/new_core/conf'
{quote}
Somebody on solr-users tells me:
{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}
Huh? Where is this magical knowledge mentioned in the [API
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
Another user on the list serve says:
{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}
My response:
{quote}
From an API consumer's point of view, I'm not really interested in being
forced to learn the history of the project to use the API. *The whole point
of creating APIs is to abstract out details that the caller doesn't need to
know, and yet this API requires an understanding of Solr's internal file
structure and history of the project?*
{quote}
(Emphasis added.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 2053 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2053/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseSerialGC
1 tests failed.
FAILED: org.apache.solr.handler.TestSolrConfigHandlerCloud.test
Error Message:
Could not get expected value 'org.apache.solr.spelling.SpellingQueryConverter'
for path 'config/queryConverter/qc/class' full output: { responseHeader:{
status:0, QTime:0}, config:{ znodeVersion:0,
luceneMatchVersion:org.apache.lucene.util.Version:5.1.0,
updateHandler:{ class:solr.DirectUpdateHandler2,
autoCommmitMaxDocs:-1, indexWriterCloseWaitsForMerges:true,
openSearcher:true, commitIntervalLowerBound:-1,
commitWithinSoftCommit:true, autoCommit:{ maxDocs:-1,
maxTime:-1, commitIntervalLowerBound:-1},
autoSoftCommit:{ maxDocs:-1, maxTime:-1}}, query:{
useFilterForSortedQuery:false, queryResultWindowSize:1,
queryResultMaxDocsCached:2147483647, enableLazyFieldLoading:false,
maxBooleanClauses:1024, :{ size:1,
initialSize:10, showItems:-1,
name:fieldValueCache}}, requestHandler:{ standard:{
class:solr.StandardRequestHandler, name:standard},
/admin/file:{ class:solr.admin.ShowFileRequestHandler,
name:/admin/file, invariants:{hidden:bogus.txt}},
/update:{ name:/update,
class:org.apache.solr.handler.UpdateRequestHandler, defaults:{}},
/update/json:{ name:/update/json,
class:org.apache.solr.handler.UpdateRequestHandler,
defaults:{update.contentType:application/json}}, /update/csv:{
name:/update/csv,
class:org.apache.solr.handler.UpdateRequestHandler,
defaults:{update.contentType:application/csv}},
/update/json/docs:{ name:/update/json/docs,
class:org.apache.solr.handler.UpdateRequestHandler, defaults:{
update.contentType:application/json,
json.command:false}}, /config:{ name:/config,
class:org.apache.solr.handler.SolrConfigHandler, defaults:{}},
/schema:{ name:/schema,
class:org.apache.solr.handler.SchemaHandler, defaults:{}},
/replication:{ name:/replication,
class:org.apache.solr.handler.ReplicationHandler, defaults:{}},
/get:{ name:/get,
class:org.apache.solr.handler.RealTimeGetHandler, defaults:{
omitHeader:true, wt:json, indent:true}},
/admin/luke:{ name:/admin/luke,
class:org.apache.solr.handler.admin.LukeRequestHandler,
defaults:{}}, /admin/system:{ name:/admin/system,
class:org.apache.solr.handler.admin.SystemInfoHandler,
defaults:{}}, /admin/mbeans:{ name:/admin/mbeans,
class:org.apache.solr.handler.admin.SolrInfoMBeanHandler,
defaults:{}}, /admin/plugins:{ name:/admin/plugins,
class:org.apache.solr.handler.admin.PluginInfoHandler,
defaults:{}}, /admin/threads:{ name:/admin/threads,
class:org.apache.solr.handler.admin.ThreadDumpHandler,
defaults:{}}, /admin/properties:{ name:/admin/properties,
class:org.apache.solr.handler.admin.PropertiesRequestHandler,
defaults:{}}, /admin/logging:{ name:/admin/logging,
class:org.apache.solr.handler.admin.LoggingHandler,
defaults:{}}, /admin/ping:{ name:/admin/ping,
class:org.apache.solr.handler.PingRequestHandler, defaults:{},
invariants:{ echoParams:all,
q:solrpingquery}}, /admin/segments:{
name:/admin/segments,
class:org.apache.solr.handler.admin.SegmentsInfoRequestHandler,
defaults:{}}}, directoryFactory:{
class:org.apache.solr.core.MockDirectoryFactory,
name:DirectoryFactory, solr.hdfs.blockcache.enabled:true,
solr.hdfs.blockcache.blocksperbank:1024, solr.hdfs.home:,
solr.hdfs.confdir:, solr.hdfs.blockcache.global:false},
updateRequestProcessorChain:[ { name:nodistrib,
:[ {class:solr.NoOpDistributingUpdateProcessorFactory},
{class:solr.RunUpdateProcessorFactory}]}, {
name:dedupe, :[ {
class:org.apache.solr.update.processor.SignatureUpdateProcessorFactory,
enabled:true, overwriteDupes:true,
fields:v_t,t_field,
signatureClass:org.apache.solr.update.processor.TextProfileSignature},
{class:solr.RunUpdateProcessorFactory}]}, {
name:stored_sig, :[ {
class:org.apache.solr.update.processor.SignatureUpdateProcessorFactory,
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_40) - Build # 4481 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4481/ Java: 32bit/jdk1.8.0_40 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestSolrConfigHandler Error Message: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010\collection1\conf\params.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010\collection1\conf\params.json: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010\collection1\conf\params.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010\collection1\conf\params.json: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 26E20402D5866F43-001: java.nio.file.DirectoryNotEmptyException:
[jira] [Commented] (SOLR-7307) Make it easier to create an EmbeddedSolrServer
[
https://issues.apache.org/jira/browse/SOLR-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382521#comment-14382521
]
Shai Erera commented on SOLR-7307:
--
[~romseygeek] I think you've added a second TestEmbeddedSolrServer under the
same package, different folder though. My eclipse doesn't compile (clean trunk
checkout), and complains that these two exist:
{noformat}
solr/solrj/src/test/org/apache/solr/client/solrj/embedded/TestEmbeddedSolrServer.java
solr/core/src/test/org/apache/solr/client/solrj/embedded/TestEmbeddedSolrServer.java
{noformat}
One under solr/solrj and one under solr/core.
Make it easier to create an EmbeddedSolrServer
--
Key: SOLR-7307
URL: https://issues.apache.org/jira/browse/SOLR-7307
Project: Solr
Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
Attachments: SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch,
SOLR-7307.patch
At the moment, if you want to create an EmbeddedSolrServer you have to
instantiate a CoreContainer and then pass it in to the ESS constructor, which
involves a fair amount of ceremony. You should be able to just pass a path
to a solr home directory, or a NodeConfig object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7212) Parameter substitution across whole request
[
https://issues.apache.org/jira/browse/SOLR-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382550#comment-14382550
]
Shai Erera commented on SOLR-7212:
--
Thanks, eclipse is happy now!
Parameter substitution across whole request
---
Key: SOLR-7212
URL: https://issues.apache.org/jira/browse/SOLR-7212
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
Fix For: 5.1
Attachments: SOLR-7212.patch
Simple example:
{code}
q=price:[ ${low} TO ${high} ]
low=100
high=200
{code}
Blog Post:
http://yonik.com/solr-query-parameter-substitution/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7212) Parameter substitution across whole request
[
https://issues.apache.org/jira/browse/SOLR-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382551#comment-14382551
]
ASF subversion and git services commented on SOLR-7212:
---
Commit 1669425 from [~yo...@apache.org] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1669425 ]
SOLR-7212: tests - fix package mismatch
Parameter substitution across whole request
---
Key: SOLR-7212
URL: https://issues.apache.org/jira/browse/SOLR-7212
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
Fix For: 5.1
Attachments: SOLR-7212.patch
Simple example:
{code}
q=price:[ ${low} TO ${high} ]
low=100
high=200
{code}
Blog Post:
http://yonik.com/solr-query-parameter-substitution/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7307) Make it easier to create an EmbeddedSolrServer
[ https://issues.apache.org/jira/browse/SOLR-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382592#comment-14382592 ] ASF subversion and git services commented on SOLR-7307: --- Commit 1669427 from [~romseygeek] in branch 'dev/trunk' [ https://svn.apache.org/r1669427 ] SOLR-7307: Rename test file to make Eclipse happy Make it easier to create an EmbeddedSolrServer -- Key: SOLR-7307 URL: https://issues.apache.org/jira/browse/SOLR-7307 Project: Solr Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Attachments: SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch At the moment, if you want to create an EmbeddedSolrServer you have to instantiate a CoreContainer and then pass it in to the ESS constructor, which involves a fair amount of ceremony. You should be able to just pass a path to a solr home directory, or a NodeConfig object. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7298) Fix Collections API SolrJ calls to not add name parameter when not needed
[ https://issues.apache.org/jira/browse/SOLR-7298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382593#comment-14382593 ] ASF subversion and git services commented on SOLR-7298: --- Commit 1669428 from [~shaie] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1669428 ] SOLR-7298: Fix Collections API SolrJ calls to not add name parameter when not needed Fix Collections API SolrJ calls to not add name parameter when not needed - Key: SOLR-7298 URL: https://issues.apache.org/jira/browse/SOLR-7298 Project: Solr Issue Type: Bug Components: SolrCloud, SolrJ Affects Versions: 5.0 Reporter: Anshum Gupta Assignee: Shai Erera Attachments: SOLR-7298.patch, SOLR-7298.patch, collection_api_params.xls Collections API SolrJ calls add the name parameter for a lot of calls incorrectly. It should only be added when required. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7307) Make it easier to create an EmbeddedSolrServer
[ https://issues.apache.org/jira/browse/SOLR-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382595#comment-14382595 ] Shai Erera commented on SOLR-7307: -- Or, perhaps they could be merged into one? Anyway, your call. Make it easier to create an EmbeddedSolrServer -- Key: SOLR-7307 URL: https://issues.apache.org/jira/browse/SOLR-7307 Project: Solr Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Attachments: SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch At the moment, if you want to create an EmbeddedSolrServer you have to instantiate a CoreContainer and then pass it in to the ESS constructor, which involves a fair amount of ceremony. You should be able to just pass a path to a solr home directory, or a NodeConfig object. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7307) Make it easier to create an EmbeddedSolrServer
[ https://issues.apache.org/jira/browse/SOLR-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382594#comment-14382594 ] ASF subversion and git services commented on SOLR-7307: --- Commit 1669429 from [~romseygeek] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1669429 ] SOLR-7307: Rename test file to make Eclipse happy Make it easier to create an EmbeddedSolrServer -- Key: SOLR-7307 URL: https://issues.apache.org/jira/browse/SOLR-7307 Project: Solr Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Attachments: SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch At the moment, if you want to create an EmbeddedSolrServer you have to instantiate a CoreContainer and then pass it in to the ESS constructor, which involves a fair amount of ceremony. You should be able to just pass a path to a solr home directory, or a NodeConfig object. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b06) - Build # 12103 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12103/ Java: 64bit/jdk1.8.0_60-ea-b06 -XX:+UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test Error Message: Error from server at http://127.0.0.1:51914/_/da/compositeid_collection_with_routerfield_shard1_replica1: no servers hosting shard: Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:51914/_/da/compositeid_collection_with_routerfield_shard1_replica1: no servers hosting shard: at __randomizedtesting.SeedInfo.seed([5F2D4E22156E1C2B:D77971F8BB9271D3]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:556) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:233) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:225) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testDeleteByIdCompositeRouterWithRouterField(FullSolrCloudDistribCmdsTest.java:357) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:146) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-7212) Parameter substitution across whole request
[
https://issues.apache.org/jira/browse/SOLR-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382533#comment-14382533
]
Yonik Seeley commented on SOLR-7212:
hmmm, why the heck did this work for me. let me look.
Parameter substitution across whole request
---
Key: SOLR-7212
URL: https://issues.apache.org/jira/browse/SOLR-7212
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
Fix For: 5.1
Attachments: SOLR-7212.patch
Simple example:
{code}
q=price:[ ${low} TO ${high} ]
low=100
high=200
{code}
Blog Post:
http://yonik.com/solr-query-parameter-substitution/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7212) Parameter substitution across whole request
[
https://issues.apache.org/jira/browse/SOLR-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382538#comment-14382538
]
ASF subversion and git services commented on SOLR-7212:
---
Commit 1669423 from [~yo...@apache.org] in branch 'dev/trunk'
[ https://svn.apache.org/r1669423 ]
SOLR-7212: tests - fix package mismatch
Parameter substitution across whole request
---
Key: SOLR-7212
URL: https://issues.apache.org/jira/browse/SOLR-7212
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
Fix For: 5.1
Attachments: SOLR-7212.patch
Simple example:
{code}
q=price:[ ${low} TO ${high} ]
low=100
high=200
{code}
Blog Post:
http://yonik.com/solr-query-parameter-substitution/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_60-ea-b06) - Build # 11936 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11936/ Java: 32bit/jdk1.8.0_60-ea-b06 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test Error Message: There were too many update fails - we expect it can happen, but shouldn't easily Stack Trace: java.lang.AssertionError: There were too many update fails - we expect it can happen, but shouldn't easily at __randomizedtesting.SeedInfo.seed([CFB436129389FAA9:47E009C83D759751]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:222) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:958) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:933) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-7212) Parameter substitution across whole request
[
https://issues.apache.org/jira/browse/SOLR-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382545#comment-14382545
]
ASF subversion and git services commented on SOLR-7212:
---
Commit 1669424 from [~yo...@apache.org] in branch 'dev/trunk'
[ https://svn.apache.org/r1669424 ]
SOLR-7212: tests - fix package mismatch
Parameter substitution across whole request
---
Key: SOLR-7212
URL: https://issues.apache.org/jira/browse/SOLR-7212
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
Fix For: 5.1
Attachments: SOLR-7212.patch
Simple example:
{code}
q=price:[ ${low} TO ${high} ]
low=100
high=200
{code}
Blog Post:
http://yonik.com/solr-query-parameter-substitution/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7298) Fix Collections API SolrJ calls to not add name parameter when not needed
[ https://issues.apache.org/jira/browse/SOLR-7298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382576#comment-14382576 ] ASF subversion and git services commented on SOLR-7298: --- Commit 1669426 from [~shaie] in branch 'dev/trunk' [ https://svn.apache.org/r1669426 ] SOLR-7298: Fix Collections API SolrJ calls to not add name parameter when not needed Fix Collections API SolrJ calls to not add name parameter when not needed - Key: SOLR-7298 URL: https://issues.apache.org/jira/browse/SOLR-7298 Project: Solr Issue Type: Bug Components: SolrCloud, SolrJ Affects Versions: 5.0 Reporter: Anshum Gupta Assignee: Shai Erera Attachments: SOLR-7298.patch, SOLR-7298.patch, collection_api_params.xls Collections API SolrJ calls add the name parameter for a lot of calls incorrectly. It should only be added when required. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7307) Make it easier to create an EmbeddedSolrServer
[ https://issues.apache.org/jira/browse/SOLR-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382587#comment-14382587 ] Alan Woodward commented on SOLR-7307: - Huh, how odd. Ant and IntelliJ don't seem to have a problem with it. I'll rename the new one though. Make it easier to create an EmbeddedSolrServer -- Key: SOLR-7307 URL: https://issues.apache.org/jira/browse/SOLR-7307 Project: Solr Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Attachments: SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch, SOLR-7307.patch At the moment, if you want to create an EmbeddedSolrServer you have to instantiate a CoreContainer and then pass it in to the ESS constructor, which involves a fair amount of ceremony. You should be able to just pass a path to a solr home directory, or a NodeConfig object. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7317) Remove jhighlight.jar which contains LGPL-only code
[ https://issues.apache.org/jira/browse/SOLR-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated SOLR-7317: - Attachment: SOLR-7317.patch Patch removes jhighlight from ivy and its license files. I also included a section in Upgrading from Solr 5.0 about the removed .jar. Let me know if this should belong someplace else. I verified after running 'ant clean-jars resolve' that the .jar was removed from the build path in eclipse and the project itself. I think it's ready. Remove jhighlight.jar which contains LGPL-only code --- Key: SOLR-7317 URL: https://issues.apache.org/jira/browse/SOLR-7317 Project: Solr Issue Type: Bug Components: contrib - Solr Cell (Tika extraction) Reporter: Shai Erera Assignee: Shai Erera Attachments: SOLR-7317.patch See discussion here: http://markmail.org/message/hmufrjbpndclew7r. jhighlight-1.0.jar contains LGPL only code. We should remove it and upgrade to the proper Tika version when Tika pulls a proper version. See also TIKA-1581. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7298) Fix Collections API SolrJ calls to not add name parameter when not needed
[ https://issues.apache.org/jira/browse/SOLR-7298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved SOLR-7298. -- Resolution: Fixed Fix Version/s: 5.1 Trunk Committed to trunk and 5x. Thanks Anshum for the review! Fix Collections API SolrJ calls to not add name parameter when not needed - Key: SOLR-7298 URL: https://issues.apache.org/jira/browse/SOLR-7298 Project: Solr Issue Type: Bug Components: SolrCloud, SolrJ Affects Versions: 5.0 Reporter: Anshum Gupta Assignee: Shai Erera Fix For: Trunk, 5.1 Attachments: SOLR-7298.patch, SOLR-7298.patch, collection_api_params.xls Collections API SolrJ calls add the name parameter for a lot of calls incorrectly. It should only be added when required. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
