[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1057 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1057/ 10 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrReplicationHandlerTest Error Message: ObjectTracker found 12 object(s) that were not released!!! [InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient] Stack Trace: java.lang.AssertionError: ObjectTracker found 12 object(s) that were not released!!! [InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient] at __randomizedtesting.SeedInfo.seed([82E33C2B432A9B38]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:256) at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrReplicationHandlerTest Error Message: 12 threads leaked from SUITE scope at org.apache.solr.cloud.CdcrReplicationHandlerTest: 1) Thread[id=3696, name=Connection evictor, state=TIMED_WAITING, group=TGRP-CdcrReplicationHandlerTest] at java.lang.Thread.sleep(Native Method) at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.lang.Thread.run(Thread.java:745)2) Thread[id=4341, name=Connection evictor, state=TIMED_WAITING, group=TGRP-CdcrReplicationHandlerTest] at java.lang.Thread.sleep(Native Method) at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.lang.Thread.run(Thread.java:745)3) Thread[id=4058, name=Connection evictor, state=TIMED_WAITING, group=TGRP-CdcrReplicationHandlerTest] at java.lang.Thread.sleep(Native Method) at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.lang.Thread.run(Thread.java:745)4) Thread[id=4340, name=Connection evictor, state=TIMED_WAITING, group=TGRP-CdcrReplicationHandlerTest] at java.lang.Thread.sleep(Native Method) at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.lang.Thread.run(Thread.java:745)5) Thread[id=3822, name=Connection evictor, state=TIMED_WAITING, group=TGRP-CdcrReplicationHandlerTest] at java.lang.Thread.sleep(Nativ
[jira] [Commented] (LUCENE-6914) DecimalDigitFilter skips characters in some cases (supplemental?)
[
https://issues.apache.org/jira/browse/LUCENE-6914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356618#comment-15356618
]
Adrien Grand commented on LUCENE-6914:
--
+1 to the patch
> DecimalDigitFilter skips characters in some cases (supplemental?)
> -
>
> Key: LUCENE-6914
> URL: https://issues.apache.org/jira/browse/LUCENE-6914
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: Hoss Man
> Attachments: LUCENE-6914.patch, LUCENE-6914.patch, LUCENE-6914.patch
>
>
> Found this while writing up the solr ref guide for DecimalDigitFilter.
> With input like "𝟙𝟡𝟠𝟜" ("Double Struck" 1984) the filter produces "1𝟡8𝟜" (1,
> double struck 9, 8, double struck 4) add some non-decimal characters in
> between the digits (ie: "𝟙x𝟡x𝟠x𝟜") and you get the expected output
> ("1x9x8x4"). This doesn't affect all decimal characters though, as evident
> by the existing test cases.
> Perhaps this is an off by one bug in the "if the original was supplementary,
> shrink the string" code path?
--
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] (LUCENE-7363) DecimalDigitFilter skips chars in case of supplementary code points
[
https://issues.apache.org/jira/browse/LUCENE-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand resolved LUCENE-7363.
--
Resolution: Duplicate
> DecimalDigitFilter skips chars in case of supplementary code points
> ---
>
> Key: LUCENE-7363
> URL: https://issues.apache.org/jira/browse/LUCENE-7363
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Attachments: LUCENE-7363.patch
>
>
> It does {{length = StemmerUtil.delete(buffer,++i, length);}} while it should
> really do {{length = StemmerUtil.delete(buffer,i+1, length);}}.
--
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-9216) Support collection.configName in MODIFYCOLLECTION request
[
https://issues.apache.org/jira/browse/SOLR-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356613#comment-15356613
]
ASF subversion and git services commented on SOLR-9216:
---
Commit 1dc7480bcdfba1e9c854172e19e8cc6ba96144d2 in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1dc7480 ]
SOLR-9216: Support collection.configName in MODIFYCOLLECTION request
> Support collection.configName in MODIFYCOLLECTION request
> -
>
> Key: SOLR-9216
> URL: https://issues.apache.org/jira/browse/SOLR-9216
> Project: Solr
> Issue Type: Improvement
>Reporter: Keith Laban
>Assignee: Noble Paul
> Attachments: SOLR-9216.patch, SOLR-9216.patch, SOLR-9216.patch
>
>
> MODIFYCOLLECTION should support updating the
> {{/collections/}} value of "configName" in zookeeper
--
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-7365) Don't use BooleanScorer for small segments
[
https://issues.apache.org/jira/browse/LUCENE-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356611#comment-15356611
]
Adrien Grand commented on LUCENE-7365:
--
One concern I have is that this reduces test coverage of BS1. Since this is
mostly an issue for MemoryIndex (the cost of searching small segments is
usually negligible compared to larger segments), maybe we could use another
approach and modify {{MemoryIndex.createSearcher}} to return an IndexSearcher
which overrides the {{protected void search(List leaves,
Weight weight, Collector collector)}} method in order to use the Scorer API
rather than the BulkScorer API?
> Don't use BooleanScorer for small segments
> --
>
> Key: LUCENE-7365
> URL: https://issues.apache.org/jira/browse/LUCENE-7365
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: LUCENE-7365.patch
>
>
> If a BooleanQuery meets certain criteria (only contains disjunctions, is
> likely to match large numbers of docs) then we use a BooleanScorer to score
> groups of 1024 docs at a time. This allocates arrays of 1024 Bucket objects
> up-front. On very small segments (for example, a MemoryIndex) this is very
> wasteful of memory, particularly if the query is large or deeply-nested. We
> should avoid using a bulk scorer on these segments.
--
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-9264) Optimize ZkController.publishAndWaitForDownStates
[ https://issues.apache.org/jira/browse/SOLR-9264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356600#comment-15356600 ] Hrishikesh Gadre commented on SOLR-9264: bq. since this variable is in the local scope. OK my bad. I see that the AtomicBoolean is indeed outside the scope of lambda expression. Now I don't quite understand how does this fix the concurrency issue. Don't we need separate AtomicBoolean per collection ? > Optimize ZkController.publishAndWaitForDownStates > - > > Key: SOLR-9264 > URL: https://issues.apache.org/jira/browse/SOLR-9264 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 6.2, master (7.0) > > Attachments: SOLR-9264.patch, SOLR-9264.patch > > > ZkController.publishAndWaitForDownStates keeps looping over all collections > in the cluster state to ensure that every replica hosted on the current node > has been marked as down. This is wasteful when you have a large number of > collections because each access to a non-watched collection gets data from > ZK. Instead, we can watch the interesting collections (i.e. which have > replicas hosted locally) and wait till we see the required state. -- 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-9264) Optimize ZkController.publishAndWaitForDownStates
[ https://issues.apache.org/jira/browse/SOLR-9264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356595#comment-15356595 ] Hrishikesh Gadre commented on SOLR-9264: [~ shalinmangar] Thanks for the updated patch. It seems to me that the logic based on AtomicBoolean is probably not sufficient if the callback is invoked multiple times *sequentially* for the same collection since this variable is in the local scope. Is it a possibility? I think instead of AtomicBoolean we should use a concurrent hashmap (outside the scope of the lambda expression). This map should be pre-populated with the collection names before registering the callback. We can even reuse the collectionsWithLocalReplica variable for this purpose (i.e. instead of Set, we will use ConcurrentHashMap type). Inside the callback we can use the remove method in a similar fashion to compareAndSet. i.e. instead of counted.compareAndSet(false, true) do collectionsWithLocalReplica.remove(collectionName) != null What do you think? > Optimize ZkController.publishAndWaitForDownStates > - > > Key: SOLR-9264 > URL: https://issues.apache.org/jira/browse/SOLR-9264 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 6.2, master (7.0) > > Attachments: SOLR-9264.patch, SOLR-9264.patch > > > ZkController.publishAndWaitForDownStates keeps looping over all collections > in the cluster state to ensure that every replica hosted on the current node > has been marked as down. This is wasteful when you have a large number of > collections because each access to a non-watched collection gets data from > ZK. Instead, we can watch the interesting collections (i.e. which have > replicas hosted locally) and wait till we see the required state. -- 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-6.x-Linux (64bit/jdk1.8.0_92) - Build # 1006 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1006/ Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseG1GC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestSolrConfigHandlerCloud Error Message: ObjectTracker found 4 object(s) that were not released!!! [SolrCore, SolrCore, MockDirectoryWrapper, MockDirectoryWrapper] Stack Trace: java.lang.AssertionError: ObjectTracker found 4 object(s) that were not released!!! [SolrCore, SolrCore, MockDirectoryWrapper, MockDirectoryWrapper] at __randomizedtesting.SeedInfo.seed([ADECA24BAEF78A43]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestSolrConfigHandlerCloud Error Message: 1 thread leaked from SUITE scope at org.apache.solr.handler.TestSolrConfigHandlerCloud: 1) Thread[id=89714, name=Thread-2274, state=TIMED_WAITING, group=TGRP-TestSolrConfigHandlerCloud] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101) at org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:333) at org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48) at org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75) at org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:107) at org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:78) at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:920) at org.apache.solr.core.SolrCore.lambda$getConfListener$6(SolrCore.java:2509) at org.apache.solr.core.SolrCore$$Lambda$60/1982991019.run(Unknown Source) at org.apache.solr.cloud.ZkController$4.run(ZkController.java:2443) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.handler.TestSolrConfigHandlerCloud: 1) Thread[id=89714, name=Thread-2274, state=TIMED_WAITING, group=TGRP-TestSolrConfigHandlerCloud] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101) at org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:333) at org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48) at org.apache.solr.schema.IndexSchemaFactory.
[jira] [Updated] (SOLR-9216) Support collection.configName in MODIFYCOLLECTION request
[
https://issues.apache.org/jira/browse/SOLR-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-9216:
-
Attachment: SOLR-9216.patch
we must reload a collection after changing the config name
> Support collection.configName in MODIFYCOLLECTION request
> -
>
> Key: SOLR-9216
> URL: https://issues.apache.org/jira/browse/SOLR-9216
> Project: Solr
> Issue Type: Improvement
>Reporter: Keith Laban
>Assignee: Noble Paul
> Attachments: SOLR-9216.patch, SOLR-9216.patch, SOLR-9216.patch
>
>
> MODIFYCOLLECTION should support updating the
> {{/collections/}} value of "configName" in zookeeper
--
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-6.x-Windows (32bit/jdk1.8.0_92) - Build # 283 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/283/ Java: 32bit/jdk1.8.0_92 -client -XX:+UseParallelGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: ObjectTracker found 8 object(s) that were not released!!! [TransactionLog, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper] Stack Trace: java.lang.AssertionError: ObjectTracker found 8 object(s) that were not released!!! [TransactionLog, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper] at __randomizedtesting.SeedInfo.seed([F3FB5C154CA966BD]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257) at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_F3FB5C154CA966BD-001\tempDir-001\node2\testschemaapi_shard1_replica1\data\tlog\tlog.001: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_F3FB5C154CA966BD-001\tempDir-001\node2\testschemaapi_shard1_replica1\data\tlog\tlog.001: The process cannot access the file because it is being used by another process. C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_F3FB5C154CA966BD-001\tempDir-001\node2\testschemaapi_shard1_replica1\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_F3FB5C154CA966BD-001\tempDir-001\node2\testschemaapi_shard1_replica1\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_F3FB5C154CA966BD-001\tempDir-001\node2\testschemaapi_shard1_replica1\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_F3FB5C154CA966BD-001\tempDir-001\node2\testschemaapi_shard1_replica1\data C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\sol
[jira] [Updated] (SOLR-9264) Optimize ZkController.publishAndWaitForDownStates
[ https://issues.apache.org/jira/browse/SOLR-9264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-9264: Attachment: SOLR-9264.patch Thanks Hrishikesh. This patch incorporates both of your review comments. I'll commit this shortly. > Optimize ZkController.publishAndWaitForDownStates > - > > Key: SOLR-9264 > URL: https://issues.apache.org/jira/browse/SOLR-9264 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 6.2, master (7.0) > > Attachments: SOLR-9264.patch, SOLR-9264.patch > > > ZkController.publishAndWaitForDownStates keeps looping over all collections > in the cluster state to ensure that every replica hosted on the current node > has been marked as down. This is wasteful when you have a large number of > collections because each access to a non-watched collection gets data from > ZK. Instead, we can watch the interesting collections (i.e. which have > replicas hosted locally) and wait till we see the required state. -- 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-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+124) - Build # 17101 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17101/
Java: 64bit/jdk-9-ea+124 -XX:-UseCompressedOops -XX:+UseG1GC
1 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler
Error Message:
ObjectTracker found 1 object(s) that were not released!!! [NRTCachingDirectory]
Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not
released!!! [NRTCachingDirectory]
at __randomizedtesting.SeedInfo.seed([7DE1DC7C88FC3383]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:256)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
Build Log:
[...truncated 10767 lines...]
[junit4] Suite: org.apache.solr.handler.TestReplicationHandler
[junit4] 2> Creating dataDir:
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_7DE1DC7C88FC3383-001/init-core-data-001
[junit4] 2> 151946 INFO
(SUITE-TestReplicationHandler-seed#[7DE1DC7C88FC3383]-worker) []
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via:
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=None)
[junit4] 2> 151947 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[7DE1DC7C88FC3383]) []
o.a.s.SolrTestCaseJ4 ###Starting doTestRepeater
[junit4] 2> 151948 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[7DE1DC7C88FC3383]) []
o.a.s.SolrTestCaseJ4 Writing core.properties file to
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_7DE1DC7C88FC3383-001/solr-instance-001/collection1
[junit4] 2> 151957 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[7DE1DC7C88FC3383]) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 151961 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[7DE1DC7C88FC3383]) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@73b3f336{/solr,null,AVAILABLE}
[junit4] 2> 151966 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[7DE1DC7C88FC3383]) []
o.e.j.s.ServerConnector Started
ServerConnector@37aec810{HTTP/1.1,[http/1.1]}{127.0.0.1:37384}
[junit4] 2> 151966 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[7DE1DC7C88FC3383]) []
o.e.j.s.Server Started @154291ms
[junit4] 2> 151966 INFO
(TEST-TestReplicationHan
[jira] [Assigned] (SOLR-9038) Ability to create/delete/list snapshots for a solr collection
[ https://issues.apache.org/jira/browse/SOLR-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley reassigned SOLR-9038: -- Assignee: David Smiley > Ability to create/delete/list snapshots for a solr collection > - > > Key: SOLR-9038 > URL: https://issues.apache.org/jira/browse/SOLR-9038 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Hrishikesh Gadre >Assignee: David Smiley > > Currently work is under-way to implement backup/restore API for Solr cloud > (SOLR-5750). SOLR-5750 is about providing an ability to "copy" index files > and collection metadata to a configurable location. > In addition to this, we should also provide a facility to create "named" > snapshots for Solr collection. Here by "snapshot" I mean configuring the > underlying Lucene IndexDeletionPolicy to not delete a specific commit point > (e.g. using PersistentSnapshotIndexDeletionPolicy). This should not be > confused with SOLR-5340 which implements core level "backup" functionality. > The primary motivation of this feature is to decouple recording/preserving a > known consistent state of a collection from actually "copying" the relevant > files to a physically separate location. This decoupling have number of > advantages > - We can use specialized data-copying tools for transferring Solr index > files. e.g. in Hadoop environment, typically > [distcp|https://hadoop.apache.org/docs/r1.2.1/distcp2.html] tool is used to > copy files from one location to other. This tool provides various options to > configure degree of parallelism, bandwidth usage as well as integration with > different types and versions of file systems (e.g. AWS S3, Azure Blob store > etc.) > - This separation of concern would also help Solr to focus on the key > functionality (i.e. querying and indexing) while delegating the copy > operation to the tools built for that purpose. > - Users can decide if/when to copy the data files as against creating a > snapshot. e.g. a user may want to create a snapshot of a collection before > making an experimental change (e.g. updating/deleting docs, schema change > etc.). If the experiment is successful, he can delete the snapshot (without > having to copy the files). If the experiment is failed, then he can copy the > files associated with the snapshot and restore. > Note that Apache Blur project is also providing a similar feature > [BLUR-132|https://issues.apache.org/jira/browse/BLUR-132] -- 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-9038) Ability to create/delete/list snapshots for a solr collection
[ https://issues.apache.org/jira/browse/SOLR-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356501#comment-15356501 ] David Smiley commented on SOLR-9038: bq. Previously SolrPersistentSnapshotManager was accessible only via IndexDeletionPolicyWrapper. Now I changed the logic to expose SolrPersistentSnapshotManager directly via SolrCore. +1 (I reviewed the commit). I think it's a small improvement in the sense that it may be non-obvious to some people that these classes are related. It didn't quite get at my point, but I think esp. with a previous improvement that I no longer wish to raise any concern about the relationship between them. So perhaps this is ready to commit, though there were some minor improvements I suggested RE Java 8 streams. Do tests pass & "ant precommit"? I can do this July 5th -- when I'm back from vacation. Possibly sooner. > Ability to create/delete/list snapshots for a solr collection > - > > Key: SOLR-9038 > URL: https://issues.apache.org/jira/browse/SOLR-9038 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Hrishikesh Gadre > > Currently work is under-way to implement backup/restore API for Solr cloud > (SOLR-5750). SOLR-5750 is about providing an ability to "copy" index files > and collection metadata to a configurable location. > In addition to this, we should also provide a facility to create "named" > snapshots for Solr collection. Here by "snapshot" I mean configuring the > underlying Lucene IndexDeletionPolicy to not delete a specific commit point > (e.g. using PersistentSnapshotIndexDeletionPolicy). This should not be > confused with SOLR-5340 which implements core level "backup" functionality. > The primary motivation of this feature is to decouple recording/preserving a > known consistent state of a collection from actually "copying" the relevant > files to a physically separate location. This decoupling have number of > advantages > - We can use specialized data-copying tools for transferring Solr index > files. e.g. in Hadoop environment, typically > [distcp|https://hadoop.apache.org/docs/r1.2.1/distcp2.html] tool is used to > copy files from one location to other. This tool provides various options to > configure degree of parallelism, bandwidth usage as well as integration with > different types and versions of file systems (e.g. AWS S3, Azure Blob store > etc.) > - This separation of concern would also help Solr to focus on the key > functionality (i.e. querying and indexing) while delegating the copy > operation to the tools built for that purpose. > - Users can decide if/when to copy the data files as against creating a > snapshot. e.g. a user may want to create a snapshot of a collection before > making an experimental change (e.g. updating/deleting docs, schema change > etc.). If the experiment is successful, he can delete the snapshot (without > having to copy the files). If the experiment is failed, then he can copy the > files associated with the snapshot and restore. > Note that Apache Blur project is also providing a similar feature > [BLUR-132|https://issues.apache.org/jira/browse/BLUR-132] -- 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-master-Windows (32bit/jdk1.8.0_92) - Build # 5945 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5945/ Java: 32bit/jdk1.8.0_92 -client -XX:+UseParallelGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [InternalHttpClient] Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [InternalHttpClient] at __randomizedtesting.SeedInfo.seed([BF365ADBD2B9C69B]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:256) at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([BF365ADBD2B9C69B:376265017C45AB63]:0) at org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test(TestSolrConfigHandlerConcurrent.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.
[JENKINS] Lucene-Solr-Tests-6.x - Build # 299 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/299/ 1 tests failed. FAILED: org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithTimeDelay Error Message: Could not find collection : c1 Stack Trace: org.apache.solr.common.SolrException: Could not find collection : c1 at __randomizedtesting.SeedInfo.seed([F6DEF604DC6FDB52:89404181B50DF6D8]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:192) at org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:129) at org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithTimeDelay(ZkStateReaderTest.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 11155 lines...] [junit4] Suite: org.apache.solr.cloud.overseer.ZkStateReaderTest [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/so
[jira] [Commented] (LUCENE-7340) MemoryIndex.toString is broken if you enable payloads
[ https://issues.apache.org/jira/browse/LUCENE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356311#comment-15356311 ] David Smiley commented on LUCENE-7340: -- I think it's dangerous that MemoryIndex.toString() can potentially generate a massive string. The functionality is useful but specifically overriding toString() is bad (IMO). If LUCENE-7361 results in a utility in misc/ then this code can simply be removed resulting in a default toString() since someone can simply use the proposed utility there to get this feature. If it results in nothing then this code can move to a new different method like toStringDebug that takes an Appendable (FYI StringBuilder & Writer implement that). > MemoryIndex.toString is broken if you enable payloads > - > > Key: LUCENE-7340 > URL: https://issues.apache.org/jira/browse/LUCENE-7340 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 5.4.1, 6.0.1, master (7.0) >Reporter: Daniel Collins >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-7340.diff, LUCENE-7340.diff, LUCENE-7340.patch > > > Noticed this as we use Luwak which creates a MemoryIndex(true, true) storing > both offsets and payloads (though in reality we never put any payloads in it). > We used to use MemoryIndex.toString() for debugging and noticed it broke in > Lucene 5.x and beyond. I think LUCENE-6155 broke it when it added support > for payloads? > Creating default memoryindex (as all the tests currently do) works fine, as > does one with just offsets, it is just the payload version which is broken. -- 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-7362) Implement FieldInfos and FieldInfo toString()
[ https://issues.apache.org/jira/browse/LUCENE-7362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356298#comment-15356298 ] David Smiley commented on LUCENE-7362: -- RE FieldInfos: okay RE FieldInfo: bq. The current toString is more useful to me than that, so it would just lose usefulness. That needn't go away if it's improved -- it can be the prefix. bq. If we want FieldInfo not plural to have a different toString it should simply print out all of the flags by name and value with no screwing around. Sounds good to me. > Implement FieldInfos and FieldInfo toString() > - > > Key: LUCENE-7362 > URL: https://issues.apache.org/jira/browse/LUCENE-7362 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: David Smiley > > FieldInfos and FieldInfo ought to override toString(). Perhaps > FieldInfo.toString() can look like the pattern popularized by Luke, also seen > in Solr? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7361) Terms.toStringDebug
[ https://issues.apache.org/jira/browse/LUCENE-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356285#comment-15356285 ] David Smiley commented on LUCENE-7361: -- Lets just remove toString() from MemoryIndex; I think it could be dangerously large and I've certainly put a ton of data in MemoryIndex before. But this issue isn't about MemoryIndex.toString(), it's about a hypothetical Terms.toStringDebug(Appendable) that wouldn't be called by Lucene itself (thus won't be in InfoStream), just a user if they want to (likely in a debug session passing System.out). bq. Having some kind of introspector on an index could be useful, though, so maybe instead of adding .toString() implementations, we have a special class in misc/ that prints this information out? And then MemoryIndex.toString() can just include some top-level stats, and users get pointed to the introspector for more detailed debugging info. +1 This issue can be retitled to reflect this change in location of the code. What do you think of the name IndexPrettyPrinter? Does this strategy sound good [~rcmuir]? I would prefer a Terms.toStringDebug though a utility class in misc/ is almost as good to me. > Terms.toStringDebug > --- > > Key: LUCENE-7361 > URL: https://issues.apache.org/jira/browse/LUCENE-7361 > Project: Lucene - Core > Issue Type: Improvement >Reporter: David Smiley > Attachments: MemoryIndexToString.java > > > While fixing LUCENE-7340, MemoryIndex.toString(), I thought MemoryIndex > shouldn't need it's own debug toString() impl for its Terms when there could > be a generic one. So here I propose that we create a > Terms.toStringDebug(Appendable result, int charLimit, String indent) or > some-such but probably not override toString() for obvious reasons. Maybe > also have this on Fields() that simply loops and calls out to the one on > Terms. > The format is debatable. -- 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-master - Build # 1240 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1240/
1 tests failed.
FAILED: org.apache.solr.handler.TestReqParamsAPI.test
Error Message:
Could not get expected value 'first' for path
'response/params/x/_appends_/add' full output: { "responseHeader":{
"status":0, "QTime":0}, "response":{ "znodeVersion":3, "params":{
"x":{ "a":"A val", "b":"B val", "":{"v":0}},
"y":{ "p":"P val", "q":"Q val", "":{"v":2}, from
server: http://127.0.0.1:55294/_w/d/collection1
Stack Trace:
java.lang.AssertionError: Could not get expected value 'first' for path
'response/params/x/_appends_/add' full output: {
"responseHeader":{
"status":0,
"QTime":0},
"response":{
"znodeVersion":3,
"params":{
"x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
"y":{
"p":"P val",
"q":"Q val",
"":{"v":2}, from server: http://127.0.0.1:55294/_w/d/collection1
at
__randomizedtesting.SeedInfo.seed([D419664A8F1697A2:5C4D599021EAFA5A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:481)
at
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:230)
at
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedt
[JENKINS] Lucene-Solr-Tests-6.x - Build # 298 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/298/ All tests passed Build Log: [...truncated 70243 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/build.xml:740: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/build.xml:101: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/build.xml:632: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/build.xml:607: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/common-build.xml:2496: Can't get https://issues.apache.org/jira/rest/api/2/project/SOLR to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/build/docs/changes/jiraVersionList.json Total time: 79 minutes 51 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_92) - Build # 1003 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1003/ Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll Error Message: Address already in use Stack Trace: java.net.BindException: Address already in use at __randomizedtesting.SeedInfo.seed([6FF9C5F8256E5CE:70C1832CC36148E1]:0) at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:433) at sun.nio.ch.Net.bind(Net.java:425) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) at org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:326) at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80) at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:244) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at org.eclipse.jetty.server.Server.doStart(Server.java:384) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:326) at org.apache.solr.cloud.MiniSolrCloudCluster.startJettySolrRunner(MiniSolrCloudCluster.java:377) at org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll(TestMiniSolrCloudCluster.java:443) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAsserti
[jira] [Commented] (SOLR-9038) Ability to create/delete/list snapshots for a solr collection
[ https://issues.apache.org/jira/browse/SOLR-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355893#comment-15355893 ] Hrishikesh Gadre commented on SOLR-9038: [~dsmiley] Thanks for the comments. bq. My only concern (repeating myself from GH) is that SolrPersistentSnapshotManager is a bolt-on to Solr's IndexDeletionPolicyWrapper when perhaps it should be integrated (one cohesive whole)? Or keep it bolt-on but make the code that's in IDPW a separate bolt-on as well? It's debatable... another opinion would be nice. I am not quite sure what you are alluding to. But here is my thinking. SolrPersistentSnapshotManager -> takes care of persisting/querying the snapshot meta-data IndexDeletionPolicyWrapper -> takes care of preserving the index commits for the configured snapshots. This keeps the code modular and easy to understand (as against adding all the logic in IndexDeletionPolicyWrapper directly). Previously SolrPersistentSnapshotManager was accessible only via IndexDeletionPolicyWrapper. Now I changed the logic to expose SolrPersistentSnapshotManager directly via SolrCore. This allows separation of concerns as described above. Please take a look, https://github.com/hgadre/lucene-solr/commit/68c2784b827ae27a002f0de6dfd01d2c9d3b07be Does this address your concern? May be we can rename SolrPersistentSnapshotManager to SolrSnapshotMetaDataManager for clarity. > Ability to create/delete/list snapshots for a solr collection > - > > Key: SOLR-9038 > URL: https://issues.apache.org/jira/browse/SOLR-9038 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Hrishikesh Gadre > > Currently work is under-way to implement backup/restore API for Solr cloud > (SOLR-5750). SOLR-5750 is about providing an ability to "copy" index files > and collection metadata to a configurable location. > In addition to this, we should also provide a facility to create "named" > snapshots for Solr collection. Here by "snapshot" I mean configuring the > underlying Lucene IndexDeletionPolicy to not delete a specific commit point > (e.g. using PersistentSnapshotIndexDeletionPolicy). This should not be > confused with SOLR-5340 which implements core level "backup" functionality. > The primary motivation of this feature is to decouple recording/preserving a > known consistent state of a collection from actually "copying" the relevant > files to a physically separate location. This decoupling have number of > advantages > - We can use specialized data-copying tools for transferring Solr index > files. e.g. in Hadoop environment, typically > [distcp|https://hadoop.apache.org/docs/r1.2.1/distcp2.html] tool is used to > copy files from one location to other. This tool provides various options to > configure degree of parallelism, bandwidth usage as well as integration with > different types and versions of file systems (e.g. AWS S3, Azure Blob store > etc.) > - This separation of concern would also help Solr to focus on the key > functionality (i.e. querying and indexing) while delegating the copy > operation to the tools built for that purpose. > - Users can decide if/when to copy the data files as against creating a > snapshot. e.g. a user may want to create a snapshot of a collection before > making an experimental change (e.g. updating/deleting docs, schema change > etc.). If the experiment is successful, he can delete the snapshot (without > having to copy the files). If the experiment is failed, then he can copy the > files associated with the snapshot and restore. > Note that Apache Blur project is also providing a similar feature > [BLUR-132|https://issues.apache.org/jira/browse/BLUR-132] -- 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-master - Build # 1239 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1239/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestSSLRandomization Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.TestSSLRandomization: 1) Thread[id=7860, name=OverseerHdfsCoreFailoverThread-96156884929937423-127.0.0.1:49898_solr-n_03, state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.TestSSLRandomization: 1) Thread[id=7860, name=OverseerHdfsCoreFailoverThread-96156884929937423-127.0.0.1:49898_solr-n_03, state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([6F2105CEB51A0E69]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestSSLRandomization Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=7860, name=OverseerHdfsCoreFailoverThread-96156884929937423-127.0.0.1:49898_solr-n_03, state=RUNNABLE, group=Overseer Hdfs SolrCore Failover Thread.] at org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=7860, name=OverseerHdfsCoreFailoverThread-96156884929937423-127.0.0.1:49898_solr-n_03, state=RUNNABLE, group=Overseer Hdfs SolrCore Failover Thread.] at org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([6F2105CEB51A0E69]:0) Build Log: [...truncated 11446 lines...] [junit4] Suite: org.apache.solr.cloud.TestSSLRandomization [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/solr-core/test/J1/temp/solr.cloud.TestSSLRandomization_6F2105CEB51A0E69-001/init-core-data-001 [junit4] 2> 991873 INFO (SUITE-TestSSLRandomization-seed#[6F2105CEB51A0E69]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: @org.apache.solr.util.RandomizeSSL(reason=frequent SSL usage to make test worth while, ssl=0.5, value=NaN, clientAuth=NaN) [junit4] 2> 991874 INFO (SUITE-TestSSLRandomization-seed#[6F2105CEB51A0E69]-worker) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 991878 INFO (Thread-2442) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 991878 INFO (Thread-2442) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 991978 INFO (SUITE-TestSSLRandomization-seed#[6F2105CEB51A0E69]-worker) [] o.a.s.c.ZkTestServer start zk server on port:40987 [junit4] 2> 991978 INFO (SUITE-TestSSLRandomization-seed#[6F2105CEB51A0E69]-worker) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 991978 INFO (SUITE-TestSSLRandomization-seed#[6F2105CEB51A0E69]-worker) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 991981 INFO (zkCallback-1086-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@15b33409 name:ZooKeeperConnection Watcher:127.0.0.1:40987 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 991981 INFO (SUITE-TestSSLRandomization-seed#[6F2105CEB51A0E69]-worker) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 991981 INFO (SUITE-TestSSLRandomization-seed#[6F2105CEB51A0E69]-worker) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 991981 INFO (SUITE-TestSSLRandomization-seed#[6F2105CEB51A0E69]-worker) [] o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml [junit4] 2> 991983 INFO (SUITE-TestSSLRandomization-seed#[6F2105CEB51A0E69]-worker) [] o.a.s.c.c.SolrZkClient makePath: /solr/clusterprops.json [junit4] 2> 991987 INFO (jetty-launcher-1085-thread-1) [] o.e.j.s.Server jetty-9.3.8.v20160314 [junit4] 2> 991987 INFO (jetty-launcher-1085-thread-2) [] o.e.j.s.Server jetty-9.3.8.v20160314 [junit4] 2> 991988 INFO (jetty-launcher-1085-thread-3) [] o.e.j.s.Server jetty-9.3.8.v20160314 [junit4] 2> 991989 INFO (jetty-launcher-1085-threa
[jira] [Commented] (SOLR-9264) Optimize ZkController.publishAndWaitForDownStates
[ https://issues.apache.org/jira/browse/SOLR-9264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355865#comment-15355865 ] Hrishikesh Gadre commented on SOLR-9264: [~ shalinmangar] I think the patch looks good. Only couple of minor comments, - Can we rename the "interestingCollections" and "interestingCollection" variable to something like "collectionsWithLocalReplica" and "collectionWithLocalReplica" ? It is a little difficult to understand what "interesting" means in this context without reading the JIRA description... - Is it possible for the callback to be delivered more than once? If yes then we should probably add some defensive check before invoking the countDown method on the latch. > Optimize ZkController.publishAndWaitForDownStates > - > > Key: SOLR-9264 > URL: https://issues.apache.org/jira/browse/SOLR-9264 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 6.2, master (7.0) > > Attachments: SOLR-9264.patch > > > ZkController.publishAndWaitForDownStates keeps looping over all collections > in the cluster state to ensure that every replica hosted on the current node > has been marked as down. This is wasteful when you have a large number of > collections because each access to a non-watched collection gets data from > ZK. Instead, we can watch the interesting collections (i.e. which have > replicas hosted locally) and wait till we see the required state. -- 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-8858) SolrIndexSearcher#doc() Completely Ignores Field Filters Unless Lazy Field Loading is Enabled
[
https://issues.apache.org/jira/browse/SOLR-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355848#comment-15355848
]
Caleb Rackliffe commented on SOLR-8858:
---
I've posted [a new PR| https://github.com/apache/lucene-solr/pull/47] against
master with some comments. I'm seeing zero failures in an {{ant test
-Dtests.slow=false}} run, so I think things are in a reviewable state.
> SolrIndexSearcher#doc() Completely Ignores Field Filters Unless Lazy Field
> Loading is Enabled
> -
>
> Key: SOLR-8858
> URL: https://issues.apache.org/jira/browse/SOLR-8858
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.6, 4.10, 5.5
>Reporter: Caleb Rackliffe
> Labels: easyfix
>
> If {{enableLazyFieldLoading=false}}, a perfectly valid fields filter will be
> ignored, and we'll create a {{DocumentStoredFieldVisitor}} without it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8396) Investigate PointField to replace NumericField types
[ https://issues.apache.org/jira/browse/SOLR-8396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomás Fernández Löbbe updated SOLR-8396: Attachment: SOLR-8396.patch Here is a new patch, updated to master. Added tests for docValues actions (faceting, sorting and stats). Still full of commented out code and only int fields yet > Investigate PointField to replace NumericField types > > > Key: SOLR-8396 > URL: https://issues.apache.org/jira/browse/SOLR-8396 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya > Attachments: SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch > > > In LUCENE-6917, [~mikemccand] mentioned that DimensionalValues are better > than NumericFields in most respects. We should explore the benefits of using > it in Solr and hence, if appropriate, switch over to using them. -- 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-9265) Add configurable node_name aliases instead of host:post_context
Keith Laban created SOLR-9265:
-
Summary: Add configurable node_name aliases instead of
host:post_context
Key: SOLR-9265
URL: https://issues.apache.org/jira/browse/SOLR-9265
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Keith Laban
Make it possible to give an alias name to node_name of an instance. As far as I
can tell you can’t do this, it's always going to be :_.
The goals of this change are the following:
1) Address the node by alias in the core admin/collection apis
2) Be able to start a new node with the same alias and have it update
clusterstate with the new base_url and suck down all the cores that the old
alias was hosting. This is already (kind of) possible if you create
core.properties for all the cores that you want the new node to host. However I
think this bleeds a little too much of the ananotmy of the cloud into the
directory structure of the solr instance. The other approach is more in the
paradigm of zookeeper is truth.
For #2 the desired behavior should be such that.
1) If there is already a live node with the same node_name this current node
should block until that node is gone
2) Once there is no node with the same node name and if there are any cores
assigned to that node alias they should now be hosted on the newly started node
3) If the old node comes back with the same alias and there is now a node in
live nodes with this alias go back to #1
Configuration should be in solr.xml such that:
{code}
${solrNodeName:}
{code}
where the default would be ":_" style.
An example for requirement #1:
{{/admin/collections?action=ADDREPLICA&collection=collection&shard=shard&node=solrNodeNameAlias}}
--
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-9265) Add configurable node_name aliases instead of host:post_context
[
https://issues.apache.org/jira/browse/SOLR-9265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355831#comment-15355831
]
Keith Laban commented on SOLR-9265:
---
I briefly spoke to [~shalinmangar] offline about this idea
> Add configurable node_name aliases instead of host:post_context
> ---
>
> Key: SOLR-9265
> URL: https://issues.apache.org/jira/browse/SOLR-9265
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Keith Laban
>
> Make it possible to give an alias name to node_name of an instance. As far as
> I can tell you can’t do this, it's always going to be
> :_. The goals of this change are the following:
> 1) Address the node by alias in the core admin/collection apis
> 2) Be able to start a new node with the same alias and have it update
> clusterstate with the new base_url and suck down all the cores that the old
> alias was hosting. This is already (kind of) possible if you create
> core.properties for all the cores that you want the new node to host. However
> I think this bleeds a little too much of the ananotmy of the cloud into the
> directory structure of the solr instance. The other approach is more in the
> paradigm of zookeeper is truth.
> For #2 the desired behavior should be such that.
> 1) If there is already a live node with the same node_name this current node
> should block until that node is gone
> 2) Once there is no node with the same node name and if there are any cores
> assigned to that node alias they should now be hosted on the newly started
> node
> 3) If the old node comes back with the same alias and there is now a node in
> live nodes with this alias go back to #1
> Configuration should be in solr.xml such that:
> {code}
>
>
> ${solrNodeName:}
>
>
> {code}
> where the default would be ":_" style.
> An example for requirement #1:
> {{/admin/collections?action=ADDREPLICA&collection=collection&shard=shard&node=solrNodeNameAlias}}
--
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-9264) Optimize ZkController.publishAndWaitForDownStates
[ https://issues.apache.org/jira/browse/SOLR-9264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-9264: Attachment: SOLR-9264.patch Patch which uses ZkStateReader's registerCollectionStateWatcher to wait until all replicas are in 'down' state. > Optimize ZkController.publishAndWaitForDownStates > - > > Key: SOLR-9264 > URL: https://issues.apache.org/jira/browse/SOLR-9264 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 6.2, master (7.0) > > Attachments: SOLR-9264.patch > > > ZkController.publishAndWaitForDownStates keeps looping over all collections > in the cluster state to ensure that every replica hosted on the current node > has been marked as down. This is wasteful when you have a large number of > collections because each access to a non-watched collection gets data from > ZK. Instead, we can watch the interesting collections (i.e. which have > replicas hosted locally) and wait till we see the required state. -- 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-9216) Support collection.configName in MODIFYCOLLECTION request
[
https://issues.apache.org/jira/browse/SOLR-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355784#comment-15355784
]
Keith Laban commented on SOLR-9216:
---
removed changes from RulesTest and added an OverseerModifyCollectionTest with
this testcase
> Support collection.configName in MODIFYCOLLECTION request
> -
>
> Key: SOLR-9216
> URL: https://issues.apache.org/jira/browse/SOLR-9216
> Project: Solr
> Issue Type: Improvement
>Reporter: Keith Laban
>Assignee: Noble Paul
> Attachments: SOLR-9216.patch, SOLR-9216.patch
>
>
> MODIFYCOLLECTION should support updating the
> {{/collections/}} value of "configName" in zookeeper
--
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-9216) Support collection.configName in MODIFYCOLLECTION request
[
https://issues.apache.org/jira/browse/SOLR-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Laban updated SOLR-9216:
--
Attachment: SOLR-9216.patch
> Support collection.configName in MODIFYCOLLECTION request
> -
>
> Key: SOLR-9216
> URL: https://issues.apache.org/jira/browse/SOLR-9216
> Project: Solr
> Issue Type: Improvement
>Reporter: Keith Laban
>Assignee: Noble Paul
> Attachments: SOLR-9216.patch, SOLR-9216.patch
>
>
> MODIFYCOLLECTION should support updating the
> {{/collections/}} value of "configName" in zookeeper
--
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-9264) Optimize ZkController.publishAndWaitForDownStates
Shalin Shekhar Mangar created SOLR-9264: --- Summary: Optimize ZkController.publishAndWaitForDownStates Key: SOLR-9264 URL: https://issues.apache.org/jira/browse/SOLR-9264 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 6.2, master (7.0) ZkController.publishAndWaitForDownStates keeps looping over all collections in the cluster state to ensure that every replica hosted on the current node has been marked as down. This is wasteful when you have a large number of collections because each access to a non-watched collection gets data from ZK. Instead, we can watch the interesting collections (i.e. which have replicas hosted locally) and wait till we see the required state. -- 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-6.x-Linux (64bit/jdk1.8.0_92) - Build # 1002 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1002/ Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 53957 lines...] BUILD FAILED /home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:740: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:101: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build.xml:138: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build.xml:480: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:2496: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/docs/changes/jiraVersionList.json Total time: 68 minutes 46 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8858) SolrIndexSearcher#doc() Completely Ignores Field Filters Unless Lazy Field Loading is Enabled
[
https://issues.apache.org/jira/browse/SOLR-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated SOLR-8858:
--
External issue URL: https://github.com/apache/lucene-solr/pull/47 (was:
https://github.com/apache/lucene-solr/pull/21)
> SolrIndexSearcher#doc() Completely Ignores Field Filters Unless Lazy Field
> Loading is Enabled
> -
>
> Key: SOLR-8858
> URL: https://issues.apache.org/jira/browse/SOLR-8858
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.6, 4.10, 5.5
>Reporter: Caleb Rackliffe
> Labels: easyfix
>
> If {{enableLazyFieldLoading=false}}, a perfectly valid fields filter will be
> ignored, and we'll create a {{DocumentStoredFieldVisitor}} without it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8858) SolrIndexSearcher#doc() Completely Ignores Field Filters Unless Lazy Field Loading is Enabled
[
https://issues.apache.org/jira/browse/SOLR-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355721#comment-15355721
]
ASF GitHub Bot commented on SOLR-8858:
--
GitHub user maedhroz opened a pull request:
https://github.com/apache/lucene-solr/pull/47
SOLR-8858 SolrIndexSearcher#doc() Completely Ignores Field Filters Unless
Lazy Field Loading is Enabled
https://issues.apache.org/jira/browse/SOLR-8858
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/maedhroz/lucene-solr SOLR-8858-trunk
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/lucene-solr/pull/47.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #47
> SolrIndexSearcher#doc() Completely Ignores Field Filters Unless Lazy Field
> Loading is Enabled
> -
>
> Key: SOLR-8858
> URL: https://issues.apache.org/jira/browse/SOLR-8858
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.6, 4.10, 5.5
>Reporter: Caleb Rackliffe
> Labels: easyfix
>
> If {{enableLazyFieldLoading=false}}, a perfectly valid fields filter will be
> ignored, and we'll create a {{DocumentStoredFieldVisitor}} without it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #47: SOLR-8858 SolrIndexSearcher#doc() Completely I...
GitHub user maedhroz opened a pull request: https://github.com/apache/lucene-solr/pull/47 SOLR-8858 SolrIndexSearcher#doc() Completely Ignores Field Filters Unless Lazy Field Loading is Enabled https://issues.apache.org/jira/browse/SOLR-8858 You can merge this pull request into a Git repository by running: $ git pull https://github.com/maedhroz/lucene-solr SOLR-8858-trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/47.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #47 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7363) DecimalDigitFilter skips chars in case of supplementary code points
[
https://issues.apache.org/jira/browse/LUCENE-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355719#comment-15355719
]
Adrien Grand commented on LUCENE-7363:
--
Thanks Hoss, that is the same bug indeed!
> DecimalDigitFilter skips chars in case of supplementary code points
> ---
>
> Key: LUCENE-7363
> URL: https://issues.apache.org/jira/browse/LUCENE-7363
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Attachments: LUCENE-7363.patch
>
>
> It does {{length = StemmerUtil.delete(buffer,++i, length);}} while it should
> really do {{length = StemmerUtil.delete(buffer,i+1, length);}}.
--
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-master - Build # 1238 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1238/
2 tests failed.
FAILED: org.apache.solr.handler.TestReqParamsAPI.test
Error Message:
Could not get expected value 'P val' for path 'response/params/y/p' full
output: { "responseHeader":{ "status":0, "QTime":0}, "response":{
"znodeVersion":2, "params":{ "x":{ "a":"A val",
"b":"B val", "":{"v":0}}, "y":{ "c":"CY val modified",
"b":"BY val", "i":20, "d":[ "val 1",
"val 2"], "e":"EY val", "":{"v":1}, from server:
http://127.0.0.1:33481/va/gw/collection1
Stack Trace:
java.lang.AssertionError: Could not get expected value 'P val' for path
'response/params/y/p' full output: {
"responseHeader":{
"status":0,
"QTime":0},
"response":{
"znodeVersion":2,
"params":{
"x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
"y":{
"c":"CY val modified",
"b":"BY val",
"i":20,
"d":[
"val 1",
"val 2"],
"e":"EY val",
"":{"v":1}, from server: http://127.0.0.1:33481/va/gw/collection1
at
__randomizedtesting.SeedInfo.seed([E6D69593785F00E1:6E82AA49D6A36D19]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:481)
at
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:215)
at
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShado
[jira] [Updated] (SOLR-9246) Errors for Streaming Expressions using JDBC (Oracle) stream source
[
https://issues.apache.org/jira/browse/SOLR-9246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Gove updated SOLR-9246:
--
Fix Version/s: master (7.0)
6.2
6.1.1
6.0.2
> Errors for Streaming Expressions using JDBC (Oracle) stream source
> --
>
> Key: SOLR-9246
> URL: https://issues.apache.org/jira/browse/SOLR-9246
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0.1
> Environment: Windows 7
>Reporter: Hui Liu
>Assignee: Dennis Gove
> Fix For: 6.0.2, 6.1.1, 6.2, master (7.0)
>
> Attachments: Re Errors for Streaming Expressions using JDBC (Oracle)
> stream source.txt, SOLR-9246.patch
>
>
> I have Solr 6.0.0 installed on my PC (windows 7), I was experimenting with
> ‘Streaming Expression’ by using Oracle jdbc as the
> stream source, but got 'null pointer' errors, below is the details on how to
> reproduce this error:
> 1. create a collection 'document6' which only contain long and string data
> type,
> schema.xml for Solr collection 'document6': (newly created empty collections
> with 2 shards)
> ===
>
>
>
>
> docValues="true" />
> precisionStep="0" positionIncrementGap="0"/>
>
>
>
>
>
>omitNorms="true"/>
>
>
> multiValued="false"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
>
> document_id
> document_id
>
> 2. create a new Oracle (version 11.2.0.3) table 'document6' that only contain
> columns whose jdbc type is long and string,
> create table document6
> (document_id number(12) not null,
> sender_msg_dest varchar2(256),
> recip_msg_dest varchar2(256),
> document_type varchar2(20),
> document_keyvarchar2(100));
> loaded 9 records;
> Oracle table 'document6': (newly created Oracle table with 9 records)
> =
> QA_DOCREP@qlgdb1 > desc document6
> Name Null?Type
> -
>
> DOCUMENT_ID NOT NULL NUMBER(12)
> SENDER_MSG_DESTVARCHAR2(256)
> RECIP_MSG_DEST VARCHAR2(256)
> DOCUMENT_TYPE VARCHAR2(20)
> DOCUMENT_KEY VARCHAR2(100)
> 3. tried this jdbc streaming expression in my browser, getting the error
> stack (see below)
> http://localhost:8988/solr/document6/stream?expr=jdbc(connection="jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql="SELECT
> document_id,sender_msg_dest,recip_msg_dest,document_type,document_key FROM
> document6",sort="document_id asc",driver="oracle.jdbc.driver.OracleDriver")
> errors in solr.log
> ==
> 2016-06-23 14:07:02.833 INFO (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.S.Request
> [document6_shard2_replica1] webapp=/solr path=/stream
> params={expr=jdbc(connection%3D"jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql%3D"SELECT+document_id,sender_msg_dest,recip_msg_dest,document_type,document_key+FROM+document6",sort%3D"document_id+asc",driver%3D"oracle.jdbc.driver.OracleDriver")}
> status=0 QTime=1
> 2016-06-23 14:07:05.282 ERROR (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.s.i.s.ExceptionStream
> java.lang.NullPointerException
> at
> org.apache.solr.client.solrj.io.stream.JDBCStream.read(JDBCStream.java:305)
> at
> org.apache.solr.client.solrj.io.stream.ExceptionStream.read(ExceptionStream.java:64)
> at
> org.apache.solr.handler.StreamHandler$TimerStream.read(StreamHandler.java:374)
> at
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:305)
> at
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
> at
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
> at
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
> at
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95)
> at
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:60)
> at
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at
> org.apache.solr.servlet.HttpSolrCall
[jira] [Closed] (SOLR-9246) Errors for Streaming Expressions using JDBC (Oracle) stream source
[
https://issues.apache.org/jira/browse/SOLR-9246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Gove closed SOLR-9246.
-
Resolution: Fixed
> Errors for Streaming Expressions using JDBC (Oracle) stream source
> --
>
> Key: SOLR-9246
> URL: https://issues.apache.org/jira/browse/SOLR-9246
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0.1
> Environment: Windows 7
>Reporter: Hui Liu
>Assignee: Dennis Gove
> Fix For: 6.0.2, 6.1.1, 6.2, master (7.0)
>
> Attachments: Re Errors for Streaming Expressions using JDBC (Oracle)
> stream source.txt, SOLR-9246.patch
>
>
> I have Solr 6.0.0 installed on my PC (windows 7), I was experimenting with
> ‘Streaming Expression’ by using Oracle jdbc as the
> stream source, but got 'null pointer' errors, below is the details on how to
> reproduce this error:
> 1. create a collection 'document6' which only contain long and string data
> type,
> schema.xml for Solr collection 'document6': (newly created empty collections
> with 2 shards)
> ===
>
>
>
>
> docValues="true" />
> precisionStep="0" positionIncrementGap="0"/>
>
>
>
>
>
>omitNorms="true"/>
>
>
> multiValued="false"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
>
> document_id
> document_id
>
> 2. create a new Oracle (version 11.2.0.3) table 'document6' that only contain
> columns whose jdbc type is long and string,
> create table document6
> (document_id number(12) not null,
> sender_msg_dest varchar2(256),
> recip_msg_dest varchar2(256),
> document_type varchar2(20),
> document_keyvarchar2(100));
> loaded 9 records;
> Oracle table 'document6': (newly created Oracle table with 9 records)
> =
> QA_DOCREP@qlgdb1 > desc document6
> Name Null?Type
> -
>
> DOCUMENT_ID NOT NULL NUMBER(12)
> SENDER_MSG_DESTVARCHAR2(256)
> RECIP_MSG_DEST VARCHAR2(256)
> DOCUMENT_TYPE VARCHAR2(20)
> DOCUMENT_KEY VARCHAR2(100)
> 3. tried this jdbc streaming expression in my browser, getting the error
> stack (see below)
> http://localhost:8988/solr/document6/stream?expr=jdbc(connection="jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql="SELECT
> document_id,sender_msg_dest,recip_msg_dest,document_type,document_key FROM
> document6",sort="document_id asc",driver="oracle.jdbc.driver.OracleDriver")
> errors in solr.log
> ==
> 2016-06-23 14:07:02.833 INFO (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.S.Request
> [document6_shard2_replica1] webapp=/solr path=/stream
> params={expr=jdbc(connection%3D"jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql%3D"SELECT+document_id,sender_msg_dest,recip_msg_dest,document_type,document_key+FROM+document6",sort%3D"document_id+asc",driver%3D"oracle.jdbc.driver.OracleDriver")}
> status=0 QTime=1
> 2016-06-23 14:07:05.282 ERROR (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.s.i.s.ExceptionStream
> java.lang.NullPointerException
> at
> org.apache.solr.client.solrj.io.stream.JDBCStream.read(JDBCStream.java:305)
> at
> org.apache.solr.client.solrj.io.stream.ExceptionStream.read(ExceptionStream.java:64)
> at
> org.apache.solr.handler.StreamHandler$TimerStream.read(StreamHandler.java:374)
> at
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:305)
> at
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
> at
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
> at
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
> at
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95)
> at
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:60)
> at
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:725)
> at org.apache.solr.servlet.HttpSolrCall
[jira] [Commented] (SOLR-9246) Errors for Streaming Expressions using JDBC (Oracle) stream source
[
https://issues.apache.org/jira/browse/SOLR-9246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355694#comment-15355694
]
Dennis Gove commented on SOLR-9246:
---
This was also committed to the master branch. I don't know why an auto note
isn't being added here.
https://github.com/apache/lucene-solr/commit/1ae0d8d6e1394a941b65c940cb449662d7cab5d2
> Errors for Streaming Expressions using JDBC (Oracle) stream source
> --
>
> Key: SOLR-9246
> URL: https://issues.apache.org/jira/browse/SOLR-9246
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0.1
> Environment: Windows 7
>Reporter: Hui Liu
>Assignee: Dennis Gove
> Attachments: Re Errors for Streaming Expressions using JDBC (Oracle)
> stream source.txt, SOLR-9246.patch
>
>
> I have Solr 6.0.0 installed on my PC (windows 7), I was experimenting with
> ‘Streaming Expression’ by using Oracle jdbc as the
> stream source, but got 'null pointer' errors, below is the details on how to
> reproduce this error:
> 1. create a collection 'document6' which only contain long and string data
> type,
> schema.xml for Solr collection 'document6': (newly created empty collections
> with 2 shards)
> ===
>
>
>
>
> docValues="true" />
> precisionStep="0" positionIncrementGap="0"/>
>
>
>
>
>
>omitNorms="true"/>
>
>
> multiValued="false"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
>
> document_id
> document_id
>
> 2. create a new Oracle (version 11.2.0.3) table 'document6' that only contain
> columns whose jdbc type is long and string,
> create table document6
> (document_id number(12) not null,
> sender_msg_dest varchar2(256),
> recip_msg_dest varchar2(256),
> document_type varchar2(20),
> document_keyvarchar2(100));
> loaded 9 records;
> Oracle table 'document6': (newly created Oracle table with 9 records)
> =
> QA_DOCREP@qlgdb1 > desc document6
> Name Null?Type
> -
>
> DOCUMENT_ID NOT NULL NUMBER(12)
> SENDER_MSG_DESTVARCHAR2(256)
> RECIP_MSG_DEST VARCHAR2(256)
> DOCUMENT_TYPE VARCHAR2(20)
> DOCUMENT_KEY VARCHAR2(100)
> 3. tried this jdbc streaming expression in my browser, getting the error
> stack (see below)
> http://localhost:8988/solr/document6/stream?expr=jdbc(connection="jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql="SELECT
> document_id,sender_msg_dest,recip_msg_dest,document_type,document_key FROM
> document6",sort="document_id asc",driver="oracle.jdbc.driver.OracleDriver")
> errors in solr.log
> ==
> 2016-06-23 14:07:02.833 INFO (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.S.Request
> [document6_shard2_replica1] webapp=/solr path=/stream
> params={expr=jdbc(connection%3D"jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql%3D"SELECT+document_id,sender_msg_dest,recip_msg_dest,document_type,document_key+FROM+document6",sort%3D"document_id+asc",driver%3D"oracle.jdbc.driver.OracleDriver")}
> status=0 QTime=1
> 2016-06-23 14:07:05.282 ERROR (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.s.i.s.ExceptionStream
> java.lang.NullPointerException
> at
> org.apache.solr.client.solrj.io.stream.JDBCStream.read(JDBCStream.java:305)
> at
> org.apache.solr.client.solrj.io.stream.ExceptionStream.read(ExceptionStream.java:64)
> at
> org.apache.solr.handler.StreamHandler$TimerStream.read(StreamHandler.java:374)
> at
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:305)
> at
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
> at
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
> at
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
> at
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95)
> at
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:60)
> at
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse
[jira] [Commented] (SOLR-9246) Errors for Streaming Expressions using JDBC (Oracle) stream source
[
https://issues.apache.org/jira/browse/SOLR-9246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355690#comment-15355690
]
ASF subversion and git services commented on SOLR-9246:
---
Commit a1756f6deb379f99ada6222ddca3dd4a15dad7d3 in lucene-solr's branch
refs/heads/branch_6_0 from [~dpgove]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a1756f6 ]
SOLR-9246: If the JDBCStream sees an unknown column type it will now throw a
detailed exception
> Errors for Streaming Expressions using JDBC (Oracle) stream source
> --
>
> Key: SOLR-9246
> URL: https://issues.apache.org/jira/browse/SOLR-9246
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0.1
> Environment: Windows 7
>Reporter: Hui Liu
>Assignee: Dennis Gove
> Attachments: Re Errors for Streaming Expressions using JDBC (Oracle)
> stream source.txt, SOLR-9246.patch
>
>
> I have Solr 6.0.0 installed on my PC (windows 7), I was experimenting with
> ‘Streaming Expression’ by using Oracle jdbc as the
> stream source, but got 'null pointer' errors, below is the details on how to
> reproduce this error:
> 1. create a collection 'document6' which only contain long and string data
> type,
> schema.xml for Solr collection 'document6': (newly created empty collections
> with 2 shards)
> ===
>
>
>
>
> docValues="true" />
> precisionStep="0" positionIncrementGap="0"/>
>
>
>
>
>
>omitNorms="true"/>
>
>
> multiValued="false"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
>
> document_id
> document_id
>
> 2. create a new Oracle (version 11.2.0.3) table 'document6' that only contain
> columns whose jdbc type is long and string,
> create table document6
> (document_id number(12) not null,
> sender_msg_dest varchar2(256),
> recip_msg_dest varchar2(256),
> document_type varchar2(20),
> document_keyvarchar2(100));
> loaded 9 records;
> Oracle table 'document6': (newly created Oracle table with 9 records)
> =
> QA_DOCREP@qlgdb1 > desc document6
> Name Null?Type
> -
>
> DOCUMENT_ID NOT NULL NUMBER(12)
> SENDER_MSG_DESTVARCHAR2(256)
> RECIP_MSG_DEST VARCHAR2(256)
> DOCUMENT_TYPE VARCHAR2(20)
> DOCUMENT_KEY VARCHAR2(100)
> 3. tried this jdbc streaming expression in my browser, getting the error
> stack (see below)
> http://localhost:8988/solr/document6/stream?expr=jdbc(connection="jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql="SELECT
> document_id,sender_msg_dest,recip_msg_dest,document_type,document_key FROM
> document6",sort="document_id asc",driver="oracle.jdbc.driver.OracleDriver")
> errors in solr.log
> ==
> 2016-06-23 14:07:02.833 INFO (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.S.Request
> [document6_shard2_replica1] webapp=/solr path=/stream
> params={expr=jdbc(connection%3D"jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql%3D"SELECT+document_id,sender_msg_dest,recip_msg_dest,document_type,document_key+FROM+document6",sort%3D"document_id+asc",driver%3D"oracle.jdbc.driver.OracleDriver")}
> status=0 QTime=1
> 2016-06-23 14:07:05.282 ERROR (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.s.i.s.ExceptionStream
> java.lang.NullPointerException
> at
> org.apache.solr.client.solrj.io.stream.JDBCStream.read(JDBCStream.java:305)
> at
> org.apache.solr.client.solrj.io.stream.ExceptionStream.read(ExceptionStream.java:64)
> at
> org.apache.solr.handler.StreamHandler$TimerStream.read(StreamHandler.java:374)
> at
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:305)
> at
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
> at
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
> at
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
> at
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95)
> at
> org.apache.solr.response.J
[jira] [Reopened] (LUCENE-7364) Don't use BooleanScorer for small segments
[ https://issues.apache.org/jira/browse/LUCENE-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward reopened LUCENE-7364: --- I think you meant to resolve LUCENE-6914 [~hossman]? > Don't use BooleanScorer for small segments > -- > > Key: LUCENE-7364 > URL: https://issues.apache.org/jira/browse/LUCENE-7364 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward > > If a BooleanQuery meets certain criteria (only contains disjunctions, is > likely to match large numbers of docs) then we use a BooleanScorer to score > groups of 1024 docs at a time. This allocates arrays of 1024 Bucket objects > up-front. On very small segments (for example, a MemoryIndex) this is very > wasteful of memory, particularly if the query is large or deeply-nested. We > should avoid using a bulk scorer on these segments. -- 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] (LUCENE-7364) Don't use BooleanScorer for small segments
[ https://issues.apache.org/jira/browse/LUCENE-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved LUCENE-7364. --- Resolution: Fixed Ack, no, just seen the duplicate. Sorry for the noise! > Don't use BooleanScorer for small segments > -- > > Key: LUCENE-7364 > URL: https://issues.apache.org/jira/browse/LUCENE-7364 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward > > If a BooleanQuery meets certain criteria (only contains disjunctions, is > likely to match large numbers of docs) then we use a BooleanScorer to score > groups of 1024 docs at a time. This allocates arrays of 1024 Bucket objects > up-front. On very small segments (for example, a MemoryIndex) this is very > wasteful of memory, particularly if the query is large or deeply-nested. We > should avoid using a bulk scorer on these segments. -- 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-9246) Errors for Streaming Expressions using JDBC (Oracle) stream source
[
https://issues.apache.org/jira/browse/SOLR-9246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355614#comment-15355614
]
ASF subversion and git services commented on SOLR-9246:
---
Commit 86a19829dbd18d7fe38c0d89d7e23c25419bc935 in lucene-solr's branch
refs/heads/branch_6_1 from [~dpgove]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86a1982 ]
SOLR-9246: If the JDBCStream sees an unknown column type it will now throw a
detailed exception
> Errors for Streaming Expressions using JDBC (Oracle) stream source
> --
>
> Key: SOLR-9246
> URL: https://issues.apache.org/jira/browse/SOLR-9246
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0.1
> Environment: Windows 7
>Reporter: Hui Liu
>Assignee: Dennis Gove
> Attachments: Re Errors for Streaming Expressions using JDBC (Oracle)
> stream source.txt, SOLR-9246.patch
>
>
> I have Solr 6.0.0 installed on my PC (windows 7), I was experimenting with
> ‘Streaming Expression’ by using Oracle jdbc as the
> stream source, but got 'null pointer' errors, below is the details on how to
> reproduce this error:
> 1. create a collection 'document6' which only contain long and string data
> type,
> schema.xml for Solr collection 'document6': (newly created empty collections
> with 2 shards)
> ===
>
>
>
>
> docValues="true" />
> precisionStep="0" positionIncrementGap="0"/>
>
>
>
>
>
>omitNorms="true"/>
>
>
> multiValued="false"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
>
> document_id
> document_id
>
> 2. create a new Oracle (version 11.2.0.3) table 'document6' that only contain
> columns whose jdbc type is long and string,
> create table document6
> (document_id number(12) not null,
> sender_msg_dest varchar2(256),
> recip_msg_dest varchar2(256),
> document_type varchar2(20),
> document_keyvarchar2(100));
> loaded 9 records;
> Oracle table 'document6': (newly created Oracle table with 9 records)
> =
> QA_DOCREP@qlgdb1 > desc document6
> Name Null?Type
> -
>
> DOCUMENT_ID NOT NULL NUMBER(12)
> SENDER_MSG_DESTVARCHAR2(256)
> RECIP_MSG_DEST VARCHAR2(256)
> DOCUMENT_TYPE VARCHAR2(20)
> DOCUMENT_KEY VARCHAR2(100)
> 3. tried this jdbc streaming expression in my browser, getting the error
> stack (see below)
> http://localhost:8988/solr/document6/stream?expr=jdbc(connection="jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql="SELECT
> document_id,sender_msg_dest,recip_msg_dest,document_type,document_key FROM
> document6",sort="document_id asc",driver="oracle.jdbc.driver.OracleDriver")
> errors in solr.log
> ==
> 2016-06-23 14:07:02.833 INFO (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.S.Request
> [document6_shard2_replica1] webapp=/solr path=/stream
> params={expr=jdbc(connection%3D"jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql%3D"SELECT+document_id,sender_msg_dest,recip_msg_dest,document_type,document_key+FROM+document6",sort%3D"document_id+asc",driver%3D"oracle.jdbc.driver.OracleDriver")}
> status=0 QTime=1
> 2016-06-23 14:07:05.282 ERROR (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.s.i.s.ExceptionStream
> java.lang.NullPointerException
> at
> org.apache.solr.client.solrj.io.stream.JDBCStream.read(JDBCStream.java:305)
> at
> org.apache.solr.client.solrj.io.stream.ExceptionStream.read(ExceptionStream.java:64)
> at
> org.apache.solr.handler.StreamHandler$TimerStream.read(StreamHandler.java:374)
> at
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:305)
> at
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
> at
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
> at
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
> at
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95)
> at
> org.apache.solr.response.J
[jira] [Resolved] (LUCENE-7364) Don't use BooleanScorer for small segments
[ https://issues.apache.org/jira/browse/LUCENE-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved LUCENE-7364. -- Resolution: Duplicate > Don't use BooleanScorer for small segments > -- > > Key: LUCENE-7364 > URL: https://issues.apache.org/jira/browse/LUCENE-7364 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward > > If a BooleanQuery meets certain criteria (only contains disjunctions, is > likely to match large numbers of docs) then we use a BooleanScorer to score > groups of 1024 docs at a time. This allocates arrays of 1024 Bucket objects > up-front. On very small segments (for example, a MemoryIndex) this is very > wasteful of memory, particularly if the query is large or deeply-nested. We > should avoid using a bulk scorer on these segments. -- 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-7363) DecimalDigitFilter skips chars in case of supplementary code points
[
https://issues.apache.org/jira/browse/LUCENE-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355607#comment-15355607
]
Hoss Man commented on LUCENE-7363:
--
dup of LUCENE-6914?
that issue has a fix (for the same or slightly similar bug?) and some tests,
but didn't really go anywhere because i didn't have any clue what i was doing
(i just poked it with a stick until my test passed), and rmuir (who actually
understood the code) didn't seem to like the test as i had written it and
didn't follow up with his own.
> DecimalDigitFilter skips chars in case of supplementary code points
> ---
>
> Key: LUCENE-7363
> URL: https://issues.apache.org/jira/browse/LUCENE-7363
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Attachments: LUCENE-7363.patch
>
>
> It does {{length = StemmerUtil.delete(buffer,++i, length);}} while it should
> really do {{length = StemmerUtil.delete(buffer,i+1, length);}}.
--
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-9246) Errors for Streaming Expressions using JDBC (Oracle) stream source
[
https://issues.apache.org/jira/browse/SOLR-9246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355604#comment-15355604
]
ASF subversion and git services commented on SOLR-9246:
---
Commit d1a9daec8787a3f6869bdcff282dee8b3936cf24 in lucene-solr's branch
refs/heads/branch_6x from [~dpgove]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d1a9dae ]
SOLR-9246: If the JDBCStream sees an unknown column type it will now throw a
detailed exception
> Errors for Streaming Expressions using JDBC (Oracle) stream source
> --
>
> Key: SOLR-9246
> URL: https://issues.apache.org/jira/browse/SOLR-9246
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0.1
> Environment: Windows 7
>Reporter: Hui Liu
>Assignee: Dennis Gove
> Attachments: Re Errors for Streaming Expressions using JDBC (Oracle)
> stream source.txt, SOLR-9246.patch
>
>
> I have Solr 6.0.0 installed on my PC (windows 7), I was experimenting with
> ‘Streaming Expression’ by using Oracle jdbc as the
> stream source, but got 'null pointer' errors, below is the details on how to
> reproduce this error:
> 1. create a collection 'document6' which only contain long and string data
> type,
> schema.xml for Solr collection 'document6': (newly created empty collections
> with 2 shards)
> ===
>
>
>
>
> docValues="true" />
> precisionStep="0" positionIncrementGap="0"/>
>
>
>
>
>
>omitNorms="true"/>
>
>
> multiValued="false"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
>
> document_id
> document_id
>
> 2. create a new Oracle (version 11.2.0.3) table 'document6' that only contain
> columns whose jdbc type is long and string,
> create table document6
> (document_id number(12) not null,
> sender_msg_dest varchar2(256),
> recip_msg_dest varchar2(256),
> document_type varchar2(20),
> document_keyvarchar2(100));
> loaded 9 records;
> Oracle table 'document6': (newly created Oracle table with 9 records)
> =
> QA_DOCREP@qlgdb1 > desc document6
> Name Null?Type
> -
>
> DOCUMENT_ID NOT NULL NUMBER(12)
> SENDER_MSG_DESTVARCHAR2(256)
> RECIP_MSG_DEST VARCHAR2(256)
> DOCUMENT_TYPE VARCHAR2(20)
> DOCUMENT_KEY VARCHAR2(100)
> 3. tried this jdbc streaming expression in my browser, getting the error
> stack (see below)
> http://localhost:8988/solr/document6/stream?expr=jdbc(connection="jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql="SELECT
> document_id,sender_msg_dest,recip_msg_dest,document_type,document_key FROM
> document6",sort="document_id asc",driver="oracle.jdbc.driver.OracleDriver")
> errors in solr.log
> ==
> 2016-06-23 14:07:02.833 INFO (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.S.Request
> [document6_shard2_replica1] webapp=/solr path=/stream
> params={expr=jdbc(connection%3D"jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql%3D"SELECT+document_id,sender_msg_dest,recip_msg_dest,document_type,document_key+FROM+document6",sort%3D"document_id+asc",driver%3D"oracle.jdbc.driver.OracleDriver")}
> status=0 QTime=1
> 2016-06-23 14:07:05.282 ERROR (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.s.i.s.ExceptionStream
> java.lang.NullPointerException
> at
> org.apache.solr.client.solrj.io.stream.JDBCStream.read(JDBCStream.java:305)
> at
> org.apache.solr.client.solrj.io.stream.ExceptionStream.read(ExceptionStream.java:64)
> at
> org.apache.solr.handler.StreamHandler$TimerStream.read(StreamHandler.java:374)
> at
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:305)
> at
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
> at
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
> at
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
> at
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95)
> at
> org.apache.solr.response.JS
[jira] [Commented] (SOLR-9103) Make StreamHandler extensible
[
https://issues.apache.org/jira/browse/SOLR-9103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355598#comment-15355598
]
Dennis Gove commented on SOLR-9103:
---
This ability existed in the initial patch adding Streaming Expressions
(SOLR-7377). I guess it was removed at some point, though I wonder why. Glad to
see it added back!
> Make StreamHandler extensible
> -
>
> Key: SOLR-9103
> URL: https://issues.apache.org/jira/browse/SOLR-9103
> Project: Solr
> Issue Type: Improvement
>Reporter: Cao Manh Dat
> Attachments: HelloStream.class, SOLR-9103.PATCH, SOLR-9103.PATCH
>
>
> StreamHandler is an implicit handler. So to make it extensible, we can
> introduce the below syntax in solrconfig.xml.
> {code}
>
> {code}
> This will add hello function to streamFactory of StreamHandler.
--
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-9263) New Admin gui fails to parse local params in the "Raw Query Parameters" query field
[
https://issues.apache.org/jira/browse/SOLR-9263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Sawyer updated SOLR-9263:
---
Attachment: SOLR-9263.patch
> New Admin gui fails to parse local params in the "Raw Query Parameters" query
> field
> ---
>
> Key: SOLR-9263
> URL: https://issues.apache.org/jira/browse/SOLR-9263
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: web gui
>Affects Versions: 6.0.1
>Reporter: Brian Sawyer
> Attachments: SOLR-9263.patch
>
>
> Including any local params in the "Raw Query Parameters" query field, such as
> for a rerank query
> {noformat}rq={!rerank reRankQuery=$rqq reRankDocs=1000
> reRankWeight=3}&rqq=(hi+hello+hey+hiya){noformat} results in an error:
> {noformat}
> org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError:
> Expected identifier at pos 20 str='{!rerank reRankQuery'
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:219)
> {noformat}
> It's clear that the resulting URL is malformed:
> {noformat}
> http://localhost:8983/solr/collection1/select?fl=name,%20score&indent=on&q=greetings&rq={!rerank%20reRankQuery&rqq=(hi+hello+hey+hiya)&wt=json
> {noformat}
> This appears to be due to javascript code naively splitting on '='.
> /solr/webapp/web/js/angular/controllers/query.js
> {code}
> if ($scope.rawParams) {
> var rawParams = $scope.rawParams.split(/[&\n]/);
> for (var i in rawParams) {
> var param = rawParams[i];
> var parts = param.split("=");
> }
> }
> {code}
> I've attached a possible patch.
--
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-9263) New Admin gui fails to parse local params in the "Raw Query Parameters" query field
[
https://issues.apache.org/jira/browse/SOLR-9263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Sawyer updated SOLR-9263:
---
Attachment: (was: patch.txt)
> New Admin gui fails to parse local params in the "Raw Query Parameters" query
> field
> ---
>
> Key: SOLR-9263
> URL: https://issues.apache.org/jira/browse/SOLR-9263
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: web gui
>Affects Versions: 6.0.1
>Reporter: Brian Sawyer
> Attachments: SOLR-9263.patch
>
>
> Including any local params in the "Raw Query Parameters" query field, such as
> for a rerank query
> {noformat}rq={!rerank reRankQuery=$rqq reRankDocs=1000
> reRankWeight=3}&rqq=(hi+hello+hey+hiya){noformat} results in an error:
> {noformat}
> org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError:
> Expected identifier at pos 20 str='{!rerank reRankQuery'
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:219)
> {noformat}
> It's clear that the resulting URL is malformed:
> {noformat}
> http://localhost:8983/solr/collection1/select?fl=name,%20score&indent=on&q=greetings&rq={!rerank%20reRankQuery&rqq=(hi+hello+hey+hiya)&wt=json
> {noformat}
> This appears to be due to javascript code naively splitting on '='.
> /solr/webapp/web/js/angular/controllers/query.js
> {code}
> if ($scope.rawParams) {
> var rawParams = $scope.rawParams.split(/[&\n]/);
> for (var i in rawParams) {
> var param = rawParams[i];
> var parts = param.split("=");
> }
> }
> {code}
> I've attached a possible patch.
--
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-7365) Don't use BooleanScorer for small segments
[ https://issues.apache.org/jira/browse/LUCENE-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-7365: -- Attachment: LUCENE-7365.patch Patch. This prevents use of BooleanScorer if the segment is smaller than 1024 docs. I'm not sure if that's the best cutoff though, and I'd like to do some benchmarking to check performance. > Don't use BooleanScorer for small segments > -- > > Key: LUCENE-7365 > URL: https://issues.apache.org/jira/browse/LUCENE-7365 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward > Attachments: LUCENE-7365.patch > > > If a BooleanQuery meets certain criteria (only contains disjunctions, is > likely to match large numbers of docs) then we use a BooleanScorer to score > groups of 1024 docs at a time. This allocates arrays of 1024 Bucket objects > up-front. On very small segments (for example, a MemoryIndex) this is very > wasteful of memory, particularly if the query is large or deeply-nested. We > should avoid using a bulk scorer on these segments. -- 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-9263) New Admin gui fails to parse local params in the "Raw Query Parameters" query field
[
https://issues.apache.org/jira/browse/SOLR-9263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Sawyer updated SOLR-9263:
---
Attachment: patch.txt
> New Admin gui fails to parse local params in the "Raw Query Parameters" query
> field
> ---
>
> Key: SOLR-9263
> URL: https://issues.apache.org/jira/browse/SOLR-9263
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: web gui
>Affects Versions: 6.0.1
>Reporter: Brian Sawyer
> Attachments: patch.txt
>
>
> Including any local params in the "Raw Query Parameters" query field, such as
> for a rerank query
> {noformat}rq={!rerank reRankQuery=$rqq reRankDocs=1000
> reRankWeight=3}&rqq=(hi+hello+hey+hiya){noformat} results in an error:
> {noformat}
> org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError:
> Expected identifier at pos 20 str='{!rerank reRankQuery'
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:219)
> {noformat}
> It's clear that the resulting URL is malformed:
> {noformat}
> http://localhost:8983/solr/collection1/select?fl=name,%20score&indent=on&q=greetings&rq={!rerank%20reRankQuery&rqq=(hi+hello+hey+hiya)&wt=json
> {noformat}
> This appears to be due to javascript code naively splitting on '='.
> /solr/webapp/web/js/angular/controllers/query.js
> {code}
> if ($scope.rawParams) {
> var rawParams = $scope.rawParams.split(/[&\n]/);
> for (var i in rawParams) {
> var param = rawParams[i];
> var parts = param.split("=");
> }
> }
> {code}
> I've attached a possible patch.
--
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-9263) New Admin gui fails to parse local params in the "Raw Query Parameters" query field
Brian Sawyer created SOLR-9263:
--
Summary: New Admin gui fails to parse local params in the "Raw
Query Parameters" query field
Key: SOLR-9263
URL: https://issues.apache.org/jira/browse/SOLR-9263
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: web gui
Affects Versions: 6.0.1
Reporter: Brian Sawyer
Including any local params in the "Raw Query Parameters" query field, such as
for a rerank query
{noformat}rq={!rerank reRankQuery=$rqq reRankDocs=1000
reRankWeight=3}&rqq=(hi+hello+hey+hiya){noformat} results in an error:
{noformat}
org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError:
Expected identifier at pos 20 str='{!rerank reRankQuery'
at
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:219)
{noformat}
It's clear that the resulting URL is malformed:
{noformat}
http://localhost:8983/solr/collection1/select?fl=name,%20score&indent=on&q=greetings&rq={!rerank%20reRankQuery&rqq=(hi+hello+hey+hiya)&wt=json
{noformat}
This appears to be due to javascript code naively splitting on '='.
/solr/webapp/web/js/angular/controllers/query.js
{code}
if ($scope.rawParams) {
var rawParams = $scope.rawParams.split(/[&\n]/);
for (var i in rawParams) {
var param = rawParams[i];
var parts = param.split("=");
}
}
{code}
I've attached a possible patch.
--
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-7365) Don't use BooleanScorer for small segments
Alan Woodward created LUCENE-7365: - Summary: Don't use BooleanScorer for small segments Key: LUCENE-7365 URL: https://issues.apache.org/jira/browse/LUCENE-7365 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward If a BooleanQuery meets certain criteria (only contains disjunctions, is likely to match large numbers of docs) then we use a BooleanScorer to score groups of 1024 docs at a time. This allocates arrays of 1024 Bucket objects up-front. On very small segments (for example, a MemoryIndex) this is very wasteful of memory, particularly if the query is large or deeply-nested. We should avoid using a bulk scorer on these segments. -- 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-7364) Don't use BooleanScorer for small segments
Alan Woodward created LUCENE-7364: - Summary: Don't use BooleanScorer for small segments Key: LUCENE-7364 URL: https://issues.apache.org/jira/browse/LUCENE-7364 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward If a BooleanQuery meets certain criteria (only contains disjunctions, is likely to match large numbers of docs) then we use a BooleanScorer to score groups of 1024 docs at a time. This allocates arrays of 1024 Bucket objects up-front. On very small segments (for example, a MemoryIndex) this is very wasteful of memory, particularly if the query is large or deeply-nested. We should avoid using a bulk scorer on these segments. -- 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-9246) Errors for Streaming Expressions using JDBC (Oracle) stream source
[
https://issues.apache.org/jira/browse/SOLR-9246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Gove reassigned SOLR-9246:
-
Assignee: Dennis Gove
> Errors for Streaming Expressions using JDBC (Oracle) stream source
> --
>
> Key: SOLR-9246
> URL: https://issues.apache.org/jira/browse/SOLR-9246
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0.1
> Environment: Windows 7
>Reporter: Hui Liu
>Assignee: Dennis Gove
> Attachments: Re Errors for Streaming Expressions using JDBC (Oracle)
> stream source.txt, SOLR-9246.patch
>
>
> I have Solr 6.0.0 installed on my PC (windows 7), I was experimenting with
> ‘Streaming Expression’ by using Oracle jdbc as the
> stream source, but got 'null pointer' errors, below is the details on how to
> reproduce this error:
> 1. create a collection 'document6' which only contain long and string data
> type,
> schema.xml for Solr collection 'document6': (newly created empty collections
> with 2 shards)
> ===
>
>
>
>
> docValues="true" />
> precisionStep="0" positionIncrementGap="0"/>
>
>
>
>
>
>omitNorms="true"/>
>
>
> multiValued="false"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
> docValues="true"/>
>
> document_id
> document_id
>
> 2. create a new Oracle (version 11.2.0.3) table 'document6' that only contain
> columns whose jdbc type is long and string,
> create table document6
> (document_id number(12) not null,
> sender_msg_dest varchar2(256),
> recip_msg_dest varchar2(256),
> document_type varchar2(20),
> document_keyvarchar2(100));
> loaded 9 records;
> Oracle table 'document6': (newly created Oracle table with 9 records)
> =
> QA_DOCREP@qlgdb1 > desc document6
> Name Null?Type
> -
>
> DOCUMENT_ID NOT NULL NUMBER(12)
> SENDER_MSG_DESTVARCHAR2(256)
> RECIP_MSG_DEST VARCHAR2(256)
> DOCUMENT_TYPE VARCHAR2(20)
> DOCUMENT_KEY VARCHAR2(100)
> 3. tried this jdbc streaming expression in my browser, getting the error
> stack (see below)
> http://localhost:8988/solr/document6/stream?expr=jdbc(connection="jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql="SELECT
> document_id,sender_msg_dest,recip_msg_dest,document_type,document_key FROM
> document6",sort="document_id asc",driver="oracle.jdbc.driver.OracleDriver")
> errors in solr.log
> ==
> 2016-06-23 14:07:02.833 INFO (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.S.Request
> [document6_shard2_replica1] webapp=/solr path=/stream
> params={expr=jdbc(connection%3D"jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql%3D"SELECT+document_id,sender_msg_dest,recip_msg_dest,document_type,document_key+FROM+document6",sort%3D"document_id+asc",driver%3D"oracle.jdbc.driver.OracleDriver")}
> status=0 QTime=1
> 2016-06-23 14:07:05.282 ERROR (qtp1389647288-139) [c:document6 s:shard2
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.s.i.s.ExceptionStream
> java.lang.NullPointerException
> at
> org.apache.solr.client.solrj.io.stream.JDBCStream.read(JDBCStream.java:305)
> at
> org.apache.solr.client.solrj.io.stream.ExceptionStream.read(ExceptionStream.java:64)
> at
> org.apache.solr.handler.StreamHandler$TimerStream.read(StreamHandler.java:374)
> at
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:305)
> at
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
> at
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
> at
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
> at
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95)
> at
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:60)
> at
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:725)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:469)
> at
> o
[jira] [Commented] (SOLR-9216) Support collection.configName in MODIFYCOLLECTION request
[
https://issues.apache.org/jira/browse/SOLR-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355533#comment-15355533
]
Noble Paul commented on SOLR-9216:
--
Yeah, the testcase is the problem. RulesTest is not the right place to do it.
We should add it elsewhere
> Support collection.configName in MODIFYCOLLECTION request
> -
>
> Key: SOLR-9216
> URL: https://issues.apache.org/jira/browse/SOLR-9216
> Project: Solr
> Issue Type: Improvement
>Reporter: Keith Laban
>Assignee: Noble Paul
> Attachments: SOLR-9216.patch
>
>
> MODIFYCOLLECTION should support updating the
> {{/collections/}} value of "configName" in zookeeper
--
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-8657) SolrRequestInfo logs an error if QuerySenderListener is being used
[
https://issues.apache.org/jira/browse/SOLR-8657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe resolved SOLR-8657.
-
Resolution: Fixed
Fix Version/s: master (7.0)
6.2
> SolrRequestInfo logs an error if QuerySenderListener is being used
> --
>
> Key: SOLR-8657
> URL: https://issues.apache.org/jira/browse/SOLR-8657
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.4.1
>Reporter: Pascal Chollet
>Assignee: Tomás Fernández Löbbe
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-8657.patch, SOLR-8657.patch, Screen Shot 2016-02-10
> at 09.43.56.png
>
>
> This is the stack trace:
> {code}
> at
> org.apache.solr.request.SolrRequestInfo.setRequestInfo(SolrRequestInfo.java:59)
> at
> org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:68)
> at org.apache.solr.core.SolrCore$6.call(SolrCore.java:1859)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:232)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> SolrRequestInfo is being set in MDCAwareThreadPoolExecutor.execute() and
> later in QuerySenderListener.newSearcher() in the same thread.
--
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-6.x-Solaris (64bit/jdk1.8.0) - Build # 230 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/230/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestSolrConfigHandlerCloud Error Message: 1 thread leaked from SUITE scope at org.apache.solr.handler.TestSolrConfigHandlerCloud: 1) Thread[id=22984, name=Thread-8447, state=TIMED_WAITING, group=TGRP-TestSolrConfigHandlerCloud] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101) at org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:333) at org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48) at org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75) at org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:107) at org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:78) at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:920) at org.apache.solr.core.SolrCore.lambda$getConfListener$6(SolrCore.java:2509) at org.apache.solr.core.SolrCore$$Lambda$49/369706141.run(Unknown Source) at org.apache.solr.cloud.ZkController$4.run(ZkController.java:2443) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.handler.TestSolrConfigHandlerCloud: 1) Thread[id=22984, name=Thread-8447, state=TIMED_WAITING, group=TGRP-TestSolrConfigHandlerCloud] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101) at org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:333) at org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48) at org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75) at org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:107) at org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:78) at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:920) at org.apache.solr.core.SolrCore.lambda$getConfListener$6(SolrCore.java:2509) at org.apache.solr.core.SolrCore$$Lambda$49/369706141.run(Unknown Source) at org.apache.solr.cloud.ZkController$4.run(ZkController.java:2443) at __randomizedtesting.SeedInfo.seed([FD70622AFD7EF674]:0) Build Log: [...truncated 12214 lines...] [junit4] Suite: org.apache.solr.handler.TestSolrConfigHandlerCloud [junit4] 2> Creating dataDir: /export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J1/temp/solr.handler.TestSolrConfigHandlerCloud_FD70622AFD7EF674-001/init-core-data-001 [junit4] 2> 3619312 INFO (SUITE-TestSolrConfigHandlerCloud-seed#[FD70622AFD7EF674]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN) [junit4] 2> 3619312 INFO (SUITE-TestSolrConfigHandlerCloud-seed#[FD70622AFD7EF674]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2> 3619316 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[FD70622AFD7EF674]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 3619316 INFO (Thread-8232) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 3619318 INFO (Thread-8232) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 3619416 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[FD70622AFD7EF674]) [] o.a.s.c.ZkTestServer start zk server on port:49020 [junit4] 2> 3619417 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[FD70622AFD7EF674]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 3619418 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[FD70622AFD7EF674]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 3619420 INFO (zkCallback-3526-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@7fa4c283 name:ZooKeeperConnection Watcher:127.0.0.1:49020 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 3619420 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[FD70622AFD7EF674]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 3619421 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[FD70622AFD7EF674]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 3619421 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[FD70622AFD7EF674]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2> 3619
[jira] [Commented] (SOLR-9262) Connection and read timeouts are being ignored by UpdateShardHandler
[ https://issues.apache.org/jira/browse/SOLR-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355444#comment-15355444 ] Shalin Shekhar Mangar commented on SOLR-9262: - Hi [~markrmil...@gmail.com], I've put back the retry in this patch which was initially added in SOLR-6931 and later removed by SOLR-4509. I am assuming that that was an oversight and the retry is in fact necessary. Can you please take a quick look and confirm? > Connection and read timeouts are being ignored by UpdateShardHandler > > > Key: SOLR-9262 > URL: https://issues.apache.org/jira/browse/SOLR-9262 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (7.0) >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: master (7.0) > > Attachments: SOLR-9262.patch > > > SOLR-4509 removed the usage of distribUpdateSoTimeout and > distribUpdateConnTimeout from UpdateShardHandler causing the http client to > be created with its default values of connection and read timeout. > https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java;h=4fe869c25c9ea0588903d8d366e8d3533835b601;hp=a44b8f87b766d4f998d534156ceb83f4d42eadbb;hb=ce172ac;hpb=3f217aba6d4422d829be5ad77b02068c130dc7d3 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9154) Config API does not work when adding a component with DirectSolrSpellChecker
[
https://issues.apache.org/jira/browse/SOLR-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355332#comment-15355332
]
Alex D edited comment on SOLR-9154 at 6/29/16 3:24 PM:
---
Would it be possible to convert the config variable to a SolrParams (e.g.:
using SolrParams.toSolrParams)? This way you could use get* methods instead of
parsing the string yourself.
was (Author: alexandre.drouin):
Would it be possible to convert the config variable to a SolrParams (e.g.:
using SolrParams.toSolrParams)? This way you could use getField* methods
instead of parsing the string yourself.
> Config API does not work when adding a component with DirectSolrSpellChecker
>
>
> Key: SOLR-9154
> URL: https://issues.apache.org/jira/browse/SOLR-9154
> Project: Solr
> Issue Type: Bug
> Components: config-api, spellchecker
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9154.patch
>
>
> When trying to add a DirectSolrSpellchecker using the Config API (JSON),
> there seems to be a loss of information w.r.t the param types. The accuracy
> field, only in this specific case needs to be defined as a float it seems.
> While this is possible when updating the solrconfig,xml directly, the field
> type (float) can not be specified using JSON.
> Here are the steps to reproduce this issue:
> {code}
> #Bootstrapping
> bin/solr start -c
> bin/solr create -c foo
> bin/post -c foo example/exampledocs/books.csv
> #Add spell checker - This would hang and the logs contain recurring
> exceptions as mentioned below
> curl http://localhost:8983/solr/foo/config -H 'Content-type:application/json'
> -d '{"update-searchcomponent": {"name":"spellcheck",
> "class":"solr.SpellCheckComponent", "spellchecker":[ {
> "name":"text_index_dictionary", "field":"text",
> "classname":"solr.DirectSolrSpellChecker",
> "distanceMeasure":"org.apache.lucene.search.spell.LevensteinDistance",
> "accuracy":0.5, "maxEdits":2, "minPrefix":1, "maxInspections":5,
> "minQueryLength":4, "maxQueryFrequency":0.001,
> "thresholdTokenFrequency":0.01}]}}'
> {code}
> Log:
> {code}
> 2016-05-24 04:08:44.371 ERROR (SolrConfigHandler-refreshconf) [c:foo s:shard1
> r:core_node1 x:foo_shard1_replica1] o.a.s.h.SolrConfigHandler Unable to
> refresh conf
> org.apache.solr.common.SolrException: Unable to reload core
> [foo_shard1_replica1]
> at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:944)
> at
> org.apache.solr.core.SolrCore.lambda$getConfListener$7(SolrCore.java:2510)
> at
> org.apache.solr.handler.SolrConfigHandler$Command$1.run(SolrConfigHandler.java:218)
> Caused by: org.apache.solr.common.SolrException: java.lang.Double cannot be
> cast to java.lang.Float
> at org.apache.solr.core.SolrCore.(SolrCore.java:773)
> at org.apache.solr.core.SolrCore.reload(SolrCore.java:462)
> at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:938)
> {code}
--
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-5944) Support updates of numeric DocValues
[ https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-5944: --- Attachment: SOLR-5944.patch New patch: # Addressed most of code level comments from Hoss. I think the readability of the code has now improved and also more robust exception handling. (Thanks Hoss). I shall reply inline to all of your suggestions, perhaps along with my next patch. # Nocommits remain, I think these are all related to Javadocs. # Stress test now has DBQ and DBI. It seems to pass 1000 runs successfully. # PeerSync, TestReplay etc. and a few more unit tests remain. > Support updates of numeric DocValues > > > Key: SOLR-5944 > URL: https://issues.apache.org/jira/browse/SOLR-5944 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Shalin Shekhar Mangar > Attachments: DUP.patch, SOLR-5944.patch, SOLR-5944.patch, > SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, > SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, > SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, > SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, > SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, > SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, > SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, > SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, > TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, > TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, > TestStressInPlaceUpdates.eb044ac71.failures.tar.gz, > hoss.62D328FA1DEA57FD.fail.txt, hoss.62D328FA1DEA57FD.fail2.txt, > hoss.62D328FA1DEA57FD.fail3.txt, hoss.D768DD9443A98DC.fail.txt, > hoss.D768DD9443A98DC.pass.txt > > > LUCENE-5189 introduced support for updates to numeric docvalues. It would be > really nice to have Solr support this. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9154) Config API does not work when adding a component with DirectSolrSpellChecker
[
https://issues.apache.org/jira/browse/SOLR-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355332#comment-15355332
]
Alex D commented on SOLR-9154:
--
Would it be possible to convert the config variable to a SolrParams (e.g.:
using SolrParams.toSolrParams)? This way you could use getField* methods
instead of parsing the string yourself.
> Config API does not work when adding a component with DirectSolrSpellChecker
>
>
> Key: SOLR-9154
> URL: https://issues.apache.org/jira/browse/SOLR-9154
> Project: Solr
> Issue Type: Bug
> Components: config-api, spellchecker
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9154.patch
>
>
> When trying to add a DirectSolrSpellchecker using the Config API (JSON),
> there seems to be a loss of information w.r.t the param types. The accuracy
> field, only in this specific case needs to be defined as a float it seems.
> While this is possible when updating the solrconfig,xml directly, the field
> type (float) can not be specified using JSON.
> Here are the steps to reproduce this issue:
> {code}
> #Bootstrapping
> bin/solr start -c
> bin/solr create -c foo
> bin/post -c foo example/exampledocs/books.csv
> #Add spell checker - This would hang and the logs contain recurring
> exceptions as mentioned below
> curl http://localhost:8983/solr/foo/config -H 'Content-type:application/json'
> -d '{"update-searchcomponent": {"name":"spellcheck",
> "class":"solr.SpellCheckComponent", "spellchecker":[ {
> "name":"text_index_dictionary", "field":"text",
> "classname":"solr.DirectSolrSpellChecker",
> "distanceMeasure":"org.apache.lucene.search.spell.LevensteinDistance",
> "accuracy":0.5, "maxEdits":2, "minPrefix":1, "maxInspections":5,
> "minQueryLength":4, "maxQueryFrequency":0.001,
> "thresholdTokenFrequency":0.01}]}}'
> {code}
> Log:
> {code}
> 2016-05-24 04:08:44.371 ERROR (SolrConfigHandler-refreshconf) [c:foo s:shard1
> r:core_node1 x:foo_shard1_replica1] o.a.s.h.SolrConfigHandler Unable to
> refresh conf
> org.apache.solr.common.SolrException: Unable to reload core
> [foo_shard1_replica1]
> at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:944)
> at
> org.apache.solr.core.SolrCore.lambda$getConfListener$7(SolrCore.java:2510)
> at
> org.apache.solr.handler.SolrConfigHandler$Command$1.run(SolrConfigHandler.java:218)
> Caused by: org.apache.solr.common.SolrException: java.lang.Double cannot be
> cast to java.lang.Float
> at org.apache.solr.core.SolrCore.(SolrCore.java:773)
> at org.apache.solr.core.SolrCore.reload(SolrCore.java:462)
> at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:938)
> {code}
--
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-7363) DecimalDigitFilter skips chars in case of supplementary code points
[
https://issues.apache.org/jira/browse/LUCENE-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355288#comment-15355288
]
Steve Rowe commented on LUCENE-7363:
+1, tricky since the loop control variable is over a shrinking series.
> DecimalDigitFilter skips chars in case of supplementary code points
> ---
>
> Key: LUCENE-7363
> URL: https://issues.apache.org/jira/browse/LUCENE-7363
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Attachments: LUCENE-7363.patch
>
>
> It does {{length = StemmerUtil.delete(buffer,++i, length);}} while it should
> really do {{length = StemmerUtil.delete(buffer,i+1, length);}}.
--
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-Artifacts-master - Build # 3016 - Failure
Build: https://builds.apache.org/job/Lucene-Artifacts-master/3016/ No tests ran. Build Log: [...truncated 8128 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-master/lucene/build.xml:359: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-master/lucene/common-build.xml:2496: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-master/lucene/build/src-export/lucene/docs/changes/jiraVersionList.json Total time: 4 minutes 22 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Compressed 139.19 MB of artifacts by 25.8% relative to #3015 Publishing Javadoc Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7361) Terms.toStringDebug
[ https://issues.apache.org/jira/browse/LUCENE-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355259#comment-15355259 ] Alan Woodward commented on LUCENE-7361: --- I agree with Robert here - toString() is used in things like IDE debugging windows, what happens if I run a debugging session on a 2Gb index? Having some kind of introspector on an index could be useful, though, so maybe instead of adding .toString() implementations, we have a special class in misc/ that prints this information out? And then MemoryIndex.toString() can just include some top-level stats, and users get pointed to the introspector for more detailed debugging info. > Terms.toStringDebug > --- > > Key: LUCENE-7361 > URL: https://issues.apache.org/jira/browse/LUCENE-7361 > Project: Lucene - Core > Issue Type: Improvement >Reporter: David Smiley > Attachments: MemoryIndexToString.java > > > While fixing LUCENE-7340, MemoryIndex.toString(), I thought MemoryIndex > shouldn't need it's own debug toString() impl for its Terms when there could > be a generic one. So here I propose that we create a > Terms.toStringDebug(Appendable result, int charLimit, String indent) or > some-such but probably not override toString() for obvious reasons. Maybe > also have this on Fields() that simply loops and calls out to the one on > Terms. > The format is debatable. -- 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-7363) DecimalDigitFilter skips chars in case of supplementary code points
[
https://issues.apache.org/jira/browse/LUCENE-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-7363:
-
Attachment: LUCENE-7363.patch
Here is a simple patch.
> DecimalDigitFilter skips chars in case of supplementary code points
> ---
>
> Key: LUCENE-7363
> URL: https://issues.apache.org/jira/browse/LUCENE-7363
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Attachments: LUCENE-7363.patch
>
>
> It does {{length = StemmerUtil.delete(buffer,++i, length);}} while it should
> really do {{length = StemmerUtil.delete(buffer,i+1, length);}}.
--
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-7363) DecimalDigitFilter skips chars in case of supplementary code points
Adrien Grand created LUCENE-7363:
Summary: DecimalDigitFilter skips chars in case of supplementary
code points
Key: LUCENE-7363
URL: https://issues.apache.org/jira/browse/LUCENE-7363
Project: Lucene - Core
Issue Type: Bug
Reporter: Adrien Grand
Assignee: Adrien Grand
It does {{length = StemmerUtil.delete(buffer,++i, length);}} while it should
really do {{length = StemmerUtil.delete(buffer,i+1, length);}}.
--
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-7362) Implement FieldInfos and FieldInfo toString()
[ https://issues.apache.org/jira/browse/LUCENE-7362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355210#comment-15355210 ] Robert Muir commented on LUCENE-7362: - I do not think they should. These are low level structures: i think the current toString is just fine, e.g. to know you have the right one in indexwriter and so on. I think this is also relevant to LUCENE-7361. MemoryIndex is a toy 1 document thing, we should not add dangerous things to low level lucene structures (like loops over fields) that will blow up. I also do not care at all for the magical coded flags that solr uses here. The current toString is more useful to me than that, so it would just lose usefulness. If we want FieldInfo *not plural* to have a different toString it should simply print out all of the flags by name and value with no screwing around. > Implement FieldInfos and FieldInfo toString() > - > > Key: LUCENE-7362 > URL: https://issues.apache.org/jira/browse/LUCENE-7362 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: David Smiley > > FieldInfos and FieldInfo ought to override toString(). Perhaps > FieldInfo.toString() can look like the pattern popularized by Luke, also seen > in Solr? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7361) Terms.toStringDebug
[ https://issues.apache.org/jira/browse/LUCENE-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355204#comment-15355204 ] Robert Muir commented on LUCENE-7361: - No, I am against this. Its only a matter of time before a debugging message in infostream becomes a horrible performance bug or similar. sorry. MemoryIndex is a 1 document toy, it can do whatever it wants. > Terms.toStringDebug > --- > > Key: LUCENE-7361 > URL: https://issues.apache.org/jira/browse/LUCENE-7361 > Project: Lucene - Core > Issue Type: Improvement >Reporter: David Smiley > Attachments: MemoryIndexToString.java > > > While fixing LUCENE-7340, MemoryIndex.toString(), I thought MemoryIndex > shouldn't need it's own debug toString() impl for its Terms when there could > be a generic one. So here I propose that we create a > Terms.toStringDebug(Appendable result, int charLimit, String indent) or > some-such but probably not override toString() for obvious reasons. Maybe > also have this on Fields() that simply loops and calls out to the one on > Terms. > The format is debatable. -- 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-9216) Support collection.configName in MODIFYCOLLECTION request
[
https://issues.apache.org/jira/browse/SOLR-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355198#comment-15355198
]
Noble Paul commented on SOLR-9216:
--
Sorry, lost track. I shall review it today
> Support collection.configName in MODIFYCOLLECTION request
> -
>
> Key: SOLR-9216
> URL: https://issues.apache.org/jira/browse/SOLR-9216
> Project: Solr
> Issue Type: Improvement
>Reporter: Keith Laban
>Assignee: Noble Paul
> Attachments: SOLR-9216.patch
>
>
> MODIFYCOLLECTION should support updating the
> {{/collections/}} value of "configName" in zookeeper
--
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-9216) Support collection.configName in MODIFYCOLLECTION request
[
https://issues.apache.org/jira/browse/SOLR-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-9216:
Assignee: Noble Paul
> Support collection.configName in MODIFYCOLLECTION request
> -
>
> Key: SOLR-9216
> URL: https://issues.apache.org/jira/browse/SOLR-9216
> Project: Solr
> Issue Type: Improvement
>Reporter: Keith Laban
>Assignee: Noble Paul
> Attachments: SOLR-9216.patch
>
>
> MODIFYCOLLECTION should support updating the
> {{/collections/}} value of "configName" in zookeeper
--
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-9234) srcField works only when all fields are captured in the /update/json/docs endpoint
[
https://issues.apache.org/jira/browse/SOLR-9234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355193#comment-15355193
]
ASF subversion and git services commented on SOLR-9234:
---
Commit 455e041c68106a9fc7d395a6a327aee6f221d1db in lucene-solr's branch
refs/heads/branch_6x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=455e041 ]
Put back 6.2 bugfixes released in 5.5.2: SOLR-9191 and SOLR-9234
> srcField works only when all fields are captured in the /update/json/docs
> endpoint
> --
>
> Key: SOLR-9234
> URL: https://issues.apache.org/jira/browse/SOLR-9234
> Project: Solr
> Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.5.2, 6.2
>
> Attachments: SOLR-9234.patch
>
>
> {code}
> $ cat ~/Desktop/nested.json
> {
> "id" : "123",
> "description": "Testing /json/docs srcField",
> "nested_data" : {
> "nested_inside" : "check check check"
> }
> }
> $ curl
> "http://localhost:8983/solr/test/update/json/docs?srcField=original_json_s&split=/&f=description_s:/descriptio&f=id:/id&commit=true&echo=true";
> -H "Content-type:application/json" -d @/Users/erikhatcher/Desktop/nested.json
> {"responseHeader":{"status":0,"QTime":1},"docs":[{"id":"123","description_s":"Testing
> /json/docs srcField","original_json_s":"{ \"id\" : \"123\",
> \"description\": \"Testing /json/docs srcField\", \"nested_data\" : {\"
> : \" }}"}]}
> {code}
--
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-9191) OverseerTaskQueue.peekTopN() fatally flawed
[ https://issues.apache.org/jira/browse/SOLR-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355192#comment-15355192 ] ASF subversion and git services commented on SOLR-9191: --- Commit 455e041c68106a9fc7d395a6a327aee6f221d1db in lucene-solr's branch refs/heads/branch_6x from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=455e041 ] Put back 6.2 bugfixes released in 5.5.2: SOLR-9191 and SOLR-9234 > OverseerTaskQueue.peekTopN() fatally flawed > --- > > Key: SOLR-9191 > URL: https://issues.apache.org/jira/browse/SOLR-9191 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4, 5.4.1, 5.5, 5.5.1, 6.0, 6.0.1 >Reporter: Scott Blum >Assignee: Scott Blum >Priority: Blocker > Fix For: 5.5.2, 5.6, 6.0.2, 6.1, 6.2, master (7.0) > > Original Estimate: 24h > Remaining Estimate: 24h > > We rewrote DistributedQueue in SOLR-6760, to optimize its obvious use case as > a FIFO. But in doing so, we broke the assumptions in > OverseerTaskQueue.peekTopN().. > OverseerTaskQueue.peekTopN() involves filtering out items you're already > working on, it's trying to peek for new items in the queue beyond what you > already know about. But DistributedQueue (being designed as a FIFO) doesn't > know about the filtering; as long as it has any items in-memory it just keeps > returning those over and over without ever pulling new data from ZK. This is > true even if the watcher has fired and marked the state as dirty. So > OverseerTaskQueue gets into a state where it can never read new items in ZK > because DQ keeps returning the same items that it has marked as in-progress. -- 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-9191) OverseerTaskQueue.peekTopN() fatally flawed
[ https://issues.apache.org/jira/browse/SOLR-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355191#comment-15355191 ] ASF subversion and git services commented on SOLR-9191: --- Commit 7a8be182784bf26935435ac51839e70a1c045f1b in lucene-solr's branch refs/heads/master from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7a8be18 ] Put back 6.2 bugfix released in 5.5.2: SOLR-9191 > OverseerTaskQueue.peekTopN() fatally flawed > --- > > Key: SOLR-9191 > URL: https://issues.apache.org/jira/browse/SOLR-9191 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4, 5.4.1, 5.5, 5.5.1, 6.0, 6.0.1 >Reporter: Scott Blum >Assignee: Scott Blum >Priority: Blocker > Fix For: 5.5.2, 5.6, 6.0.2, 6.1, 6.2, master (7.0) > > Original Estimate: 24h > Remaining Estimate: 24h > > We rewrote DistributedQueue in SOLR-6760, to optimize its obvious use case as > a FIFO. But in doing so, we broke the assumptions in > OverseerTaskQueue.peekTopN().. > OverseerTaskQueue.peekTopN() involves filtering out items you're already > working on, it's trying to peek for new items in the queue beyond what you > already know about. But DistributedQueue (being designed as a FIFO) doesn't > know about the filtering; as long as it has any items in-memory it just keeps > returning those over and over without ever pulling new data from ZK. This is > true even if the watcher has fired and marked the state as dirty. So > OverseerTaskQueue gets into a state where it can never read new items in ZK > because DQ keeps returning the same items that it has marked as in-progress. -- 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-9234) srcField works only when all fields are captured in the /update/json/docs endpoint
[
https://issues.apache.org/jira/browse/SOLR-9234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355171#comment-15355171
]
Steve Rowe commented on SOLR-9234:
--
I removed it from the 6.2 section; I'll put it back.
> srcField works only when all fields are captured in the /update/json/docs
> endpoint
> --
>
> Key: SOLR-9234
> URL: https://issues.apache.org/jira/browse/SOLR-9234
> Project: Solr
> Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.5.2, 6.2
>
> Attachments: SOLR-9234.patch
>
>
> {code}
> $ cat ~/Desktop/nested.json
> {
> "id" : "123",
> "description": "Testing /json/docs srcField",
> "nested_data" : {
> "nested_inside" : "check check check"
> }
> }
> $ curl
> "http://localhost:8983/solr/test/update/json/docs?srcField=original_json_s&split=/&f=description_s:/descriptio&f=id:/id&commit=true&echo=true";
> -H "Content-type:application/json" -d @/Users/erikhatcher/Desktop/nested.json
> {"responseHeader":{"status":0,"QTime":1},"docs":[{"id":"123","description_s":"Testing
> /json/docs srcField","original_json_s":"{ \"id\" : \"123\",
> \"description\": \"Testing /json/docs srcField\", \"nested_data\" : {\"
> : \" }}"}]}
> {code}
--
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-6.x-Linux (32bit/jdk1.8.0_92) - Build # 999 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/999/ Java: 32bit/jdk1.8.0_92 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.common.cloud.TestCollectionStateWatchers.testSimpleCollectionWatch Error Message: CollectionStateWatcher wasn't cleared after completion Stack Trace: java.lang.AssertionError: CollectionStateWatcher wasn't cleared after completion at __randomizedtesting.SeedInfo.seed([D2E0891DB4CC3587:8FDB466DF3C1AAB9]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.common.cloud.TestCollectionStateWatchers.testSimpleCollectionWatch(TestCollectionStateWatchers.java:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 13267 lines...] [junit4] Suite: org.apache.solr.common.cloud.TestCollectionStateWatchers [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-6.x-Linux/so
[jira] [Resolved] (SOLR-8777) Duplicate Solr process can cripple a running process
[ https://issues.apache.org/jira/browse/SOLR-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-8777. - Resolution: Fixed Assignee: Shalin Shekhar Mangar Fix Version/s: master (7.0) 6.2 Thanks Jessica and Scott! > Duplicate Solr process can cripple a running process > > > Key: SOLR-8777 > URL: https://issues.apache.org/jira/browse/SOLR-8777 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.3.1 >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 6.2, master (7.0) > > Attachments: SOLR-8777.patch, SOLR-8777.patch > > > Thanks to [~mewmewball] for catching this one. > Accidentally executing the same instance of Solr twice causes the second > start instance to die with an "Address already in use", but not before > deleting the first instance's live_node entry, emitting "Found a previous > node that still exists while trying to register a new live node - > removing existing node to create another". > The second start instance dies and its ephemeral node is then removed, > causing /live_nodes/ to be empty since the first start instance's > live_node was deleted by the second. -- 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-8777) Duplicate Solr process can cripple a running process
[ https://issues.apache.org/jira/browse/SOLR-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355082#comment-15355082 ] ASF subversion and git services commented on SOLR-8777: --- Commit 812fd346f7a136ccfe550a6ba0d7b0e634d68769 in lucene-solr's branch refs/heads/branch_6x from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=812fd34 ] SOLR-8777: Duplicate Solr process can cripple a running process (cherry picked from commit 4ea95bf) > Duplicate Solr process can cripple a running process > > > Key: SOLR-8777 > URL: https://issues.apache.org/jira/browse/SOLR-8777 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.3.1 >Reporter: Shalin Shekhar Mangar > Attachments: SOLR-8777.patch, SOLR-8777.patch > > > Thanks to [~mewmewball] for catching this one. > Accidentally executing the same instance of Solr twice causes the second > start instance to die with an "Address already in use", but not before > deleting the first instance's live_node entry, emitting "Found a previous > node that still exists while trying to register a new live node - > removing existing node to create another". > The second start instance dies and its ephemeral node is then removed, > causing /live_nodes/ to be empty since the first start instance's > live_node was deleted by the second. -- 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-9234) srcField works only when all fields are captured in the /update/json/docs endpoint
[
https://issues.apache.org/jira/browse/SOLR-9234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355080#comment-15355080
]
Shalin Shekhar Mangar commented on SOLR-9234:
-
On branch_6x, this issue is only mentioned in the 5.5.2 section. It should also
be in the 6.2 section.
> srcField works only when all fields are captured in the /update/json/docs
> endpoint
> --
>
> Key: SOLR-9234
> URL: https://issues.apache.org/jira/browse/SOLR-9234
> Project: Solr
> Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.5.2, 6.2
>
> Attachments: SOLR-9234.patch
>
>
> {code}
> $ cat ~/Desktop/nested.json
> {
> "id" : "123",
> "description": "Testing /json/docs srcField",
> "nested_data" : {
> "nested_inside" : "check check check"
> }
> }
> $ curl
> "http://localhost:8983/solr/test/update/json/docs?srcField=original_json_s&split=/&f=description_s:/descriptio&f=id:/id&commit=true&echo=true";
> -H "Content-type:application/json" -d @/Users/erikhatcher/Desktop/nested.json
> {"responseHeader":{"status":0,"QTime":1},"docs":[{"id":"123","description_s":"Testing
> /json/docs srcField","original_json_s":"{ \"id\" : \"123\",
> \"description\": \"Testing /json/docs srcField\", \"nested_data\" : {\"
> : \" }}"}]}
> {code}
--
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-6.x - Build # 295 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/295/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestMiniSolrCloudClusterSSL Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.TestMiniSolrCloudClusterSSL: 1) Thread[id=71553, name=OverseerHdfsCoreFailoverThread-96154418505187337-127.0.0.1:57004_solr-n_02, state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.TestMiniSolrCloudClusterSSL: 1) Thread[id=71553, name=OverseerHdfsCoreFailoverThread-96154418505187337-127.0.0.1:57004_solr-n_02, state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([A6CC7C99A6B69CB2]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestMiniSolrCloudClusterSSL Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=71553, name=OverseerHdfsCoreFailoverThread-96154418505187337-127.0.0.1:57004_solr-n_02, state=RUNNABLE, group=Overseer Hdfs SolrCore Failover Thread.] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=71553, name=OverseerHdfsCoreFailoverThread-96154418505187337-127.0.0.1:57004_solr-n_02, state=RUNNABLE, group=Overseer Hdfs SolrCore Failover Thread.] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([A6CC7C99A6B69CB2]:0) Build Log: [...truncated 12151 lines...] [junit4] Suite: org.apache.solr.cloud.TestMiniSolrCloudClusterSSL [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/build/solr-core/test/J0/temp/solr.cloud.TestMiniSolrCloudClusterSSL_A6CC7C99A6B69CB2-001/init-core-data-001 [junit4] 2> 1831328 WARN (SUITE-TestMiniSolrCloudClusterSSL-seed#[A6CC7C99A6B69CB2]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=6 numCloses=6 [junit4] 2> 1831330 INFO (SUITE-TestMiniSolrCloudClusterSSL-seed#[A6CC7C99A6B69CB2]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN) [junit4] 2> 1831331 INFO (TEST-TestMiniSolrCloudClusterSSL.testSslAndClientAuth-seed#[A6CC7C99A6B69CB2]) [] o.a.s.SolrTestCaseJ4 ###Starting testSslAndClientAuth [junit4] 2> 1831331 INFO (TEST-TestMiniSolrCloudClusterSSL.testSslAndClientAuth-seed#[A6CC7C99A6B69CB2]) [] o.a.s.c.TestMiniSolrCloudClusterSSL NOTE: This Test ignores the randomized SSL & clientAuth settings selected by base class [junit4] 2> 1831332 INFO (TEST-TestMiniSolrCloudClusterSSL.testSslAndClientAuth-seed#[A6CC7C99A6B69CB2]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 1831332 INFO (Thread-8214) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 1831332 INFO (Thread-8214) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 1831432 INFO (TEST-TestMiniSolrCloudClusterSSL.testSslAndClientAuth-seed#[A6CC7C99A6B69CB2]) [] o.a.s.c.ZkTestServer start zk server on port:42653 [junit4] 2> 1831433 INFO (TEST-TestMiniSolrCloudClusterSSL.testSslAndClientAuth-seed#[A6CC7C99A6B69CB2]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 1831433 INFO (TEST-TestMiniSolrCloudClusterSSL.testSslAndClientAuth-seed#[A6CC7C99A6B69CB2]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 1831435 INFO (zkCallback-17212-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@4bc9c283 name:ZooKeeperConnection Watcher:127.0.0.1:42653 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 1831435 INFO (TEST-TestMiniSolrCloudClusterSSL.testSslAndClientAuth-seed#[A6CC7C99A6B69CB2]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 18
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 17094 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17094/ Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.schema.TestManagedSchemaAPI.test Error Message: Error from server at http://127.0.0.1:45762/solr/testschemaapi_shard1_replica2: ERROR: [doc=2] unknown field 'myNewField1' Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at http://127.0.0.1:45762/solr/testschemaapi_shard1_replica2: ERROR: [doc=2] unknown field 'myNewField1' at __randomizedtesting.SeedInfo.seed([337245714D24C5BF:BB267AABE3D8A847]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:697) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1109) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934) at org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86) at org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRu
[jira] [Updated] (SOLR-9262) Connection and read timeouts are being ignored by UpdateShardHandler
[ https://issues.apache.org/jira/browse/SOLR-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-9262: Attachment: SOLR-9262.patch Trivial fix > Connection and read timeouts are being ignored by UpdateShardHandler > > > Key: SOLR-9262 > URL: https://issues.apache.org/jira/browse/SOLR-9262 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (7.0) >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: master (7.0) > > Attachments: SOLR-9262.patch > > > SOLR-4509 removed the usage of distribUpdateSoTimeout and > distribUpdateConnTimeout from UpdateShardHandler causing the http client to > be created with its default values of connection and read timeout. > https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java;h=4fe869c25c9ea0588903d8d366e8d3533835b601;hp=a44b8f87b766d4f998d534156ceb83f4d42eadbb;hb=ce172ac;hpb=3f217aba6d4422d829be5ad77b02068c130dc7d3 -- 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-4509) Move to non deprecated HttpClient impl classes to remove stale connection check on every request and move connection lifecycle management towards the client.
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355032#comment-15355032 ] Shalin Shekhar Mangar commented on SOLR-4509: - This has broken support for specifying connection and read timeout values for UpdateShardHandler's http client. I opened SOLR-9262 to fix. > Move to non deprecated HttpClient impl classes to remove stale connection > check on every request and move connection lifecycle management towards the > client. > - > > Key: SOLR-4509 > URL: https://issues.apache.org/jira/browse/SOLR-4509 > Project: Solr > Issue Type: Improvement > Environment: 5 node SmartOS cluster (all nodes living in same global > zone - i.e. same physical machine) >Reporter: Ryan Zezeski >Assignee: Mark Miller >Priority: Minor > Fix For: master (7.0) > > Attachments: > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > IsStaleTime.java, SOLR-4509-4_4_0.patch, SOLR-4509.patch, SOLR-4509.patch, > SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, > SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, > baremetal-stale-nostale-med-latency.dat, > baremetal-stale-nostale-med-latency.svg, > baremetal-stale-nostale-throughput.dat, baremetal-stale-nostale-throughput.svg > > > By disabling the Apache HTTP Client stale check I've witnessed a 2-4x > increase in throughput and reduction of over 100ms. This patch was made in > the context of a project I'm leading, called Yokozuna, which relies on > distributed search. > Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 > Here's a write-up I did on my findings: > http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html > I'm happy to answer any questions or make changes to the patch to make it > acceptable. > ReviewBoard: https://reviews.apache.org/r/28393/ -- 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-9262) Connection and read timeouts are being ignored by UpdateShardHandler
Shalin Shekhar Mangar created SOLR-9262: --- Summary: Connection and read timeouts are being ignored by UpdateShardHandler Key: SOLR-9262 URL: https://issues.apache.org/jira/browse/SOLR-9262 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Affects Versions: master (7.0) Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: master (7.0) SOLR-4509 removed the usage of distribUpdateSoTimeout and distribUpdateConnTimeout from UpdateShardHandler causing the http client to be created with its default values of connection and read timeout. https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java;h=4fe869c25c9ea0588903d8d366e8d3533835b601;hp=a44b8f87b766d4f998d534156ceb83f4d42eadbb;hb=ce172ac;hpb=3f217aba6d4422d829be5ad77b02068c130dc7d3 -- 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-6.x - Build # 105 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/105/ 1 tests failed. FAILED: org.apache.lucene.index.TestIndexingSequenceNumbers.testStressConcurrentCommit Error Message: this IndexWriter is closed Stack Trace: org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:742) at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:756) at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3174) at org.apache.lucene.index.TestIndexingSequenceNumbers.testStressConcurrentCommit(TestIndexingSequenceNumbers.java:228) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.OutOfMemoryError: Java heap space at __randomizedtesting.SeedInfo.seed([F8BD42013B872937]:0) at java.util.HashMap.resize(HashMap.java:703) at java.util.HashMap.putVal(HashMap.java:628) at java.util.HashMap.put(HashMap.java:611) at org.apache.lucene.index.FieldInfos$Builder.getOrAdd(FieldInfos.java:386) at org.apache.lucene.index.DefaultIndexingChain.getOrAddField(DefaultIndexingChain.java:582) at org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:430) at org.apache.lucene.index.Default
[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object
[ https://issues.apache.org/jira/browse/LUCENE-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354907#comment-15354907 ] Grant Ingersoll commented on LUCENE-7354: - bq. I don't see this - when I run CloudMLTQParserTest without your patch, and I look at MoreLikeThis.retrieveTerms() where String.valueOf(fieldValue) is called (by pulling the value of that expression out into a variable and breaking there in the debugger), I only see the actual field values - no indexed stored et al. I'll check again, [~steve_rowe]. I was doing the same thing you describe. Could be a version issue. I am on Solr 5.5.1. > MoreLikeThis incorrectly does toString on Field object > -- > > Key: LUCENE-7354 > URL: https://issues.apache.org/jira/browse/LUCENE-7354 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 6.0.1, 5.5.1, master (7.0) >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: LUCENE-7354-mlt-fix > > > In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a > Field object, we are incorrectly calling toString on the Field object, which > puts the Field attributes (indexed, stored, et. al) into the String that is > returned. > I'll put up a patch/fix shortly. -- 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] (LUCENE-7359) Add equals() and hashcode() to Explanation
[ https://issues.apache.org/jira/browse/LUCENE-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved LUCENE-7359. --- Resolution: Fixed Assignee: Alan Woodward Fix Version/s: 6.2 > Add equals() and hashcode() to Explanation > -- > > Key: LUCENE-7359 > URL: https://issues.apache.org/jira/browse/LUCENE-7359 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Fix For: 6.2 > > Attachments: LUCENE-7359.patch > > > I don't think there's any reason *not* to add these? -- 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-7359) Add equals() and hashcode() to Explanation
[ https://issues.apache.org/jira/browse/LUCENE-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354887#comment-15354887 ] ASF subversion and git services commented on LUCENE-7359: - Commit 6a703bebf751e882be30061121cfd7f0e9e8eb8b in lucene-solr's branch refs/heads/master from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6a703be ] LUCENE-7359: Add equals() and hashCode() to Explanation > Add equals() and hashcode() to Explanation > -- > > Key: LUCENE-7359 > URL: https://issues.apache.org/jira/browse/LUCENE-7359 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Priority: Minor > Fix For: 6.2 > > Attachments: LUCENE-7359.patch > > > I don't think there's any reason *not* to add these? -- 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-7359) Add equals() and hashcode() to Explanation
[ https://issues.apache.org/jira/browse/LUCENE-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354882#comment-15354882 ] ASF subversion and git services commented on LUCENE-7359: - Commit 976501f6f3fe602ada85a6f2392d1bb23438a319 in lucene-solr's branch refs/heads/branch_6x from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=976501f ] LUCENE-7359: Add equals() and hashCode() to Explanation > Add equals() and hashcode() to Explanation > -- > > Key: LUCENE-7359 > URL: https://issues.apache.org/jira/browse/LUCENE-7359 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Priority: Minor > Attachments: LUCENE-7359.patch > > > I don't think there's any reason *not* to add these? -- 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-8777) Duplicate Solr process can cripple a running process
[ https://issues.apache.org/jira/browse/SOLR-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354863#comment-15354863 ] ASF subversion and git services commented on SOLR-8777: --- Commit 4ea95bf8f11a9fb0b4226a0cd4b6840b845cf611 in lucene-solr's branch refs/heads/master from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4ea95bf ] SOLR-8777: Duplicate Solr process can cripple a running process > Duplicate Solr process can cripple a running process > > > Key: SOLR-8777 > URL: https://issues.apache.org/jira/browse/SOLR-8777 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.3.1 >Reporter: Shalin Shekhar Mangar > Attachments: SOLR-8777.patch, SOLR-8777.patch > > > Thanks to [~mewmewball] for catching this one. > Accidentally executing the same instance of Solr twice causes the second > start instance to die with an "Address already in use", but not before > deleting the first instance's live_node entry, emitting "Found a previous > node that still exists while trying to register a new live node - > removing existing node to create another". > The second start instance dies and its ephemeral node is then removed, > causing /live_nodes/ to be empty since the first start instance's > live_node was deleted by the second. -- 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-master - Build # 1236 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1236/ 1 tests failed. FAILED: org.apache.solr.handler.TestBlobHandler.doBlobHandlerTest Error Message: Could not find collection : .system Stack Trace: org.apache.solr.common.SolrException: Could not find collection : .system at __randomizedtesting.SeedInfo.seed([12883CB9F69DD63D:F2491EEB4D71A0CF]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:192) at org.apache.solr.handler.TestBlobHandler.doBlobHandlerTest(TestBlobHandler.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 10919 lines...] [junit4] Suite: org.apa
[jira] [Resolved] (LUCENE-7360) Remove Explanation.toHtml()
[ https://issues.apache.org/jira/browse/LUCENE-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved LUCENE-7360. --- Resolution: Fixed Assignee: Alan Woodward Fix Version/s: 6.2 master (7.0) Thanks for the review Adrien! > Remove Explanation.toHtml() > --- > > Key: LUCENE-7360 > URL: https://issues.apache.org/jira/browse/LUCENE-7360 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward > Fix For: master (7.0), 6.2 > > Attachments: LUCENE-7360.patch > > > This seems to be something of a relic. It's still used in Solr, but I think > it makes more sense to move it directly into the ExplainAugmenter there > rather than having it in Lucene itself. -- 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-7360) Remove Explanation.toHtml()
[ https://issues.apache.org/jira/browse/LUCENE-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354790#comment-15354790 ] ASF subversion and git services commented on LUCENE-7360: - Commit d33ad81d69ed8f96a2e7b8b00f4616c979378cd4 in lucene-solr's branch refs/heads/branch_6x from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d33ad81 ] LUCENE-7360: Explanation.toHtml() is deprecated > Remove Explanation.toHtml() > --- > > Key: LUCENE-7360 > URL: https://issues.apache.org/jira/browse/LUCENE-7360 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward > Fix For: master (7.0), 6.2 > > Attachments: LUCENE-7360.patch > > > This seems to be something of a relic. It's still used in Solr, but I think > it makes more sense to move it directly into the ExplainAugmenter there > rather than having it in Lucene itself. -- 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-7360) Remove Explanation.toHtml()
[ https://issues.apache.org/jira/browse/LUCENE-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354792#comment-15354792 ] ASF subversion and git services commented on LUCENE-7360: - Commit f3dcd467ff391ae7988cbc0576cc2c1bdb5caaa5 in lucene-solr's branch refs/heads/master from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f3dcd46 ] LUCENE-7360: Remove Explanation.toHtml() > Remove Explanation.toHtml() > --- > > Key: LUCENE-7360 > URL: https://issues.apache.org/jira/browse/LUCENE-7360 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward > Fix For: master (7.0), 6.2 > > Attachments: LUCENE-7360.patch > > > This seems to be something of a relic. It's still used in Solr, but I think > it makes more sense to move it directly into the ExplainAugmenter there > rather than having it in Lucene itself. -- 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-7360) Remove Explanation.toHtml()
[ https://issues.apache.org/jira/browse/LUCENE-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354791#comment-15354791 ] ASF subversion and git services commented on LUCENE-7360: - Commit 23119db3606732986d31c6e44ec26fbbde79ef75 in lucene-solr's branch refs/heads/master from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=23119db ] LUCENE-7360: Explanation.toHtml() is deprecated > Remove Explanation.toHtml() > --- > > Key: LUCENE-7360 > URL: https://issues.apache.org/jira/browse/LUCENE-7360 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward > Fix For: master (7.0), 6.2 > > Attachments: LUCENE-7360.patch > > > This seems to be something of a relic. It's still used in Solr, but I think > it makes more sense to move it directly into the ExplainAugmenter there > rather than having it in Lucene itself. -- 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-master - Build # 1056 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1056/ 7 tests failed. FAILED: org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithTimeDelay Error Message: Could not find collection : c1 Stack Trace: org.apache.solr.common.SolrException: Could not find collection : c1 at __randomizedtesting.SeedInfo.seed([6C80CB9F14AA1964:131E7C1A7DC834EE]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:192) at org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:129) at org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithTimeDelay(ZkStateReaderTest.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ConcurrentDeleteAndCreateCollectionTest Error Message: ObjectTracker found 10 object(s) that were not released!!! [InternalHttpClient, I
[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_92) - Build # 5943 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5943/ Java: 32bit/jdk1.8.0_92 -server -XX:+UseParallelGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: ObjectTracker found 8 object(s) that were not released!!! [MDCAwareThreadPoolExecutor, MockDirectoryWrapper, TransactionLog, MDCAwareThreadPoolExecutor, TransactionLog, MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper] Stack Trace: java.lang.AssertionError: ObjectTracker found 8 object(s) that were not released!!! [MDCAwareThreadPoolExecutor, MockDirectoryWrapper, TransactionLog, MDCAwareThreadPoolExecutor, TransactionLog, MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper] at __randomizedtesting.SeedInfo.seed([AE17F471E70AEC35]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:256) at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_AE17F471E70AEC35-001\tempDir-001\node2\testschemaapi_shard1_replica1\data\tlog\tlog.000: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_AE17F471E70AEC35-001\tempDir-001\node2\testschemaapi_shard1_replica1\data\tlog\tlog.000: The process cannot access the file because it is being used by another process. C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_AE17F471E70AEC35-001\tempDir-001\node2\testschemaapi_shard1_replica1\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_AE17F471E70AEC35-001\tempDir-001\node2\testschemaapi_shard1_replica1\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_AE17F471E70AEC35-001\tempDir-001\node2\testschemaapi_shard1_replica1\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_AE17F471E70AEC35-001\tempDir-001\node2\testschemaapi_shard1_replica1\data C:\Users\jenkins\workspace\Lucen
