[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2583 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2583/ 5 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionTest.test Error Message: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:58558/_t/le/c8n_1x2_shard1_replica2 Stack Trace: org.apache.solr.client.solrj.SolrServerException: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:58558/_t/le/c8n_1x2_shard1_replica2 at __randomizedtesting.SeedInfo.seed([D22BA990232ABB32:5A7F964A8DD6D6CA]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:575) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:787) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730) at org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484) at org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501) at org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193) at org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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)
Re: issues[SOLR-1970]
On 2/3/2015 10:28 PM, MashupEye wrote:
I'm a solr user. now has a problem.
https://issues.apache.org/jira/browse/SOLR-1970
I think:
The conf directory might not be writable, the data directory is a
better place for dataimport.properties
or
This adds a propertywriter / element to solrconfig.xml file,
something like:
requestHandler name=/dataimport
class=org.apache.solr.handler.dataimport.DataImportHandler
lst name=defaults
str name=configdata-config.xml/str
lst name=propertywriter
str name=typeSimplePropertiesWriter/str
str name=directory${solr.product.data.dir}/str
/lst
lst name=datasource
str name=driver${jdbc.mysql.movie.driver}/str
str name=url${jdbc.mysql.movie.url}/str
str name=user${jdbc.mysql.movie.username}/str
str name=password${jdbc.mysql.movie.password}/str
int name=batchSize${jdbc.mysql.movie.batchsize}/int
bool name=readOnly${jdbc.mysql.movie.readonly}/bool
/lst
/lst
/requestHandler
This should have been sent to the solr-user mailing list, not the dev list.
http://lucene.apache.org/solr/resources.html#community
These are the possible problems that you might be experiencing:
1) The config element should be propertyWriter, not propertywriter.
Configurations are case sensitive.
2) The solr.product.data.dir system property is not defined, or not correct.
3) You're not using a new enough Solr version. 4.1.0 is required.
Thanks,
Shawn
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_31) - Build # 4357 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4357/ Java: 64bit/jdk1.8.0_31 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.lucene.facet.TestRandomSamplingFacetsCollector.testRandomSampling Error Message: 76 Stack Trace: java.lang.ArrayIndexOutOfBoundsException: 76 at __randomizedtesting.SeedInfo.seed([F6C13C5EAC0B79D3:1CD955431D5C8E64]:0) at org.apache.lucene.facet.TestRandomSamplingFacetsCollector.testRandomSampling(TestRandomSamplingFacetsCollector.java:133) 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:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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) Build Log: [...truncated 6207 lines...] [junit4] Suite: org.apache.lucene.facet.TestRandomSamplingFacetsCollector [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestRandomSamplingFacetsCollector -Dtests.method=testRandomSampling -Dtests.seed=F6C13C5EAC0B79D3 -Dtests.slow=true -Dtests.locale=ja_JP_JP_#u-ca-japanese -Dtests.timezone=Asia/Singapore -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [junit4] ERROR 0.37s | TestRandomSamplingFacetsCollector.testRandomSampling [junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException: 76 [junit4]
[jira] [Commented] (SOLR-1970) need to customize location of dataimport.properties
[
https://issues.apache.org/jira/browse/SOLR-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304650#comment-14304650
]
zippoy commented on SOLR-1970:
--
+1
The conf directory might not be writable
the data directory is a better place for dataimport.properties
need to customize location of dataimport.properties
---
Key: SOLR-1970
URL: https://issues.apache.org/jira/browse/SOLR-1970
Project: Solr
Issue Type: Improvement
Components: contrib - DataImportHandler
Affects Versions: 1.4
Reporter: Chris Book
Assignee: James Dyer
Fix For: 4.1, Trunk
By default dataimport.properties is written to {solr.home}/conf/. However
when using multiple solr cores, it is currently useful to use the same conf
directory for all of the cores and use solr.xml to specify a different
schema.xml. I can then specify a different data-config.xml for each core to
define how the data gets from the database to each core's shema.
However, all the solr cores will fight over writing to the
dataimport.properties file. There should be an option in solrconfig.xml to
specify the location or name of this file so that a different one can be used
for each core.
--
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
issues[SOLR-1970]
Hi, friends:
I'm a solr user. now has a problem.
https://issues.apache.org/jira/browse/SOLR-1970
I think:
The conf directory might not be writable, the data directory is a better
place for dataimport.properties
or
This adds a propertywriter / element to solrconfig.xml file,
something like:
requestHandler name=/dataimport
class=org.apache.solr.handler.dataimport.DataImportHandler
lst name=defaults
str name=configdata-config.xml/str
lst name=propertywriter
str name=typeSimplePropertiesWriter/str
str name=directory${solr.product.data.dir}/str
/lst
lst name=datasource
str name=driver${jdbc.mysql.movie.driver}/str
str name=url${jdbc.mysql.movie.url}/str
str name=user${jdbc.mysql.movie.username}/str
str name=password${jdbc.mysql.movie.password}/str
int name=batchSize${jdbc.mysql.movie.batchsize}/int
bool name=readOnly${jdbc.mysql.movie.readonly}/bool
/lst
/lst
/requestHandler
Please mark this issues, thank you very much!
best wishes!
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_31) - Build # 4461 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4461/ Java: 32bit/jdk1.8.0_31 -server -XX:+UseG1GC 2 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\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010\collection1\conf\configoverlay.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-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\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-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\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010\collection1\conf\configoverlay.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-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\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 9D0AE3276BC9A82A-001: java.nio.file.DirectoryNotEmptyException:
[jira] [Commented] (SOLR-6775) Creating backup snapshot null pointer exception
[ https://issues.apache.org/jira/browse/SOLR-6775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304744#comment-14304744 ] Steve Fatula commented on SOLR-6775: I have the exact same issue on Solr 4.10.3. 803906 [Thread-52] INFO org.apache.solr.handler.SnapShooter – Creating backup snapshot... Exception in thread Thread-52 java.lang.NullPointerException at org.apache.solr.handler.SnapPuller.delTree(SnapPuller.java:1026) at org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:162) at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:91) Creating backup snapshot null pointer exception --- Key: SOLR-6775 URL: https://issues.apache.org/jira/browse/SOLR-6775 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 4.10 Environment: Linux Server, Java version 1.7.0_21, Solr version 4.10.0 Reporter: Ryan Hesson Labels: snapshot, solr I set up Solr Replication. I have one master on a server, one slave on another server. The replication of data appears functioning correctly. The issue is when the master SOLR tries to create a snapshot backup it gets a null pointer exception. org.apache.solr.handler.SnapShooter createSnapshot method calls org.apache.solr.handler.SnapPuller.delTree(snapShotDir); at line 162 and the exception happens within org.apache.solr.handler.SnapPuller at line 1026 because snapShotDir is null. Here is the actual log output: 58319963 [qtp12610551-16] INFO org.apache.solr.core.SolrCore - newest commit generation = 349 58319983 [Thread-19] INFO org.apache.solr.handler.SnapShooter - Creating backup snapshot... Exception in thread Thread-19 java.lang.NullPointerException at org.apache.solr.handler.SnapPuller.delTree(SnapPuller.java:1026) at org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:162) at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:91) I may have missed how to set the directory in the documentation but I've looked around without much luck. I thought the process was to use the same directory as the index data for the snapshots. Is this a known issue with this release or am I missing how to set the value? If someone could tell me how to set snapshotdir or confirm that it is an issue and a different way of backing up the index is needed it would be much appreciated. -- 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 # 2579 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2579/ 5 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionTest.test Error Message: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:48385/c8n_1x2_shard1_replica2 Stack Trace: org.apache.solr.client.solrj.SolrServerException: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:48385/c8n_1x2_shard1_replica2 at __randomizedtesting.SeedInfo.seed([2467935EDB9B6614:AC33AC8475670BEC]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:575) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:787) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730) at org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484) at org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501) at org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193) at org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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-6787) API to manage blobs in Solr
[
https://issues.apache.org/jira/browse/SOLR-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303351#comment-14303351
]
ASF subversion and git services commented on SOLR-6787:
---
Commit 1656747 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1656747 ]
SOLR-6787: .system collection create fails if /configs dir is not present in ZK
API to manage blobs in Solr
Key: SOLR-6787
URL: https://issues.apache.org/jira/browse/SOLR-6787
Project: Solr
Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0, Trunk
Attachments: SOLR-6787.patch, SOLR-6787.patch
A special collection called .system needs to be created by the user to
store/manage blobs. The schema/solrconfig of that collection need to be
automatically supplied by the system so that there are no errors
APIs need to be created to manage the content of that collection
{code}
#create your .system collection first
http://localhost:8983/solr/admin/collections?action=CREATEname=.systemreplicationFactor=2
#The config for this collection is automatically created . numShards for this
collection is hardcoded to 1
#create a new jar or add a new version of a jar
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@mycomponent.jar http://localhost:8983/solr/.system/blob/mycomponent
# GET on the end point would give a list of jars and other details
curl http://localhost:8983/solr/.system/blob
# GET on the end point with jar name would give details of various versions
of the available jars
curl http://localhost:8983/solr/.system/blob/mycomponent
# GET on the end point with jar name and version with a wt=filestream to get
the actual file
curl http://localhost:8983/solr/.system/blob/mycomponent/1?wt=filestream
mycomponent.1.jar
# GET on the end point with jar name and wt=filestream to get the latest
version of the file
curl http://localhost:8983/solr/.system/blob/mycomponent?wt=filestream
mycomponent.jar
{code}
Please note that the jars are never deleted. a new version is added to the
system everytime a new jar is posted for the name. You must use the standard
delete commands to delete the old entries
--
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-6787) API to manage blobs in Solr
[
https://issues.apache.org/jira/browse/SOLR-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303357#comment-14303357
]
ASF subversion and git services commented on SOLR-6787:
---
Commit 1656748 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1656748 ]
SOLR-6787: .system collection create fails if /configs dir is not present in ZK
API to manage blobs in Solr
Key: SOLR-6787
URL: https://issues.apache.org/jira/browse/SOLR-6787
Project: Solr
Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0, Trunk
Attachments: SOLR-6787.patch, SOLR-6787.patch
A special collection called .system needs to be created by the user to
store/manage blobs. The schema/solrconfig of that collection need to be
automatically supplied by the system so that there are no errors
APIs need to be created to manage the content of that collection
{code}
#create your .system collection first
http://localhost:8983/solr/admin/collections?action=CREATEname=.systemreplicationFactor=2
#The config for this collection is automatically created . numShards for this
collection is hardcoded to 1
#create a new jar or add a new version of a jar
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@mycomponent.jar http://localhost:8983/solr/.system/blob/mycomponent
# GET on the end point would give a list of jars and other details
curl http://localhost:8983/solr/.system/blob
# GET on the end point with jar name would give details of various versions
of the available jars
curl http://localhost:8983/solr/.system/blob/mycomponent
# GET on the end point with jar name and version with a wt=filestream to get
the actual file
curl http://localhost:8983/solr/.system/blob/mycomponent/1?wt=filestream
mycomponent.1.jar
# GET on the end point with jar name and wt=filestream to get the latest
version of the file
curl http://localhost:8983/solr/.system/blob/mycomponent?wt=filestream
mycomponent.jar
{code}
Please note that the jars are never deleted. a new version is added to the
system everytime a new jar is posted for the name. You must use the standard
delete commands to delete the old entries
--
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-2907) java.lang.IllegalArgumentException: deltaQuery has no column to resolve to declared primary key pk='ITEM_ID, CATEGORY_ID'
[
https://issues.apache.org/jira/browse/SOLR-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303404#comment-14303404
]
sunil jadhav commented on SOLR-2907:
Thanks Mate. You saved my DAY. Your suggestion did worked after spending almost
6 hours on figuring out the resolution
java.lang.IllegalArgumentException: deltaQuery has no column to resolve to
declared primary key pk='ITEM_ID, CATEGORY_ID'
-
Key: SOLR-2907
URL: https://issues.apache.org/jira/browse/SOLR-2907
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler, Schema and Analysis
Affects Versions: 3.4
Reporter: Alan Baker
We are using solr for our site and ran into this error in our own schema and
I was able to reproduce it using the dataimport example code in the solr
project. We do not get this error in SOLR 1.4 only started seeing it as we
are working to upgrade to 3.4.0. It fails when delta-importing linked tables.
Complete trace:
Nov 18, 2011 5:21:02 PM org.apache.solr.handler.dataimport.DataImporter
doDeltaImport
SEVERE: Delta Import Failed
java.lang.IllegalArgumentException: deltaQuery has no column to resolve to
declared primary key pk='ITEM_ID, CATEGORY_ID'
at
org.apache.solr.handler.dataimport.DocBuilder.findMatchingPkColumn(DocBuilder.java:849)
at
org.apache.solr.handler.dataimport.DocBuilder.collectDelta(DocBuilder.java:900)
at
org.apache.solr.handler.dataimport.DocBuilder.collectDelta(DocBuilder.java:879)
at
org.apache.solr.handler.dataimport.DocBuilder.doDelta(DocBuilder.java:285)
at
org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:179)
at
org.apache.solr.handler.dataimport.DataImporter.doDeltaImport(DataImporter.java:390)
at
org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:429)
at
org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:408)
I used this dataConfig from the wiki on the data import:
dataConfig
dataSource driver=org.hsqldb.jdbcDriver
url=jdbc:hsqldb:./example-DIH/hsqldb/ex user=sa /
document
entity name=item pk=ID
query=select * from item
deltaImportQuery=select * from item where
ID=='${dataimporter.delta.id}'
deltaQuery=select id from item where last_modified gt;
'${dataimporter.last_index_time}'
entity name=item_category pk=ITEM_ID, CATEGORY_ID
query=select CATEGORY_ID from item_category where
ITEM_ID='${item.ID}'
deltaQuery=select ITEM_ID, CATEGORY_ID from
item_category where last_modified '${dataimporter.last_index_time}'
parentDeltaQuery=select ID from item where
ID=${item_category.ITEM_ID}
entity name=category pk=ID
query=select DESCRIPTION as cat from category where
ID = '${item_category.CATEGORY_ID}'
deltaQuery=select ID from category where
last_modified gt; '${dataimporter.last_index_time}'
parentDeltaQuery=select ITEM_ID, CATEGORY_ID from
item_category where CATEGORY_ID=${category.ID}/
/entity
/entity
/document
/dataConfig
To reproduce use the data config from above and set the dataimport.properties
last update times to before the last_modifed date in the example data. I my
case I had to set the year to 1969. Then run a delta-import and the
exception occurs. Thanks.
--
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-6919) Log REST info before executing
[ https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303412#comment-14303412 ] Mark Miller commented on SOLR-6919: --- bq. FWIW, I only see one other debug statement in SolrCore trunk, and it's in an unexpected situation. So I don't think this is high priority. I'm not really worried about the situation today, I'm worried about it tomorrow. Debug is a developers tool and can be put in tight loops or pretty much anywhere - SolrCore is a very large class - doing it this way seems like, okay, it's fine this release, SolrCore does not currently have a lot of debug logging, but it could make it useless on a upgrade, or even essentially cause a bug on upgrade as all of a sudden you start pumping out a ton of debug logging and have performance issues, flood your log, etc. You don't really want to turn on debug logging for Solrcore - you want to turn on pre logging of the query. Log REST info before executing -- Key: SOLR-6919 URL: https://issues.apache.org/jira/browse/SOLR-6919 Project: Solr Issue Type: Improvement Components: search Reporter: Mike Drob Assignee: Gregory Chanan Priority: Minor Fix For: Trunk, 5.1 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch We should log request info (path, parameters, etc...) before attempting to execute a query. This is helpful in cases where we get a bad query that causes OOM or something else catastrophic, and are doing post-event triage. -- 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-6937) In schemaless mode ,replace spaces and special characters in field names with underscore
[
https://issues.apache.org/jira/browse/SOLR-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-6937:
-
Fix Version/s: 5.1
5.0
In schemaless mode ,replace spaces and special characters in field names with
underscore
Key: SOLR-6937
URL: https://issues.apache.org/jira/browse/SOLR-6937
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Reporter: Grant Ingersoll
Assignee: Noble Paul
Fix For: 5.0, Trunk, 5.1
Attachments: SOLR-6937.patch, SOLR-6937.patch
Assuming spaces in field names are still bad, we should automatically convert
them to not have spaces. For instance, I indexed Citibike public data set
which has:
{quote}
tripduration,starttime,stoptime,start station id,start station
name,start station latitude,start station longitude,end station
id,end station name,end station latitude,end station
longitude,bikeid,usertype,birth year,gender{quote}
My vote would be to replace spaces w/ underscores.
--
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-1782) stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued fields
[ https://issues.apache.org/jira/browse/SOLR-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-1782. Resolution: Won't Fix Fix Version/s: 5.0 I'm marking this as resolved:won't fix since SOLR-6351 has provided an alternative solution that works better and supports more options then stats.facet ever did. stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued fields - Key: SOLR-1782 URL: https://issues.apache.org/jira/browse/SOLR-1782 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.4 Environment: reproduced on Win2k3 using 1.5.0-dev solr ($Id: CHANGES.txt 906924 2010-02-05 12:43:11Z noble $) Reporter: Gerald DeConto Assignee: Hoss Man Fix For: 5.0 Attachments: SOLR-1782.2.patch, SOLR-1782.2013-01-07.patch, SOLR-1782.2013-04-10.patch, SOLR-1782.patch, SOLR-1782.patch, SOLR-1782.patch, SOLR-1782.solr-4.2.1.patch, SOLR-1782.test.patch, index.rar the StatsComponent assumes any field specified in the stats.facet param can be faceted using FieldCache.DEFAULT.getStringIndex. This can cause problems with a variety of field types, but in the case of multivalued fields it can either cause erroneous false stats when the number of distinct values is small, or it can cause ArrayIndexOutOfBoundsException when the number of distinct values is greater then the number of documents. -- 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] [Reopened] (SOLR-6952) Re-using data-driven configsets by default is not helpful
[
https://issues.apache.org/jira/browse/SOLR-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reopened SOLR-6952:
--
This has broken the blob store API
The schema and config are automatically created by the system for .system
collection
There should be a way to create a colection without creating a configset
{code}
bin/solr create -c .system -n .system
{code}
Re-using data-driven configsets by default is not helpful
-
Key: SOLR-6952
URL: https://issues.apache.org/jira/browse/SOLR-6952
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 5.0
Reporter: Grant Ingersoll
Assignee: Timothy Potter
Fix For: 5.0, Trunk
Attachments: SOLR-6952.patch, SOLR-6952.patch
When creating collections (I'm using the bin/solr scripts), I think we should
automatically copy configsets, especially when running in getting started
mode or data driven mode.
I did the following:
{code}
bin/solr create_collection -n foo
bin/post foo some_data.csv
{code}
I then created a second collection with the intention of sending in the same
data, but this time run through a python script that changed a value from an
int to a string (since it was an enumerated type) and was surprised to see
that I got:
{quote}
Caused by: java.lang.NumberFormatException: For input string: NA
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Long.parseLong(Long.java:441)
{quote}
for my new version of the data that passes in a string instead of an int, as
this new collection had only seen strings for that field.
--
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-6217) IndexWriter should make it clear when tragedy strikes
[ https://issues.apache.org/jira/browse/LUCENE-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304102#comment-14304102 ] Ryan Ernst commented on LUCENE-6217: bq. Maybe we could instead throw a new exception (IWClosedByTragedy or something) +1 IndexWriter should make it clear when tragedy strikes - Key: LUCENE-6217 URL: https://issues.apache.org/jira/browse/LUCENE-6217 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless If you hit an exception at a bad time e.g. when writing files for a newly flushed segment, IndexWriter declares it a tragedy and secretly closes itself as a side effect of the exception. Subsequent operations will throw an ACE with the exception that caused the tragedy as its cause. This requires messy code, if you want to know when this happened to you, since the first exception doesn't make it clear that it was tragic. I think we should make it easier to know when this happens? Maybe we could instead throw a new exception (IWClosedByTragedy or something), or maybe we add a getter (.getTragicException) to IW? -- 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-6217) IndexWriter should make it clear when tragedy strikes
[ https://issues.apache.org/jira/browse/LUCENE-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304110#comment-14304110 ] Robert Muir commented on LUCENE-6217: - I would rather have the getter than confusingly change exception types. we shouldn't make this more complicated than it already is: you cannot recover from this situation anyway. IndexWriter should make it clear when tragedy strikes - Key: LUCENE-6217 URL: https://issues.apache.org/jira/browse/LUCENE-6217 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless If you hit an exception at a bad time e.g. when writing files for a newly flushed segment, IndexWriter declares it a tragedy and secretly closes itself as a side effect of the exception. Subsequent operations will throw an ACE with the exception that caused the tragedy as its cause. This requires messy code, if you want to know when this happened to you, since the first exception doesn't make it clear that it was tragic. I think we should make it easier to know when this happens? Maybe we could instead throw a new exception (IWClosedByTragedy or something), or maybe we add a getter (.getTragicException) to IW? -- 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-7071) SolrCore init failure handling preempts SolrCloud's failover support.
Mark Miller created SOLR-7071: - Summary: SolrCore init failure handling preempts SolrCloud's failover support. Key: SOLR-7071 URL: https://issues.apache.org/jira/browse/SOLR-7071 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller If you are using a load balancer or direct querying and one of your replicas and load a core for some reason (init failure due to index corruption or bad config or whatever), if a query for a collection hit's that node, it won't get proxied to another node for good failover - you will get an error returned about the init failure. -- 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-6832) Queries be served locally rather than being forwarded to another replica
[ https://issues.apache.org/jira/browse/SOLR-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304149#comment-14304149 ] Sachin Goyal commented on SOLR-6832: Oh great. Thanks for saving me a search for the ZkController :) Queries be served locally rather than being forwarded to another replica Key: SOLR-6832 URL: https://issues.apache.org/jira/browse/SOLR-6832 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10.2 Reporter: Sachin Goyal Assignee: Timothy Potter Attachments: SOLR-6832.patch Currently, I see that code flow for a query in SolrCloud is as follows: For distributed query: SolrCore - SearchHandler.handleRequestBody() - HttpShardHandler.submit() For non-distributed query: SolrCore - SearchHandler.handleRequestBody() - QueryComponent.process() \\ \\ \\ For a distributed query, the request is always sent to all the shards even if the originating SolrCore (handling the original distributed query) is a replica of one of the shards. If the original Solr-Core can check itself before sending http requests for any shard, we can probably save some network hopping and gain some performance. \\ \\ We can change SearchHandler.handleRequestBody() or HttpShardHandler.submit() to fix this behavior (most likely the former and not the latter). -- 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-7071) SolrCore init failure handling preempts SolrCloud's failover support.
[ https://issues.apache.org/jira/browse/SOLR-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-7071: -- Description: If you are using a load balancer or direct querying and one of your replicas can't load a core for some reason (init failure due to index corruption or bad config or whatever), if a query for a collection hit's that node, it won't get proxied to another node for good failover - you will get an error returned about the init failure. (was: If you are using a load balancer or direct querying and one of your replicas and load a core for some reason (init failure due to index corruption or bad config or whatever), if a query for a collection hit's that node, it won't get proxied to another node for good failover - you will get an error returned about the init failure. ) SolrCore init failure handling preempts SolrCloud's failover support. - Key: SOLR-7071 URL: https://issues.apache.org/jira/browse/SOLR-7071 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller If you are using a load balancer or direct querying and one of your replicas can't load a core for some reason (init failure due to index corruption or bad config or whatever), if a query for a collection hit's that node, it won't get proxied to another node for good failover - you will get an error returned about the init failure. -- 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-NightlyTests-5.x - Build # 752 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/752/ 5 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionTest.test Error Message: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:44424/c8n_1x2_shard1_replica2 Stack Trace: org.apache.solr.client.solrj.SolrServerException: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:44424/c8n_1x2_shard1_replica2 at __randomizedtesting.SeedInfo.seed([C34D9A8EFC4CA1CE:4B19A55452B0CC36]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:575) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:787) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730) at org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484) at org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501) at org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193) at org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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] [Comment Edited] (SOLR-6919) Log REST info before executing
[
https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303515#comment-14303515
]
Mike Drob edited comment on SOLR-6919 at 2/3/15 4:20 PM:
-
I checked out {{IndexWriter}} and {{InfoStream}} and think it might be somewhat
overengineered for this case.
How about we just create a child logger and use that? Then it will inherit the
default levels and settings from the SolrCore logger, or can be set separately
if desired. I've attached another patch with this if we think this is a good
path to go.
was (Author: mdrob):
I checked out {IndexWriter}} and {{InfoStream}} and think it might be somewhat
overengineered for this case.
How about we just create a child logger and use that? Then it will inherit the
default levels and settings from the SolrCore logger, or can be set separately
if desired. I've attached another patch with this if we think this is a good
path to go.
Log REST info before executing
--
Key: SOLR-6919
URL: https://issues.apache.org/jira/browse/SOLR-6919
Project: Solr
Issue Type: Improvement
Components: search
Reporter: Mike Drob
Assignee: Gregory Chanan
Priority: Minor
Fix For: Trunk, 5.1
Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch,
SOLR-6919.patch
We should log request info (path, parameters, etc...) before attempting to
execute a query. This is helpful in cases where we get a bad query that
causes OOM or something else catastrophic, and are doing post-event triage.
--
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-6919) Log REST info before executing
[ https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303536#comment-14303536 ] Mike Drob commented on SOLR-6919: - bq. Only other note on this topic is that if we do use a special 'child' logger object like this, we should probably add it to the documentation. Do you mean somewhere in the wiki, or is there a good place for this in source control? I'm still learning the layout of everything, so any pointers would be appreciated in this case. Log REST info before executing -- Key: SOLR-6919 URL: https://issues.apache.org/jira/browse/SOLR-6919 Project: Solr Issue Type: Improvement Components: search Reporter: Mike Drob Assignee: Gregory Chanan Priority: Minor Fix For: Trunk, 5.1 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch We should log request info (path, parameters, etc...) before attempting to execute a query. This is helpful in cases where we get a bad query that causes OOM or something else catastrophic, and are doing post-event triage. -- 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-6919) Log REST info before executing
[
https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated SOLR-6919:
Attachment: SOLR-6919.patch
I checked out {IndexWriter}} and {{InfoStream}} and think it might be somewhat
overengineered for this case.
How about we just create a child logger and use that? Then it will inherit the
default levels and settings from the SolrCore logger, or can be set separately
if desired. I've attached another patch with this if we think this is a good
path to go.
Log REST info before executing
--
Key: SOLR-6919
URL: https://issues.apache.org/jira/browse/SOLR-6919
Project: Solr
Issue Type: Improvement
Components: search
Reporter: Mike Drob
Assignee: Gregory Chanan
Priority: Minor
Fix For: Trunk, 5.1
Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch,
SOLR-6919.patch
We should log request info (path, parameters, etc...) before attempting to
execute a query. This is helpful in cases where we get a bad query that
causes OOM or something else catastrophic, and are doing post-event triage.
--
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-1782) stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued fields
[ https://issues.apache.org/jira/browse/SOLR-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1782: --- Description: the StatsComponent assumes any field specified in the stats.facet param can be faceted using FieldCache.DEFAULT.getStringIndex. This can cause problems with a variety of field types, but in the case of multivalued fields it can either cause erroneous false stats when the number of distinct values is small, or it can cause ArrayIndexOutOfBoundsException when the number of distinct values is greater then the number of documents. --- New users interested in mixing stats facets are encouraged to ignore the stats.facet param and instead combine stats.field with facet.pivot to achieve similar results more efficiently... https://cwiki.apache.org/confluence/display/solr/The+Stats+Component#TheStatsComponent-TheStatsComponentandFaceting was:the StatsComponent assumes any field specified in the stats.facet param can be faceted using FieldCache.DEFAULT.getStringIndex. This can cause problems with a variety of field types, but in the case of multivalued fields it can either cause erroneous false stats when the number of distinct values is small, or it can cause ArrayIndexOutOfBoundsException when the number of distinct values is greater then the number of documents. stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued fields - Key: SOLR-1782 URL: https://issues.apache.org/jira/browse/SOLR-1782 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.4 Environment: reproduced on Win2k3 using 1.5.0-dev solr ($Id: CHANGES.txt 906924 2010-02-05 12:43:11Z noble $) Reporter: Gerald DeConto Assignee: Hoss Man Fix For: 5.0 Attachments: SOLR-1782.2.patch, SOLR-1782.2013-01-07.patch, SOLR-1782.2013-04-10.patch, SOLR-1782.patch, SOLR-1782.patch, SOLR-1782.patch, SOLR-1782.solr-4.2.1.patch, SOLR-1782.test.patch, index.rar the StatsComponent assumes any field specified in the stats.facet param can be faceted using FieldCache.DEFAULT.getStringIndex. This can cause problems with a variety of field types, but in the case of multivalued fields it can either cause erroneous false stats when the number of distinct values is small, or it can cause ArrayIndexOutOfBoundsException when the number of distinct values is greater then the number of documents. --- New users interested in mixing stats facets are encouraged to ignore the stats.facet param and instead combine stats.field with facet.pivot to achieve similar results more efficiently... https://cwiki.apache.org/confluence/display/solr/The+Stats+Component#TheStatsComponent-TheStatsComponentandFaceting -- 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-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303468#comment-14303468 ] Petar Tahchiev commented on SOLR-3218: -- 4.9.1. is out but this is still open :( Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.9, Trunk Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch, SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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-6919) Log REST info before executing
[ https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303525#comment-14303525 ] Mark Miller commented on SOLR-6919: --- I don't mean to use it's implementation. Just that it's kind of a special logging object and we could make this the same. AFAIK, you can just make a special logger name for this that controls it - like org.apache.solr.queryprelog=DEBUG or whatever. bq. How about we just create a child logger and use that? Looking at the patch, yeah, that's what I meant. I don't know what the right name is, but I think that's right implementation path. Log REST info before executing -- Key: SOLR-6919 URL: https://issues.apache.org/jira/browse/SOLR-6919 Project: Solr Issue Type: Improvement Components: search Reporter: Mike Drob Assignee: Gregory Chanan Priority: Minor Fix For: Trunk, 5.1 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch We should log request info (path, parameters, etc...) before attempting to execute a query. This is helpful in cases where we get a bad query that causes OOM or something else catastrophic, and are doing post-event triage. -- 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-6832) Queries be served locally rather than being forwarded to another replica
[ https://issues.apache.org/jira/browse/SOLR-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter reassigned SOLR-6832: Assignee: Timothy Potter Queries be served locally rather than being forwarded to another replica Key: SOLR-6832 URL: https://issues.apache.org/jira/browse/SOLR-6832 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10.2 Reporter: Sachin Goyal Assignee: Timothy Potter Attachments: SOLR-6832.patch Currently, I see that code flow for a query in SolrCloud is as follows: For distributed query: SolrCore - SearchHandler.handleRequestBody() - HttpShardHandler.submit() For non-distributed query: SolrCore - SearchHandler.handleRequestBody() - QueryComponent.process() \\ \\ \\ For a distributed query, the request is always sent to all the shards even if the originating SolrCore (handling the original distributed query) is a replica of one of the shards. If the original Solr-Core can check itself before sending http requests for any shard, we can probably save some network hopping and gain some performance. \\ \\ We can change SearchHandler.handleRequestBody() or HttpShardHandler.submit() to fix this behavior (most likely the former and not the latter). -- 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-3435) StatsComponents should support all SimpleFacetParameters in its facet parameter
[ https://issues.apache.org/jira/browse/SOLR-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-3435. Resolution: Won't Fix Fix Version/s: 5.0 I'm resolving this as won't fixed since SOLR-6351 has provided an alternative solution that works better and supports more options then stats.facet ever did. StatsComponents should support all SimpleFacetParameters in its facet parameter --- Key: SOLR-3435 URL: https://issues.apache.org/jira/browse/SOLR-3435 Project: Solr Issue Type: Improvement Affects Versions: 4.0-ALPHA Reporter: Mathias H. Labels: statscomponent Fix For: 5.0 StatsComponents _stats.facet_ parameter doesn't support SimpleFacetParameters params like _facet.mincount_, _facet.limit_, etc. Moreover it'll always create Field Value Facets. Range Facets aren't possible. Very useful to calculate the sum of a field for each month/day/etc (using range facets) or to limit the results with facet.limit. -- 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-3435) StatsComponents should support all SimpleFacetParameters in its facet parameter
[ https://issues.apache.org/jira/browse/SOLR-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-3435: --- Description: StatsComponents _stats.facet_ parameter doesn't support SimpleFacetParameters params like _facet.mincount_, _facet.limit_, etc. Moreover it'll always create Field Value Facets. Range Facets aren't possible. Very useful to calculate the sum of a field for each month/day/etc (using range facets) or to limit the results with facet.limit. --- New users interested in mixing stats facets are encouraged to ignore the stats.facet param and instead combine stats.field with facet.pivot to achieve similar results more efficiently... https://cwiki.apache.org/confluence/display/solr/The+Stats+Component#TheStatsComponent-TheStatsComponentandFaceting was: StatsComponents _stats.facet_ parameter doesn't support SimpleFacetParameters params like _facet.mincount_, _facet.limit_, etc. Moreover it'll always create Field Value Facets. Range Facets aren't possible. Very useful to calculate the sum of a field for each month/day/etc (using range facets) or to limit the results with facet.limit. StatsComponents should support all SimpleFacetParameters in its facet parameter --- Key: SOLR-3435 URL: https://issues.apache.org/jira/browse/SOLR-3435 Project: Solr Issue Type: Improvement Affects Versions: 4.0-ALPHA Reporter: Mathias H. Labels: statscomponent Fix For: 5.0 StatsComponents _stats.facet_ parameter doesn't support SimpleFacetParameters params like _facet.mincount_, _facet.limit_, etc. Moreover it'll always create Field Value Facets. Range Facets aren't possible. Very useful to calculate the sum of a field for each month/day/etc (using range facets) or to limit the results with facet.limit. --- New users interested in mixing stats facets are encouraged to ignore the stats.facet param and instead combine stats.field with facet.pivot to achieve similar results more efficiently... https://cwiki.apache.org/confluence/display/solr/The+Stats+Component#TheStatsComponent-TheStatsComponentandFaceting -- 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-6919) Log REST info before executing
[ https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303528#comment-14303528 ] Mark Miller commented on SOLR-6919: --- bq. I checked out IndexWriter and InfoStream and think it might be somewhat overengineered for this case. Just to be clear, those are Lucene specific class for special IndexWriter debug logging. We expose turning that on in Solr with a somewhat special log object. Only other note on this topic is that if we do use a special 'child' logger object like this, we should probably add it to the documentation. Log REST info before executing -- Key: SOLR-6919 URL: https://issues.apache.org/jira/browse/SOLR-6919 Project: Solr Issue Type: Improvement Components: search Reporter: Mike Drob Assignee: Gregory Chanan Priority: Minor Fix For: Trunk, 5.1 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch We should log request info (path, parameters, etc...) before attempting to execute a query. This is helpful in cases where we get a bad query that causes OOM or something else catastrophic, and are doing post-event triage. -- 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-6919) Log REST info before executing
[ https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303541#comment-14303541 ] Mark Miller commented on SOLR-6919: --- The official documentation is now at https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide Contributors can comment, committers can change. Log REST info before executing -- Key: SOLR-6919 URL: https://issues.apache.org/jira/browse/SOLR-6919 Project: Solr Issue Type: Improvement Components: search Reporter: Mike Drob Assignee: Gregory Chanan Priority: Minor Fix For: Trunk, 5.1 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch We should log request info (path, parameters, etc...) before attempting to execute a query. This is helpful in cases where we get a bad query that causes OOM or something else catastrophic, and are doing post-event triage. -- 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-6919) Log REST info before executing
[ https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303573#comment-14303573 ] Mike Drob commented on SOLR-6919: - Great, thanks. Comment made at https://cwiki.apache.org/confluence/display/solr/Configuring+Logging?focusedCommentId=51808825#comment-51808825 Log REST info before executing -- Key: SOLR-6919 URL: https://issues.apache.org/jira/browse/SOLR-6919 Project: Solr Issue Type: Improvement Components: search Reporter: Mike Drob Assignee: Gregory Chanan Priority: Minor Fix For: Trunk, 5.1 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch We should log request info (path, parameters, etc...) before attempting to execute a query. This is helpful in cases where we get a bad query that causes OOM or something else catastrophic, and are doing post-event triage. -- 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-Windows (32bit/jdk1.8.0_31) - Build # 4355 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4355/ Java: 32bit/jdk1.8.0_31 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.lucene.store.TestRateLimiter.testPause Error Message: we should sleep less than 2 seconds but did: 2299 millis Stack Trace: java.lang.AssertionError: we should sleep less than 2 seconds but did: 2299 millis at __randomizedtesting.SeedInfo.seed([1670D9B1ABDB616C:70D09D8F20F6386A]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.store.TestRateLimiter.testPause(TestRateLimiter.java:41) 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:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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) Build Log: [...truncated 850 lines...] [junit4] Suite: org.apache.lucene.store.TestRateLimiter [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestRateLimiter -Dtests.method=testPause -Dtests.seed=1670D9B1ABDB616C -Dtests.slow=true -Dtests.locale=fr_CA -Dtests.timezone=Africa/Brazzaville -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [junit4] FAILURE 1.47s | TestRateLimiter.testPause [junit4] Throwable #1: java.lang.AssertionError: we
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_31) - Build # 4459 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4459/ Java: 32bit/jdk1.8.0_31 -client -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.ReplicationFactorTest.test Error Message: org.apache.http.NoHttpResponseException: The target server failed to respond Stack Trace: org.apache.solr.client.solrj.SolrServerException: org.apache.http.NoHttpResponseException: The target server failed to respond at __randomizedtesting.SeedInfo.seed([C81B6CEB5EA84F56:404F5331F05422AE]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:865) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730) at org.apache.solr.cloud.ReplicationFactorTest.testRf3(ReplicationFactorTest.java:284) at org.apache.solr.cloud.ReplicationFactorTest.test(ReplicationFactorTest.java:112) 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:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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
[jira] [Updated] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful
[ https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-6196: Attachment: (was: geo3d.zip) Include geo3d package, along with Lucene integration to make it useful -- Key: LUCENE-6196 URL: https://issues.apache.org/jira/browse/LUCENE-6196 Project: Lucene - Core Issue Type: New Feature Components: modules/spatial Reporter: Karl Wright Assignee: David Smiley Attachments: ShapeImpl.java, geo3d-tests.zip, geo3d.zip I would like to explore contributing a geo3d package to Lucene. This can be used in conjunction with Lucene search, both for generating geohashes (via spatial4j) for complex geographic shapes, as well as limiting results resulting from those queries to those results within the exact shape in highly performant ways. The package uses 3d planar geometry to do its magic, which basically limits computation necessary to determine membership (once a shape has been initialized, of course) to only multiplications and additions, which makes it feasible to construct a performant BoostSource-based filter for geographic shapes. The math is somewhat more involved when generating geohashes, but is still more than fast enough to do a good job. -- 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] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful
[ https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-6196: Attachment: geo3d.zip Minor cleanups, and reduction of duplicated code... Include geo3d package, along with Lucene integration to make it useful -- Key: LUCENE-6196 URL: https://issues.apache.org/jira/browse/LUCENE-6196 Project: Lucene - Core Issue Type: New Feature Components: modules/spatial Reporter: Karl Wright Assignee: David Smiley Attachments: ShapeImpl.java, geo3d-tests.zip, geo3d.zip I would like to explore contributing a geo3d package to Lucene. This can be used in conjunction with Lucene search, both for generating geohashes (via spatial4j) for complex geographic shapes, as well as limiting results resulting from those queries to those results within the exact shape in highly performant ways. The package uses 3d planar geometry to do its magic, which basically limits computation necessary to determine membership (once a shape has been initialized, of course) to only multiplications and additions, which makes it feasible to construct a performant BoostSource-based filter for geographic shapes. The math is somewhat more involved when generating geohashes, but is still more than fast enough to do a good job. -- 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-5972) new statistics facet capabilities to StatsComponent facet - limit, sort and missing.
[ https://issues.apache.org/jira/browse/SOLR-5972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303217#comment-14303217 ] Elran Dvir commented on SOLR-5972: -- Hi all, This patch contains a new statistics result for a field - existInDoc. It returns the number of documents in which the field has a value (not missing). For multivalue fields there is a calculation of existInDoc inside the class UnInvertedField. Since Solr 4.10 there was a fix for a stats calculation of multi valued field which is doc valued. The class handling it is DocValuesStats. I want to support existInDoc calculation also for multi valued - doc valued field. How Should I change DocValuesStats to support this? Thanks. new statistics facet capabilities to StatsComponent facet - limit, sort and missing. Key: SOLR-5972 URL: https://issues.apache.org/jira/browse/SOLR-5972 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: SOLR-5972.patch, SOLR-5972.patch I thought it would be very useful to enable limiting and sorting StatsComponent facet response. I chose to implement it in Stats Component rather than Analytics component because Analytics doesn't support distributed queries yet. The default for limit is -1 - returns all facet values. The default for sort is no sorting. The default for missing is true. So if you use stats component exactly as before, the response won't change as of nowadays. If ask for sort or limit, missing facet value will be the last, as in regular facet. Sort types supported: min, max, sum and countdistinct for stats fields, and count and index for facet fields (all sort types are lower cased). Sort directions asc and desc are supported. Sorting by multiple fields is supported. our example use case will be employees' monthly salaries: The follwing query returns the 10 most expensive employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary sum descf.employee_name.stats.facet.limit=10 The follwing query returns the 10 least expensive employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary sum ascf.employee_name.stats.facet.limit=10 The follwing query returns the employee that got the highest salary ever: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary max descf.employee_name.stats.facet.limit=1 The follwing query returns the employee that got the lowest salary ever: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary min ascf.employee_name.stats.facet.limit=1 The follwing query returns the 10 first (lexicographically) employees: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=employee_name index ascf.employee_name.stats.facet.limit=10 The follwing query returns the 10 employees that have worked for the longest period: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=employee_name count descf.employee_name.stats.facet.limit=10 The follwing query returns the 10 employee whose salaries vary the most: q=*:*stats=truestats.field=salarystats.facet=employee_namef.employee_name.stats.facet.sort=salary countdistinct descf.employee_name.stats.facet.limit=10 Attached a patch implementing this in StatsComponent. -- 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-6937) In schemaless mode ,replace spaces and special characters in field names with underscore
[
https://issues.apache.org/jira/browse/SOLR-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-6937:
-
Summary: In schemaless mode ,replace spaces and special characters in field
names with underscore (was: In schemaless mode ,replace spaces and special
characters with underscore)
In schemaless mode ,replace spaces and special characters in field names with
underscore
Key: SOLR-6937
URL: https://issues.apache.org/jira/browse/SOLR-6937
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Reporter: Grant Ingersoll
Assignee: Noble Paul
Fix For: Trunk
Attachments: SOLR-6937.patch, SOLR-6937.patch
Assuming spaces in field names are still bad, we should automatically convert
them to not have spaces. For instance, I indexed Citibike public data set
which has:
{quote}
tripduration,starttime,stoptime,start station id,start station
name,start station latitude,start station longitude,end station
id,end station name,end station latitude,end station
longitude,bikeid,usertype,birth year,gender{quote}
My vote would be to replace spaces w/ underscores.
--
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-6216) Make it easier to modify Japanese token attributes downstream
[
https://issues.apache.org/jira/browse/LUCENE-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303308#comment-14303308
]
Robert Muir commented on LUCENE-6216:
-
I think we can do it without a performance hit. The last time I benchmarked,
the current loading was fairly important to e.g. a simple analyzer, because
some attributes like reading are a fair number of bytes per character to
process.
its not really lazy loading, but decodes from the dictionary on every single
request. So maybe we should just make it lazy loaded?
Instead of:
{code}
String getPartOfSpeech() {
return token == null ? null : token.getPartOfSpeech();
}
{code}
add a setPartOfSpeech() and have the code work something like this, so its just
caches but can be changed:
{code}
if (pos == null) {
if (token != null) {
pos = token.getPartOfSpeech();
}
}
return pos;
{code}
The disadvantage would be any semantics around 'null', but there are other ways
to implement the same idea.
Make it easier to modify Japanese token attributes downstream
-
Key: LUCENE-6216
URL: https://issues.apache.org/jira/browse/LUCENE-6216
Project: Lucene - Core
Issue Type: Improvement
Components: modules/analysis
Reporter: Christian Moen
Priority: Minor
Japanese-specific token attributes such as {{PartOfSpeechAttribute}},
{{BaseFormAttribute}}, etc. get their values from a
{{org.apache.lucene.analysis.ja.Token}} through a {{setToken()}} method.
This makes it cumbersome to change these token attributes later on in the
analysis chain since the {{Token}} instances are difficult to instantiate
(sort of read-only objects).
I've ran into this issue in LUCENE-3922 (JapaneseNumberFilter) where it would
be appropriate to update token attributes to also reflect Japanese number
normalization.
I think it might be more practical to allow setting a specific value for
these token attributes directly rather than through a {{Token}} since it
makes the APIs simpler, allows for easier changing attributes downstream, and
also supporting additional dictionaries easier.
The drawback with the approach that I can think of is a performance hit as we
will miss out on the inherent lazy retrieval of these token attributes from
the {{Token}} object (and the underlying dictionary/buffer).
I'd like to do some testing to better understand the performance impact of
this change. Happy to hear your thoughts on 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] [Created] (SOLR-7070) Issue when using fl with dynamic filelds without setting wilcards
Khalid Galal created SOLR-7070: -- Summary: Issue when using fl with dynamic filelds without setting wilcards Key: SOLR-7070 URL: https://issues.apache.org/jira/browse/SOLR-7070 Project: Solr Issue Type: Bug Affects Versions: 4.10.3 Reporter: Khalid Galal Fix For: 4.6 Issue when using fl with dynamic fields without setting wildcards, such as: In solr 4.6, I used to select dynamic fields by exact match, e.g. the below query used to work with me: fl=123_PART But in solr 4.10.3, the above query doesn't work any more, so I am forced to use a wildcards, such as to be begin with match, e.g. the below query: fl=*_PART The above query works but returns all dynamic fields that end with _PART, and that results in bad performance as our dynamic fields are stored. Is there any way to be able to select a dynamic field exactly like in version 4.6? -- 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-6919) Log REST info before executing
[ https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated SOLR-6919: Attachment: SOLR-6919.patch Attaching a new patch that is built on top of the content that [~gchanan] already committed. Log REST info before executing -- Key: SOLR-6919 URL: https://issues.apache.org/jira/browse/SOLR-6919 Project: Solr Issue Type: Improvement Components: search Reporter: Mike Drob Assignee: Gregory Chanan Priority: Minor Fix For: Trunk, 5.1 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch We should log request info (path, parameters, etc...) before attempting to execute a query. This is helpful in cases where we get a bad query that causes OOM or something else catastrophic, and are doing post-event triage. -- 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 # 2580 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2580/ 5 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionTest.test Error Message: org.apache.http.NoHttpResponseException: The target server failed to respond Stack Trace: org.apache.solr.client.solrj.SolrServerException: org.apache.http.NoHttpResponseException: The target server failed to respond at __randomizedtesting.SeedInfo.seed([B3BB3B605D6829A2:3BEF04BAF394445A]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:865) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730) at org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484) at org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501) at org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193) at org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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
[jira] [Commented] (SOLR-6919) Log REST info before executing
[ https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303642#comment-14303642 ] Mark Miller commented on SOLR-6919: --- Awesome, thanks, looks great. I think we have to wait till the 5.0 guide is out before putting it in. Log REST info before executing -- Key: SOLR-6919 URL: https://issues.apache.org/jira/browse/SOLR-6919 Project: Solr Issue Type: Improvement Components: search Reporter: Mike Drob Assignee: Gregory Chanan Priority: Minor Fix For: Trunk, 5.1 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch We should log request info (path, parameters, etc...) before attempting to execute a query. This is helpful in cases where we get a bad query that causes OOM or something else catastrophic, and are doing post-event triage. -- 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-7005) facet.heatmap for spatial heatmap faceting on RPT
[
https://issues.apache.org/jira/browse/SOLR-7005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303651#comment-14303651
]
Hoss Man commented on SOLR-7005:
bq. I'm confused about FacetComponent.distributedProcess() line ~215 (removal
of faceting types when distribFieldFacetRefinements != null). Chris Hostetter
Which faceting types should be removed here; why is it just facet.field and
facet.query; maybe the others should too?
I'm confused to. (admitedly i haven't looked at it very hard today)
I suspect this code is just really old, from the back when only facet.field
facet.query existed. I suspect that at that point in time, the idea was:
1) remove *every* the facet.field params, because we're about loop over the
ones we know still need refinment and add them
2) remove *any* facet.query, because they never need refined
You'll note that a few lines down ~233 there is a similar block of code
relating to facet.pivot facet.pivot.mincount -- aparently for the same
reasons as #1 above.
bq. ...Which faceting types should be removed here; why is it just facet.field
and facet.query; maybe the others should too?
i suspect it's safe/efficient to remove all the facet params up front, and let
the various types of faceting re-add the params they need if/when they need
refined? ... but i'm not certain about that.
the thing to do is setup a simple cluster where the field terms are vastly diff
between two shards (to force refinement) and then look at what distributed
refinement requests are sent to each shard when combining multiple types of
faceting -- make sure that a facet.field + facet.range + facet.query +
facet.pivot + facet.heatmap that requires refinement on the facet.field doesn't
unneccessarily re-request the same facet.range + facet.query + facet.pivot +
facet.heatmap if they don't also need refinement.
facet.heatmap for spatial heatmap faceting on RPT
-
Key: SOLR-7005
URL: https://issues.apache.org/jira/browse/SOLR-7005
Project: Solr
Issue Type: New Feature
Components: spatial
Reporter: David Smiley
Assignee: David Smiley
Fix For: 5.1
Attachments: SOLR-7005_heatmap.patch, SOLR-7005_heatmap.patch,
SOLR-7005_heatmap.patch, heatmap_512x256.png, heatmap_64x32.png
This is a new feature that uses the new spatial Heatmap / 2D PrefixTree cell
counter in Lucene spatial LUCENE-6191. This is a form of faceting, and
as-such I think it should live in the facet parameter namespace. Here's
what the parameters are:
* facet=true
* facet.heatmap=fieldname
* facet.heatmap.bbox=\[-180 -90 TO 180 90]
* facet.heatmap.gridLevel=6
* facet.heatmap.distErrPct=0.10
Like other faceting features, the fieldName can have local-params to exclude
filter queries or specify an output key.
The bbox is optional; you get the whole world or you can specify a box or
actually any shape that WKT supports (you get the bounding box of whatever
you put).
Ultimately, this feature needs to know the grid level, which together with
the input shape will yield a certain number of cells. You can specify
gridLevel exactly, or don't and instead provide distErrPct which is computed
like it is for the RPT field type as seen in the schema. 0.10 yielded ~4k
cells but it'll vary. There's also a facet.heatmap.maxCells safety net
defaulting to 100k. Exceed this and you get an error.
The output is (JSON):
{noformat}
{gridLevel=6,columns=64,rows=64,minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0,counts=[[0,
0, 2, 1, ],[1, 1, 3, 2, ...],...]}
{noformat}
counts is null if all would be 0. Perhaps individual row arrays should
likewise be null... I welcome feedback.
I'm toying with an output format option in which you can specify a base-64'ed
grayscale PNG.
Obviously this should support sharded / distributed environments.
--
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-6919) Log REST info before executing
[ https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated SOLR-6919: Attachment: SOLR-6919.patch bq. should the slow query log also go to the request log? I can see an argument made for this, but I don't think it is necessary. bq. if you are generating this on top of what is already committed why does the test case look like a new file? I'm not sure, I must have made a mistake somewhere. Here's a new patch that looks correct w.r.t. the test case. Log REST info before executing -- Key: SOLR-6919 URL: https://issues.apache.org/jira/browse/SOLR-6919 Project: Solr Issue Type: Improvement Components: search Reporter: Mike Drob Assignee: Gregory Chanan Priority: Minor Fix For: Trunk, 5.1 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch We should log request info (path, parameters, etc...) before attempting to execute a query. This is helpful in cases where we get a bad query that causes OOM or something else catastrophic, and are doing post-event triage. -- 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-SmokeRelease-5.0 - Build # 23 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.0/23/ No tests ran. Build Log: [...truncated 51651 lines...] prepare-release-no-sign: [mkdir] Created dir: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist [copy] Copying 446 files to /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 245 files to /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7 [smoker] NOTE: output encoding is US-ASCII [smoker] [smoker] Load release URL file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist/... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.1 MB in 0.04 sec (3.5 MB/sec) [smoker] check changes HTML... [smoker] download lucene-5.0.0-src.tgz... [smoker] 27.9 MB in 0.04 sec (671.0 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-5.0.0.tgz... [smoker] 64.0 MB in 0.17 sec (381.4 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-5.0.0.zip... [smoker] 73.5 MB in 0.14 sec (533.3 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-5.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.7... [smoker] got 5645 hits for query lucene [smoker] checkindex with 1.7... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-5.0.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.7... [smoker] got 5645 hits for query lucene [smoker] checkindex with 1.7... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-5.0.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run ant validate [smoker] run tests w/ Java 7 and testArgs='-Dtests.jettyConnector=Socket -Dtests.multiplier=1 -Dtests.slow=false'... [smoker] test demo with 1.7... [smoker] got 207 hits for query lucene [smoker] checkindex with 1.7... [smoker] generate javadocs w/ Java 7... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] confirm all releases have coverage in TestBackwardsCompatibility [smoker] find all past Lucene releases... [smoker] run TestBackwardsCompatibility.. [smoker] success! [smoker] [smoker] Test Solr... [smoker] test basics... [smoker] get KEYS [smoker] 0.1 MB in 0.00 sec (85.3 MB/sec) [smoker] check changes HTML... [smoker] download solr-5.0.0-src.tgz... [smoker] 34.9 MB in 0.06 sec (622.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-5.0.0.tgz... [smoker] 121.9 MB in 0.23 sec (531.5 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-5.0.0.zip... [smoker] 128.1 MB in 0.14 sec (921.7 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-5.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-5.0.0.tgz... [smoker] **WARNING**: skipping check of /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/tmp/unpack/solr-5.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/tmp/unpack/solr-5.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] verify WAR metadata/contained JAR identity/no javax.* or java.* classes... [smoker] unpack lucene-5.0.0.tgz... [smoker] copying unpacked distribution for Java 7 ... [smoker] test solr example w/ Java 7... [smoker] start Solr instance (log=/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/tmp/unpack/solr-5.0.0-java7/solr-example.log)... [smoker] No process found for Solr node running on port 8983 [smoker] starting Solr on port 8983 from /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/tmp/unpack/solr-5.0.0-java7 [smoker] startup done [smoker] [smoker] Setup new core instance directory: [smoker] /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/tmp/unpack/solr-5.0.0-java7/server/solr/techproducts [smoker] [smoker] Creating new core 'techproducts' using command: [smoker]
Re: [CI] Lucene 5x Linux Java8 64 Test Only - Build # 28739 - Failure!
These assert trips won't reproduce for me, under beasting, same Java version, G1GC ... Mike McCandless http://blog.mikemccandless.com On Tue, Feb 3, 2015 at 2:10 PM, bu...@elasticsearch.com wrote: *BUILD FAILURE* Build URL http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28739/ Project:lucene_linux_java8_64_test_only Date of build:Tue, 03 Feb 2015 20:08:25 +0100 Build duration:2 min 25 sec *CHANGES* No Changes *BUILD ARTIFACTS* checkout/lucene/build/core/test/temp/junit4-J0-20150203_200828_615.events http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28739/artifact/checkout/lucene/build/core/test/temp/junit4-J0-20150203_200828_615.events checkout/lucene/build/core/test/temp/junit4-J1-20150203_200828_615.events http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28739/artifact/checkout/lucene/build/core/test/temp/junit4-J1-20150203_200828_615.events checkout/lucene/build/core/test/temp/junit4-J2-20150203_200828_616.events http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28739/artifact/checkout/lucene/build/core/test/temp/junit4-J2-20150203_200828_616.events checkout/lucene/build/core/test/temp/junit4-J3-20150203_200828_616.events http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28739/artifact/checkout/lucene/build/core/test/temp/junit4-J3-20150203_200828_616.events checkout/lucene/build/core/test/temp/junit4-J4-20150203_200828_616.events http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28739/artifact/checkout/lucene/build/core/test/temp/junit4-J4-20150203_200828_616.events checkout/lucene/build/core/test/temp/junit4-J5-20150203_200828_617.events http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28739/artifact/checkout/lucene/build/core/test/temp/junit4-J5-20150203_200828_617.events checkout/lucene/build/core/test/temp/junit4-J6-20150203_200828_618.events http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28739/artifact/checkout/lucene/build/core/test/temp/junit4-J6-20150203_200828_618.events checkout/lucene/build/core/test/temp/junit4-J7-20150203_200828_618.events http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28739/artifact/checkout/lucene/build/core/test/temp/junit4-J7-20150203_200828_618.events *FAILED JUNIT TESTS* Name: org.apache.lucene.index Failed: 1 test(s), Passed: 746 test(s), Skipped: 19 test(s), Total: 766 test(s) *Failed: org.apache.lucene.index.TestFlushByRamOrCountsPolicy.testStallControl * *CONSOLE OUTPUT* [...truncated 1566 lines...] [junit4] [junit4] Tests with failures: [junit4] - org.apache.lucene.index.TestFlushByRamOrCountsPolicy.testStallControl [junit4] [junit4] [junit4] JVM J0: 1.29 .. 131.01 = 129.72s [junit4] JVM J1: 1.03 .. 129.65 = 128.62s [junit4] JVM J2: 1.02 .. 130.41 = 129.39s [junit4] JVM J3: 1.27 .. 129.46 = 128.19s [junit4] JVM J4: 1.02 .. 129.33 = 128.31s [junit4] JVM J5: 1.04 .. 129.15 = 128.11s [junit4] JVM J6: 1.02 .. 129.19 = 128.16s [junit4] JVM J7: 0.79 .. 129.16 = 128.37s [junit4] Execution time total: 2 minutes 11 seconds [junit4] Tests summary: 409 suites, 3238 tests, 1 error, 62 ignored (52 assumptions) BUILD FAILED /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:49: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1363: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:970: There were test failures: 409 suites, 3238 tests, 1 error, 62 ignored (52 assumptions) Total time: 2 minutes 18 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - 1st Trigger Failure - Any was overridden by another trigger and will not send an email. Trigger Failure - Still was overridden by another trigger and will not send an email. Sending email for trigger: Failure - 1st
[jira] [Commented] (SOLR-6919) Log REST info before executing
[ https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303815#comment-14303815 ] Gregory Chanan commented on SOLR-6919: -- should the slow query log also go to the request log? if you are generating this on top of what is already committed why does the test case look like a new file? Log REST info before executing -- Key: SOLR-6919 URL: https://issues.apache.org/jira/browse/SOLR-6919 Project: Solr Issue Type: Improvement Components: search Reporter: Mike Drob Assignee: Gregory Chanan Priority: Minor Fix For: Trunk, 5.1 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch We should log request info (path, parameters, etc...) before attempting to execute a query. This is helpful in cases where we get a bad query that causes OOM or something else catastrophic, and are doing post-event triage. -- 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-Windows (32bit/jdk1.7.0_76) - Build # 4356 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4356/ Java: 32bit/jdk1.7.0_76 -client -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.ReplicationFactorTest.test Error Message: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:63723/repfacttest_c8n_1x3_shard1_replica2 Stack Trace: org.apache.solr.client.solrj.SolrServerException: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:63723/repfacttest_c8n_1x3_shard1_replica2 at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:575) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:787) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730) at org.apache.solr.cloud.ReplicationFactorTest.testRf3(ReplicationFactorTest.java:283) at org.apache.solr.cloud.ReplicationFactorTest.test(ReplicationFactorTest.java:112) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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
[jira] [Commented] (SOLR-5379) Query-time multi-word synonym expansion
[ https://issues.apache.org/jira/browse/SOLR-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304161#comment-14304161 ] Otis Gospodnetic commented on SOLR-5379: bq. I am sure there is, but there are no working patches for 4.10 or 5.x thus far. Right. What I was trying to ask is whether any of the active Solr committers wants to commit this. If there is no will to commit, I'd rather keep things simple on our end ignore this issue. But there is a will to commit, I'd love to see this in Solr, as would 30+ other watchers, I imagine. Query-time multi-word synonym expansion --- Key: SOLR-5379 URL: https://issues.apache.org/jira/browse/SOLR-5379 Project: Solr Issue Type: Improvement Components: query parsers Reporter: Tien Nguyen Manh Labels: multi-word, queryparser, synonym Fix For: 4.9, Trunk Attachments: conf-test-files-4_8_1.patch, quoted-4_8_1.patch, quoted.patch, synonym-expander-4_8_1.patch, synonym-expander.patch While dealing with synonym at query time, solr failed to work with multi-word synonyms due to some reasons: - First the lucene queryparser tokenizes user query by space so it split multi-word term into two terms before feeding to synonym filter, so synonym filter can't recognized multi-word term to do expansion - Second, if synonym filter expand into multiple terms which contains multi-word synonym, The SolrQueryParseBase currently use MultiPhraseQuery to handle synonyms. But MultiPhraseQuery don't work with term have different number of words. For the first one, we can extend quoted all multi-word synonym in user query so that lucene queryparser don't split it. There are a jira task related to this one https://issues.apache.org/jira/browse/LUCENE-2605. For the second, we can replace MultiPhraseQuery by an appropriate BoleanQuery SHOULD which contains multiple PhraseQuery in case tokens stream have multi-word synonym. -- 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-6832) Queries be served locally rather than being forwarded to another replica
[
https://issues.apache.org/jira/browse/SOLR-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sachin Goyal updated SOLR-6832:
---
Attachment: SOLR-6832.patch
[~thelabdude], here is a new patch with the above comments incorporated.
I have checked that
{code:java}req.getCore().getCoreDescriptor().getCoreContainer().getZkController().getBaseUrl(){code}
works well and so {code}ResponseBuilder. findCurrentHostAddress(){code} is no
longer required.
Configuration change is also done.
Queries be served locally rather than being forwarded to another replica
Key: SOLR-6832
URL: https://issues.apache.org/jira/browse/SOLR-6832
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.10.2
Reporter: Sachin Goyal
Assignee: Timothy Potter
Attachments: SOLR-6832.patch, SOLR-6832.patch
Currently, I see that code flow for a query in SolrCloud is as follows:
For distributed query:
SolrCore - SearchHandler.handleRequestBody() - HttpShardHandler.submit()
For non-distributed query:
SolrCore - SearchHandler.handleRequestBody() - QueryComponent.process()
\\
\\
\\
For a distributed query, the request is always sent to all the shards even if
the originating SolrCore (handling the original distributed query) is a
replica of one of the shards.
If the original Solr-Core can check itself before sending http requests for
any shard, we can probably save some network hopping and gain some
performance.
\\
\\
We can change SearchHandler.handleRequestBody() or HttpShardHandler.submit()
to fix this behavior (most likely the former and not the latter).
--
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 # 2581 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2581/ 1 tests failed. REGRESSION: org.apache.lucene.analysis.uima.UIMABaseAnalyzerTest.testRandomStrings Error Message: some thread(s) failed Stack Trace: java.lang.RuntimeException: some thread(s) failed at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:531) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:428) at org.apache.lucene.analysis.uima.UIMABaseAnalyzerTest.testRandomStrings(UIMABaseAnalyzerTest.java:122) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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) Build Log: [...truncated 3661 lines...] [junit4] Suite: org.apache.lucene.analysis.uima.UIMABaseAnalyzerTest [junit4] 2 2 03, 2015 1:08:21 ?? WhitespaceTokenizer initialize [junit4] 2 ??: Whitespace tokenizer successfully initialized [junit4] 2 2 03, 2015 1:08:21 ?? WhitespaceTokenizer typeSystemInit [junit4] 2 ??: Whitespace tokenizer typesystem initialized [junit4] 2 2 03, 2015 1:08:21 ?? WhitespaceTokenizer process [junit4] 2 ??: Whitespace tokenizer starts
[jira] [Commented] (SOLR-7070) Issue when using fl with dynamic filelds without setting wilcards
[
https://issues.apache.org/jira/browse/SOLR-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303990#comment-14303990
]
Hoss Man commented on SOLR-7070:
Can you please provide more details about your schema, your request URLs, and
the exact behavior you are seeing?
I just used Solr 4.10.3 along with the default example...
{noformat}
bin/solr start -e default
cd example/exampledocs/
java -jar post.jar *.xml
{noformat}
and had no problem getting fl to work with a field name generated from a
dynamicField...
{noformat}
curl
'http://localhost:8983/solr/select?q=manu:belkinfl=manu_id_swt=jsonindent=true'
{
responseHeader:{
status:0,
QTime:1,
params:{
fl:manu_id_s,
indent:true,
q:manu:belkin,
wt:json}},
response:{numFound:2,start:0,docs:[
{
manu_id_s:belkin},
{
manu_id_s:belkin}]
}}
{noformat}
Issue when using fl with dynamic filelds without setting wilcards
---
Key: SOLR-7070
URL: https://issues.apache.org/jira/browse/SOLR-7070
Project: Solr
Issue Type: Bug
Affects Versions: 4.10.3
Reporter: Khalid Galal
Labels: dynamic, fields
Fix For: 4.6
Issue when using fl with dynamic fields without setting wildcards, such as:
In solr 4.6, I used to select dynamic fields by exact match, e.g. the below
query used to work with me:
fl=123_PART
But in solr 4.10.3, the above query doesn't work any more, so I am forced to
use a wildcards, such as to be begin with match, e.g. the below query:
fl=*_PART
The above query works but returns all dynamic fields that end with _PART,
and that results in bad performance as our dynamic fields are stored.
Is there any way to be able to select a dynamic field exactly like in version
4.6?
--
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_31) - Build # 4460 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4460/ Java: 64bit/jdk1.8.0_31 -XX:+UseCompressedOops -XX:+UseParallelGC 2 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\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010\collection1\conf\params.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-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\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-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\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010\collection1\conf\params.json: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-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\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010\collection1\conf: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010\collection1\conf C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010\collection1 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001\tempDir-010 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler 4A38993A093C42A8-001: java.nio.file.DirectoryNotEmptyException:
[jira] [Commented] (SOLR-6832) Queries be served locally rather than being forwarded to another replica
[
https://issues.apache.org/jira/browse/SOLR-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303922#comment-14303922
]
Timothy Potter commented on SOLR-6832:
--
[~sachingoyal] Thanks for the patch! I'm working to get it to a committable
state.
I don't think adding {{preferLocalShards}} as a collection-level setting (in
SolrConfig) adds much value here. If an operator wants to enforce that query
parameter for all requests, they can use the built-in support for defaults or
invariants on the appropriate query request handler, e.g. to make this the
default on the /select handler, you could do:
{code}
requestHandler name=/select class=solr.SearchHandler
lst name=defaults
str name=echoParamsexplicit/str
int name=rows10/int
bool name=preferLocalShardstrue/bool
...
{code}
Both approaches require some config changes in solrconfig.xml, but the latter
(my suggestion) avoids adding new code / config settings. That said, please let
me know if you think there's another reason to have this as an explicit setting
in solrconfig.xml.
Also, all the code in {{findCurrentHostAddress}} can simply be replaced by
{{ZkController.getBaseUrl()}} when needed.
Queries be served locally rather than being forwarded to another replica
Key: SOLR-6832
URL: https://issues.apache.org/jira/browse/SOLR-6832
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.10.2
Reporter: Sachin Goyal
Assignee: Timothy Potter
Attachments: SOLR-6832.patch
Currently, I see that code flow for a query in SolrCloud is as follows:
For distributed query:
SolrCore - SearchHandler.handleRequestBody() - HttpShardHandler.submit()
For non-distributed query:
SolrCore - SearchHandler.handleRequestBody() - QueryComponent.process()
\\
\\
\\
For a distributed query, the request is always sent to all the shards even if
the originating SolrCore (handling the original distributed query) is a
replica of one of the shards.
If the original Solr-Core can check itself before sending http requests for
any shard, we can probably save some network hopping and gain some
performance.
\\
\\
We can change SearchHandler.handleRequestBody() or HttpShardHandler.submit()
to fix this behavior (most likely the former and not the latter).
--
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] (LUCENE-6216) Make it easier to modify Japanese token attributes downstream
Christian Moen created LUCENE-6216:
--
Summary: Make it easier to modify Japanese token attributes
downstream
Key: LUCENE-6216
URL: https://issues.apache.org/jira/browse/LUCENE-6216
Project: Lucene - Core
Issue Type: Improvement
Components: modules/analysis
Reporter: Christian Moen
Priority: Minor
Japanese-specific token attributes such as {{PartOfSpeechAttribute}},
{{BaseFormAttribute}}, etc. get their values from a
{{org.apache.lucene.analysis.ja.Token}} through a {{setToken()}} method. This
makes it cumbersome to change these token attributes later on in the analysis
chain since the {{Token}} instances are difficult to instantiate (sort of
read-only objects).
I've ran into this issue in LUCENE-3922 (JapaneseNumberFilter) where it would
be appropriate to update token attributes to also reflect Japanese number
normalization.
I think it might be more practical to allow setting a specific value for these
token attributes directly rather than through a {{Token}} since it makes the
APIs simpler, allows for easier changing attributes downstream, and also
supporting additional dictionaries easier.
The drawback with the approach that I can think of is a performance hit as we
will miss out on the inherent lazy retrieval of these token attributes from the
{{Token}} object (and the underlying dictionary/buffer).
I'd like to do some testing to better understand the performance impact of this
change. Happy to hear your thoughts on 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] [Commented] (SOLR-5379) Query-time multi-word synonym expansion
[ https://issues.apache.org/jira/browse/SOLR-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303081#comment-14303081 ] Markus Jelsma commented on SOLR-5379: - I am sure there is, but there are no working patches for 4.10 or 5.x thus far. Query-time multi-word synonym expansion --- Key: SOLR-5379 URL: https://issues.apache.org/jira/browse/SOLR-5379 Project: Solr Issue Type: Improvement Components: query parsers Reporter: Tien Nguyen Manh Labels: multi-word, queryparser, synonym Fix For: 4.9, Trunk Attachments: conf-test-files-4_8_1.patch, quoted-4_8_1.patch, quoted.patch, synonym-expander-4_8_1.patch, synonym-expander.patch While dealing with synonym at query time, solr failed to work with multi-word synonyms due to some reasons: - First the lucene queryparser tokenizes user query by space so it split multi-word term into two terms before feeding to synonym filter, so synonym filter can't recognized multi-word term to do expansion - Second, if synonym filter expand into multiple terms which contains multi-word synonym, The SolrQueryParseBase currently use MultiPhraseQuery to handle synonyms. But MultiPhraseQuery don't work with term have different number of words. For the first one, we can extend quoted all multi-word synonym in user query so that lucene queryparser don't split it. There are a jira task related to this one https://issues.apache.org/jira/browse/LUCENE-2605. For the second, we can replace MultiPhraseQuery by an appropriate BoleanQuery SHOULD which contains multiple PhraseQuery in case tokens stream have multi-word synonym. -- 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: Why would test timeout not kick in...?
Just in case anyone else needs this: It's actually -XX:SelfDestructTimer=30 See http://stas-blogspot.blogspot.de/2011/07/most-complete-list-of-xx-options-for.html#SelfDestructTimer Regards Christoph Kaser Am 30.01.2015 um 15:37 schrieb Michael McCandless: Thanks Uwe Dawid, next time I'll try try to SIGHUP it. I never knew about this -DSelfDestructTime=30! Mike McCandless http://blog.mikemccandless.com On Mon, Jan 26, 2015 at 3:21 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: If you encounter a situation like this, please stack dump the hung JVM, ok? (send a SIGHUP signal to it). If you can't provoke the JVM to dump its stack then it's very likely a JVM error. Otherwise I'll have something to debug. An alternative solution to force-kill a forked JVM (Oracle only) is to pass the magic switch to it: -DSelfDestructTimer=30 The number is in minutes; from JDK sources: product(intx, SelfDestructTimer, 0, \ Will cause VM to terminate after a given time (in minutes) \ (0 means off)) Dawid On Mon, Jan 26, 2015 at 8:42 PM, Uwe Schindler u...@thetaphi.de wrote: Hi, This happens in most cases under OOM situations. In that case the test runner loses control and is unable to shut down. In this case it could be something different, because you still see a test method in the hearbeat. On OOM situations in most cases you see just the test case name and no method. We have that quite often with Solr tests on Policeman Jenkins, too. If you want to be sure that a build is aborted, you can also set a maximum timeout for the whole build in Jenkins. Jenkins will then kill -9 the whole process structure it launched. Please note that Jenkins measures the whole build time, so give enough buffer. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Monday, January 26, 2015 7:10 PM To: Lucene/Solr dev Subject: Why would test timeout not kick in...? This test (TestCompressingTermVectorsFormat.testClone) just kept HEARTBEAT-ing for 2 days: http://build-eu- 00.elasticsearch.org/job/lucene_linux_java8_64_test_only/26953/console The test class / super classes are not annotated with longer timeouts ... Shouldn't it have timed out at 7200 seconds? Mike McCandless http://blog.mikemccandless.com - 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 - 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 -- Dipl.-Inf. Christoph Kaser IconParc GmbH Sophienstrasse 1 80333 München www.iconparc.de Tel +49 -89- 15 90 06 - 21 Fax +49 -89- 15 90 06 - 49 Geschäftsleitung: Dipl.-Ing. Roland Brückner, Dipl.-Inf. Sven Angerer. HRB 121830, Amtsgericht München - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3922) Add Japanese Kanji number normalization to Kuromoji
[ https://issues.apache.org/jira/browse/LUCENE-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Moen updated LUCENE-3922: --- Attachment: LUCENE-3922.patch Minor updates to javadoc. I'll leave reading attributes, etc. unchanged for now and get back to resolving this once we have better mechanisms in place for updating some of the Japanese token attributes downstream. Add Japanese Kanji number normalization to Kuromoji --- Key: LUCENE-3922 URL: https://issues.apache.org/jira/browse/LUCENE-3922 Project: Lucene - Core Issue Type: New Feature Components: modules/analysis Affects Versions: 4.0-ALPHA Reporter: Kazuaki Hiraga Assignee: Christian Moen Labels: features Fix For: 5.1 Attachments: LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch Japanese people use Kanji numerals instead of Arabic numerals for writing price, address and so on. i.e 12万4800円(124,800JPY), 二番町三ノ二(3-2 Nibancho) and 十二月(December). So, we would like to normalize those Kanji numerals to Arabic numerals (I don't think we need to have a capability to normalize to Kanji numerals). -- 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-3922) Add Japanese Kanji number normalization to Kuromoji
[ https://issues.apache.org/jira/browse/LUCENE-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303062#comment-14303062 ] ASF subversion and git services commented on LUCENE-3922: - Commit 1656670 from [~cm] in branch 'dev/trunk' [ https://svn.apache.org/r1656670 ] Added JapaneseNumberFilter (LUCENE-3922) Add Japanese Kanji number normalization to Kuromoji --- Key: LUCENE-3922 URL: https://issues.apache.org/jira/browse/LUCENE-3922 Project: Lucene - Core Issue Type: New Feature Components: modules/analysis Affects Versions: 4.0-ALPHA Reporter: Kazuaki Hiraga Assignee: Christian Moen Labels: features Fix For: 5.1 Attachments: LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch Japanese people use Kanji numerals instead of Arabic numerals for writing price, address and so on. i.e 12万4800円(124,800JPY), 二番町三ノ二(3-2 Nibancho) and 十二月(December). So, we would like to normalize those Kanji numerals to Arabic numerals (I don't think we need to have a capability to normalize to Kanji numerals). -- 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-5379) Query-time multi-word synonym expansion
[
https://issues.apache.org/jira/browse/SOLR-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304336#comment-14304336
]
Jan Høydahl commented on SOLR-5379:
---
+1 to get some of this in. I have the desire but not the cycles right now.
Perhaps your happy customer could help drive this?
Just looked briefly at the patches.. *disclaimer: I did not apply and test this
yet*
* I would expect a ton of new unit tests for {{synonym-expander.patch}} but
cannot find?
* Why create another subclass of ExtendedDismax for this? If going into core,
fold the features into edismax? The patch will be smaller too.
* I cannot see a test for configuring custom {{synonymAnalyzers}}. Also, it
should refer to schema fieldTypes instead of adding to qparser config - in the
same way e.g. Suggesters do
Probably the work could be split up - first add more test coverage to the
{{synonym-expander}} part and commit it. Then fold the quoting-stuff into
standard edismax and commit (this part is less risky since it is back-compat if
you don't use the new params).
Is [~tiennm] still around? Other users ot the patch who are willing to step in
and improve it?
Query-time multi-word synonym expansion
---
Key: SOLR-5379
URL: https://issues.apache.org/jira/browse/SOLR-5379
Project: Solr
Issue Type: Improvement
Components: query parsers
Reporter: Tien Nguyen Manh
Labels: multi-word, queryparser, synonym
Fix For: 4.9, Trunk
Attachments: conf-test-files-4_8_1.patch, quoted-4_8_1.patch,
quoted.patch, synonym-expander-4_8_1.patch, synonym-expander.patch
While dealing with synonym at query time, solr failed to work with multi-word
synonyms due to some reasons:
- First the lucene queryparser tokenizes user query by space so it split
multi-word term into two terms before feeding to synonym filter, so synonym
filter can't recognized multi-word term to do expansion
- Second, if synonym filter expand into multiple terms which contains
multi-word synonym, The SolrQueryParseBase currently use MultiPhraseQuery to
handle synonyms. But MultiPhraseQuery don't work with term have different
number of words.
For the first one, we can extend quoted all multi-word synonym in user query
so that lucene queryparser don't split it. There are a jira task related to
this one https://issues.apache.org/jira/browse/LUCENE-2605.
For the second, we can replace MultiPhraseQuery by an appropriate BoleanQuery
SHOULD which contains multiple PhraseQuery in case tokens stream have
multi-word synonym.
--
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-6216) Make it easier to modify Japanese token attributes downstream
[
https://issues.apache.org/jira/browse/LUCENE-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304342#comment-14304342
]
Christian Moen commented on LUCENE-6216:
Thanks, Robert.
I had the same idea and I tried this out last night. The advantage of the
approach is that we only read the buffer data for the token attributes we use,
but it leaves the API a bit slightly awkward in my opinion since we would have
both a {{setToken()}} and a {{setPartOfSpeech()}}. That said, this is still
perhaps the best way to go for performance reasons and these APIs being very
low-level and not commonly used.
For the sake of exploring an alternative idea; a different approach could be to
have separate token filters set these attributes. The tokenizer would set a
{{CharTermAttribute}}, etc. and a {{JapaneseTokenAttribute}} (or something
suitably named) that holds the {{Token}}. A separate
{{JapanesePartOfSpeechFilter}} would be responsible for setting the
{{PartOfSpeechAttribute}} by getting the data from the
{{JapaneseTokenAttribute}} using a {{getToken()}} method. We'd still need logic
similar to the above to deal with {{setPartOfSpeech()}}, etc. so I don't think
we gain anything by taking this approach, and it's a big change, too.
Make it easier to modify Japanese token attributes downstream
-
Key: LUCENE-6216
URL: https://issues.apache.org/jira/browse/LUCENE-6216
Project: Lucene - Core
Issue Type: Improvement
Components: modules/analysis
Reporter: Christian Moen
Priority: Minor
Japanese-specific token attributes such as {{PartOfSpeechAttribute}},
{{BaseFormAttribute}}, etc. get their values from a
{{org.apache.lucene.analysis.ja.Token}} through a {{setToken()}} method.
This makes it cumbersome to change these token attributes later on in the
analysis chain since the {{Token}} instances are difficult to instantiate
(sort of read-only objects).
I've ran into this issue in LUCENE-3922 (JapaneseNumberFilter) where it would
be appropriate to update token attributes to also reflect Japanese number
normalization.
I think it might be more practical to allow setting a specific value for
these token attributes directly rather than through a {{Token}} since it
makes the APIs simpler, allows for easier changing attributes downstream, and
also supporting additional dictionaries easier.
The drawback with the approach that I can think of is a performance hit as we
will miss out on the inherent lazy retrieval of these token attributes from
the {{Token}} object (and the underlying dictionary/buffer).
I'd like to do some testing to better understand the performance impact of
this change. Happy to hear your thoughts on 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
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2582 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2582/ 5 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionTest.test Error Message: org.apache.http.NoHttpResponseException: The target server failed to respond Stack Trace: org.apache.solr.client.solrj.SolrServerException: org.apache.http.NoHttpResponseException: The target server failed to respond at __randomizedtesting.SeedInfo.seed([E2CC0EA7682EE78A:6A98317DC6D28A72]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:865) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730) at org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484) at org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501) at org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193) at org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2578 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2578/ 6 tests failed. REGRESSION: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test Error Message: shard1 is not consistent. Got 136 from http://127.0.0.1:41409/collection1lastClient and got 110 from http://127.0.0.1:41430/collection1 Stack Trace: java.lang.AssertionError: shard1 is not consistent. Got 136 from http://127.0.0.1:41409/collection1lastClient and got 110 from http://127.0.0.1:41430/collection1 at __randomizedtesting.SeedInfo.seed([B088F3516467E676:38DCCC8BCA9B8B8E]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1246) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1225) at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:159) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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
[jira] [Resolved] (SOLR-5147) Support child documents in DIH
[ https://issues.apache.org/jira/browse/SOLR-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-5147. -- Resolution: Fixed Support child documents in DIH -- Key: SOLR-5147 URL: https://issues.apache.org/jira/browse/SOLR-5147 Project: Solr Issue Type: Sub-task Reporter: Vadim Kirilchuk Assignee: Noble Paul Fix For: Trunk, 5.1 Attachments: SOLR-5147-5x.patch, SOLR-5147.patch, SOLR-5147.patch, dih-oome-fix.patch DIH should be able to index hierarchical documents, i.e. it should be able to work with SolrInputDocuments#addChildDocument. There was patch in SOLR-3076: https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch But it is not uptodate and far from being complete. -- 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: [CI] Lucene Linux Java 8 64 Test Only - Build # 28585 - Failure!
TestScorerPerf.testConjunctions timed out @ 2 hours ... but this does not repro for me standalone, nor with master seed, using G1GC. The test runs very quickly... Mike McCandless http://blog.mikemccandless.com On Tue, Feb 3, 2015 at 3:07 AM, bu...@elasticsearch.com wrote: *BUILD FAILURE* Build URL http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/ Project:lucene_trunk_linux_java8_64_test_only Date of build:Tue, 03 Feb 2015 07:06:18 +0100 Build duration:2 hr 0 min *CHANGES* No Changes *BUILD ARTIFACTS* checkout/lucene/build/core/test/temp/junit4-J0-20150203_070621_306.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J0-20150203_070621_306.events checkout/lucene/build/core/test/temp/junit4-J1-20150203_070621_307.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J1-20150203_070621_307.events checkout/lucene/build/core/test/temp/junit4-J2-20150203_070621_307.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J2-20150203_070621_307.events checkout/lucene/build/core/test/temp/junit4-J3-20150203_070621_320.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J3-20150203_070621_320.events checkout/lucene/build/core/test/temp/junit4-J4-20150203_070621_318.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J4-20150203_070621_318.events checkout/lucene/build/core/test/temp/junit4-J5-20150203_070621_318.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J5-20150203_070621_318.events checkout/lucene/build/core/test/temp/junit4-J6-20150203_070621_320.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J6-20150203_070621_320.events checkout/lucene/build/core/test/temp/junit4-J7-20150203_070621_324.events http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J7-20150203_070621_324.events *FAILED JUNIT TESTS* Name: junit.framework Failed: 1 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 1 test(s) *Failed: junit.framework.TestSuite.org.apache.lucene.search.TestScorerPerf * Name: org.apache.lucene.search Failed: 1 test(s), Passed: 702 test(s), Skipped: 5 test(s), Total: 708 test(s) *Failed: org.apache.lucene.search.TestScorerPerf.testConjunctions * *CONSOLE OUTPUT* [...truncated 1847 lines...] [junit4] Tests with failures: [junit4] - org.apache.lucene.search.TestScorerPerf.testConjunctions [junit4] - org.apache.lucene.search.TestScorerPerf (suite) [junit4] [junit4] [junit4] JVM J0: 1.18 .. 134.63 = 133.45s [junit4] JVM J1: 0.89 .. 128.01 = 127.13s [junit4] JVM J2: 1.08 .. 129.33 = 128.24s [junit4] JVM J3: 1.13 .. 7243.77 = 7242.65s [junit4] JVM J4: 0.88 .. 125.94 = 125.06s [junit4] JVM J5: 1.08 .. 127.14 = 126.06s [junit4] JVM J6: 1.33 .. 127.70 = 126.37s [junit4] JVM J7: 1.08 .. 127.75 = 126.68s [junit4] Execution time total: 2 hours 43 seconds [junit4] Tests summary: 409 suites, 3241 tests, 1 suite-level error, 1 error, 113 ignored (50 assumptions) BUILD FAILED /home/jenkins/workspace/lucene_trunk_linux_java8_64_test_only/checkout/lucene/build.xml:49: The following error occurred while executing this line: /home/jenkins/workspace/lucene_trunk_linux_java8_64_test_only/checkout/lucene/common-build.xml:1348: The following error occurred while executing this line: /home/jenkins/workspace/lucene_trunk_linux_java8_64_test_only/checkout/lucene/common-build.xml:956: There were test failures: 409 suites, 3241 tests, 1 suite-level error, 1 error, 113 ignored (50 assumptions) Total time: 120 minutes 51 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - 1st Trigger Failure - Any was overridden by another trigger and will not send an email. Trigger Failure - Still was overridden by another trigger and will not send an email. Sending email for trigger: Failure - 1st
Re: [CI] Lucene Linux Java 8 64 Test Only - Build # 28585 - Failure!
There is nothing special in the events file (just a stall before timeout).
It is suspicious where it reports the thread to be at the timeout time:
[junit4] 2 jstack at approximately timeout time
[junit4] 2
TEST-TestScorerPerf.testConjunctions-seed#[675750BB099F7976] ID=176
RUNNABLE
[junit4] 2at
org.apache.lucene.search.Query.toString(Query.java:70)
[junit4] 2at java.lang.String.valueOf(String.java:2981)
It seems impossible to me (it'd be inside the toString(String) of a
subclass?).
public String toString() {
70:return toString();
}
Dawid
On Tue, Feb 3, 2015 at 10:30 AM, Michael McCandless m...@elasticsearch.com
wrote:
TestScorerPerf.testConjunctions timed out @ 2 hours ... but this does not
repro for me standalone, nor with master seed, using G1GC. The test runs
very quickly...
Mike McCandless
http://blog.mikemccandless.com
On Tue, Feb 3, 2015 at 3:07 AM, bu...@elasticsearch.com wrote:
*BUILD FAILURE*
Build URL
http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/
Project:lucene_trunk_linux_java8_64_test_only Date of build:Tue, 03 Feb
2015 07:06:18 +0100 Build duration:2 hr 0 min
*CHANGES* No Changes
*BUILD ARTIFACTS*
checkout/lucene/build/core/test/temp/junit4-J0-20150203_070621_306.events
http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J0-20150203_070621_306.events
checkout/lucene/build/core/test/temp/junit4-J1-20150203_070621_307.events
http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J1-20150203_070621_307.events
checkout/lucene/build/core/test/temp/junit4-J2-20150203_070621_307.events
http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J2-20150203_070621_307.events
checkout/lucene/build/core/test/temp/junit4-J3-20150203_070621_320.events
http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J3-20150203_070621_320.events
checkout/lucene/build/core/test/temp/junit4-J4-20150203_070621_318.events
http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J4-20150203_070621_318.events
checkout/lucene/build/core/test/temp/junit4-J5-20150203_070621_318.events
http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J5-20150203_070621_318.events
checkout/lucene/build/core/test/temp/junit4-J6-20150203_070621_320.events
http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J6-20150203_070621_320.events
checkout/lucene/build/core/test/temp/junit4-J7-20150203_070621_324.events
http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_test_only/28585/artifact/checkout/lucene/build/core/test/temp/junit4-J7-20150203_070621_324.events
*FAILED JUNIT TESTS* Name: junit.framework Failed: 1 test(s), Passed: 0
test(s), Skipped: 0 test(s), Total: 1 test(s)
*Failed:
junit.framework.TestSuite.org.apache.lucene.search.TestScorerPerf * Name:
org.apache.lucene.search Failed: 1 test(s), Passed: 702 test(s), Skipped: 5
test(s), Total: 708 test(s)
*Failed: org.apache.lucene.search.TestScorerPerf.testConjunctions *
*CONSOLE OUTPUT* [...truncated 1847 lines...] [junit4] Tests with
failures: [junit4] -
org.apache.lucene.search.TestScorerPerf.testConjunctions [junit4] -
org.apache.lucene.search.TestScorerPerf (suite) [junit4] [junit4]
[junit4] JVM J0: 1.18 .. 134.63 = 133.45s [junit4] JVM J1: 0.89 ..
128.01 = 127.13s [junit4] JVM J2: 1.08 .. 129.33 = 128.24s [junit4] JVM
J3: 1.13 .. 7243.77 = 7242.65s [junit4] JVM J4: 0.88 .. 125.94 = 125.06s
[junit4]
JVM J5: 1.08 .. 127.14 = 126.06s [junit4] JVM J6: 1.33 .. 127.70 =
126.37s [junit4] JVM J7: 1.08 .. 127.75 = 126.68s [junit4] Execution
time total: 2 hours 43 seconds [junit4] Tests summary: 409 suites, 3241
tests, 1 suite-level error, 1 error, 113 ignored (50 assumptions) BUILD
FAILED
/home/jenkins/workspace/lucene_trunk_linux_java8_64_test_only/checkout/lucene/build.xml:49:
The following error occurred while executing this line:
/home/jenkins/workspace/lucene_trunk_linux_java8_64_test_only/checkout/lucene/common-build.xml:1348:
The following error occurred while executing this line:
/home/jenkins/workspace/lucene_trunk_linux_java8_64_test_only/checkout/lucene/common-build.xml:956:
There were test failures: 409 suites, 3241 tests, 1 suite-level error, 1
error, 113 ignored (50 assumptions) Total time: 120 minutes 51 seconds Build
step 'Invoke Ant' marked build as failure Archiving artifacts Recording
test results Email was
[jira] [Commented] (SOLR-7061) Cross-Entity Variable Resolving and Arguments for ScriptTransformer Functions
[
https://issues.apache.org/jira/browse/SOLR-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303038#comment-14303038
]
Noble Paul commented on SOLR-7061:
--
bq.We want to cache as minimum data as possible for each function. ContextImpl
uses a HashMapString, Object to store document-level data in DocWrapper for
all entities, no matter if they will be used by any function or not, which may
cache unnecessary values in memory.
I fail to understand this fully. Th context only stores the values you
explicitly set. So where are the unnecessary values coming from?
Cross-Entity Variable Resolving and Arguments for ScriptTransformer Functions
-
Key: SOLR-7061
URL: https://issues.apache.org/jira/browse/SOLR-7061
Project: Solr
Issue Type: Improvement
Components: contrib - DataImportHandler
Affects Versions: 4.10.3
Reporter: Mark Peng
Priority: Minor
Labels: dataimport, transformers
Attachments: SOLR-7061.patch
Script Transformer has been widely used to modify the value of columns of
selected rows from targeting data source (such as SQL Database) based on
specific logics, before writing to Solr as documents. However, current
implementation has the following limitations:
*1. It is not possible to pass constant values or resolved variables (e.g.,
$\{TABLE.COLUMN\} ) as arguments to a script function.*
*2. Cross-entity row data exchange is not possible as well.*
In our use case, we have complex nested entities and rely heavily on the
script functions to transform table rows while doing data import. Sometimes
for each single document, we need to get the selected column values from a
parent entity into current entity for doing value transformation and applying
if-else logics. To achieve this, we need to join with others tables in the
SQL of current entity, which is quite resource-consuming, especially for
large tables.
Therefore, we have done some improvements to allow us to pass selected column
values from entity A to another entity B as its function arguments by
utilizing variable resolver.
Here is an example about how it works. Suppose we have the following
configuration:
{code}
dataConfig
dataSource name=ProductDB
driver=oracle.jdbc.driver.OracleDriver
url=jdbc:oracle:thin:@${dataimporter.request.host}:
${dataimporter.request.port}/${dataimporter.request.name}
user=${dataimporter.request.user}
password=${dataimporter.request.password}
autoCommit=true/
!-- ScriptTransformer functions --
script![CDATA[
function processItemRow(row, resolvedVars) {
var isOnSale = resolvedVars.get(${PRODUCT.IS_ONSALE});
var discount = resolvedVars.get(${PRODUCT.DISCOUNT_RATE});
var price = row.get(PRICE);
if(isOnSale) {
row.put(PRICE, price * discount);
}
else
row.put(PRICE, price);
return row;
}
]]
/script
document name=EC_SHOP
entity dataSource=ProductDB name=PRODUCT
query=SELECT PRODUCT_ID, TITLE, IS_ONSALE, DISCOUNT_RATE
FROM PRODUCT
field column=PRODUCT_ID name=PRODUCT_ID/
field column=TITLE name=TITLE/
field column=IS_ONSALE name=IS_ONSALE/
field column=DISCOUNT_RATE name=DISCOUNT_RATE/
entity dataSource=ProductDB name=ITEM
transformer=script:processItemRow(${PRODUCT.IS_ONSALE},${PRODUCT.DISCOUNT_RATE})
query=SELECT PRICE FROM ITEM WHERE PRODUCT_ID =
'${PRODUCT.PRODUCT_ID}'
field column=PRICE name=PRICE/
/entity
/entity
/document
/dataConfig
{code}
As demonstrated above, now we can get access to the value of column
*IS_ONSALE* and *DISCOUNT_RATE* of table *PRODUCT* from the entity of table
*ITEM* by passing *$\{PRODUCT.IS_ONSALE\}* and *$\{PRODUCT.DISCOUNT_RATE\}*
as arguments of the function *processItemRow* to determine if we should give
some discounts for the production price. The signature of function has a
secondary argument (named *resolvedVars* here) for passing the map of column
values resolved from other previous entities.
This improvement gives more flexibility for script functions to exchange row
data cross entities (even cross datasource) and do more complex processing
for entity rows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail:
[jira] [Commented] (SOLR-6832) Queries be served locally rather than being forwarded to another replica
[
https://issues.apache.org/jira/browse/SOLR-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304033#comment-14304033
]
Timothy Potter commented on SOLR-6832:
--
Awesome - btw ... in case you haven't seen this before, it's a little
cumbersome to get at the ZkController from the req object, something like:
{code}
req.getCore().getCoreDescriptor().getCoreContainer().getZkController().getBaseUrl()
{code}
Queries be served locally rather than being forwarded to another replica
Key: SOLR-6832
URL: https://issues.apache.org/jira/browse/SOLR-6832
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.10.2
Reporter: Sachin Goyal
Assignee: Timothy Potter
Attachments: SOLR-6832.patch
Currently, I see that code flow for a query in SolrCloud is as follows:
For distributed query:
SolrCore - SearchHandler.handleRequestBody() - HttpShardHandler.submit()
For non-distributed query:
SolrCore - SearchHandler.handleRequestBody() - QueryComponent.process()
\\
\\
\\
For a distributed query, the request is always sent to all the shards even if
the originating SolrCore (handling the original distributed query) is a
replica of one of the shards.
If the original Solr-Core can check itself before sending http requests for
any shard, we can probably save some network hopping and gain some
performance.
\\
\\
We can change SearchHandler.handleRequestBody() or HttpShardHandler.submit()
to fix this behavior (most likely the former and not the latter).
--
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-6832) Queries be served locally rather than being forwarded to another replica
[ https://issues.apache.org/jira/browse/SOLR-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304014#comment-14304014 ] Sachin Goyal commented on SOLR-6832: [~thelabdude], I do not feel very strongly about the configuration option in solrconfig.xml I kept it here only because specifying a global option looked simpler to use. I will try the ZkController.getBaseUrl() and update the patch shortly with the above suggestions. Thank you for reviewing. Queries be served locally rather than being forwarded to another replica Key: SOLR-6832 URL: https://issues.apache.org/jira/browse/SOLR-6832 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10.2 Reporter: Sachin Goyal Assignee: Timothy Potter Attachments: SOLR-6832.patch Currently, I see that code flow for a query in SolrCloud is as follows: For distributed query: SolrCore - SearchHandler.handleRequestBody() - HttpShardHandler.submit() For non-distributed query: SolrCore - SearchHandler.handleRequestBody() - QueryComponent.process() \\ \\ \\ For a distributed query, the request is always sent to all the shards even if the originating SolrCore (handling the original distributed query) is a replica of one of the shards. If the original Solr-Core can check itself before sending http requests for any shard, we can probably save some network hopping and gain some performance. \\ \\ We can change SearchHandler.handleRequestBody() or HttpShardHandler.submit() to fix this behavior (most likely the former and not the latter). -- 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] (LUCENE-6217) IndexWriter should make it clear when tragedy strikes
Michael McCandless created LUCENE-6217: -- Summary: IndexWriter should make it clear when tragedy strikes Key: LUCENE-6217 URL: https://issues.apache.org/jira/browse/LUCENE-6217 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless If you hit an exception at a bad time e.g. when writing files for a newly flushed segment, IndexWriter declares it a tragedy and secretly closes itself as a side effect of the exception. Subsequent operations will throw an ACE with the exception that caused the tragedy as its cause. This requires messy code, if you want to know when this happened to you, since the first exception doesn't make it clear that it was tragic. I think we should make it easier to know when this happens? Maybe we could instead throw a new exception (IWClosedByTragedy or something), or maybe we add a getter (.getTragicException) to IW? -- 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 # 1971 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1971/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 3 tests failed. FAILED: org.apache.solr.cloud.ReplicationFactorTest.test Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([EBDE05C83D3A332A]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ReplicationFactorTest Error Message: Suite timeout exceeded (= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (= 720 msec). at __randomizedtesting.SeedInfo.seed([EBDE05C83D3A332A]:0) FAILED: org.apache.solr.cloud.TestRebalanceLeaders.test Error Message: No live SolrServers available to handle this request:[https://127.0.0.1:50445/ws_rk, https://127.0.0.1:50448/ws_rk, https://127.0.0.1:50451/ws_rk, https://127.0.0.1:50441/ws_rk, https://127.0.0.1:50454/ws_rk] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:50445/ws_rk, https://127.0.0.1:50448/ws_rk, https://127.0.0.1:50451/ws_rk, https://127.0.0.1:50441/ws_rk, https://127.0.0.1:50454/ws_rk] at __randomizedtesting.SeedInfo.seed([EBDE05C83D3A332A:638A3A1293C65ED2]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:349) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1009) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:787) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730) at org.apache.solr.cloud.TestRebalanceLeaders.issueCommands(TestRebalanceLeaders.java:280) at org.apache.solr.cloud.TestRebalanceLeaders.rebalanceLeaderTest(TestRebalanceLeaders.java:107) at org.apache.solr.cloud.TestRebalanceLeaders.test(TestRebalanceLeaders.java:73) 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:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at
[jira] [Commented] (LUCENE-6216) Make it easier to modify Japanese token attributes downstream
[
https://issues.apache.org/jira/browse/LUCENE-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304479#comment-14304479
]
Robert Muir commented on LUCENE-6216:
-
Yeah for the second idea, i guess my main concern is that it surfaces what
should be an implementation detail up to the user. It has some practical
challenges too, e.g. today if you have just a simple JapaneseTokenizer-only
chain, you can see e.g. POS and so on when debugging. But with the alternate
approach, you'd have to modify your analysis chain to see everything.
It doesn't mean the current approach is the way it should be though: the whole
chain could work differently rather than exposing all the attributes. But, if
we stay with what we have, we should definitely try to clean this up more. For
example, i hate that every Japanese*Attribute has a setToken() method at all.
They should be more pojo-like with get/set. The current
lazy-loaded/backed-by-token is an optimization that should somehow only be
known by the Tokenizer and the *Impl. And as an optimization, setToken() should
still work.
Make it easier to modify Japanese token attributes downstream
-
Key: LUCENE-6216
URL: https://issues.apache.org/jira/browse/LUCENE-6216
Project: Lucene - Core
Issue Type: Improvement
Components: modules/analysis
Reporter: Christian Moen
Priority: Minor
Japanese-specific token attributes such as {{PartOfSpeechAttribute}},
{{BaseFormAttribute}}, etc. get their values from a
{{org.apache.lucene.analysis.ja.Token}} through a {{setToken()}} method.
This makes it cumbersome to change these token attributes later on in the
analysis chain since the {{Token}} instances are difficult to instantiate
(sort of read-only objects).
I've ran into this issue in LUCENE-3922 (JapaneseNumberFilter) where it would
be appropriate to update token attributes to also reflect Japanese number
normalization.
I think it might be more practical to allow setting a specific value for
these token attributes directly rather than through a {{Token}} since it
makes the APIs simpler, allows for easier changing attributes downstream, and
also supporting additional dictionaries easier.
The drawback with the approach that I can think of is a performance hit as we
will miss out on the inherent lazy retrieval of these token attributes from
the {{Token}} object (and the underlying dictionary/buffer).
I'd like to do some testing to better understand the performance impact of
this change. Happy to hear your thoughts on 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
