[JENKINS] Lucene-Solr-BadApples-7.x-Linux (64bit/jdk-10.0.1) - Build # 49 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/49/
Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.cloud.SSLMigrationTest.test

Error Message:
Replica didn't have the proper urlScheme in the ClusterState

Stack Trace:
java.lang.AssertionError: Replica didn't have the proper urlScheme in the 
ClusterState
at 
__randomizedtesting.SeedInfo.seed([A315C3E7C0B1E796:2B41FC3D6E4D8A6E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SSLMigrationTest.assertReplicaInformation(SSLMigrationTest.java:104)
at 
org.apache.solr.cloud.SSLMigrationTest.testMigrateSSL(SSLMigrationTest.java:97)
at org.apache.solr.cloud.SSLMigrationTest.test(SSLMigrationTest.java:61)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 240 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/240/

2 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testDistribFaceting

Error Message:
Field intField should have a count of 1 expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: Field intField should have a count of 1 expected:<1> 
but was:<0>
at 
__randomizedtesting.SeedInfo.seed([EA6BC1AB257C709:6C174227D64CECDB]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testFacet(DocValuesNotIndexedTest.java:445)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testDistribFaceting(DocValuesNotIndexedTest.java:216)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  

[jira] [Commented] (SOLR-11779) Basic long-term collection of aggregated metrics

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509136#comment-16509136
 ] 

Yonik Seeley commented on SOLR-11779:
-

I don't know if it's this issue or a related issue, but all basic tests as well 
as "bin/solr start" now throw the following exception:
{code}
2018-06-12 03:45:57.146 WARN  (main) [   ] o.a.s.h.a.MetricsHistoryHandler 
Error querying .system collection, keeping metrics history in memory
org.apache.solr.common.SolrException: No such core: .system
at 
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:161)
 ~[solr-core-8.0.0-SNAPSHOT.jar:8.0.0-SNAPSHOT 
7773bf67643a152e1d12bed253345a40ef14f0e9 - yonik - 2018-06-11 20:14:07]
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) 
~[solr-solrj-8.0.0-SNAPSHOT.jar:8.0.0-SNAPSHOT 
7773bf67643a152e1d12bed253345a40ef14f0e9 - yonik - 2018-06-11 20:14:12]
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942) 
~[solr-solrj-8.0.0-SNAPSHOT.jar:8.0.0-SNAPSHOT 
7773bf67643a152e1d12bed253345a40ef14f0e9 - yonik - 2018-06-11 20:14:12]
at 
org.apache.solr.handler.admin.MetricsHistoryHandler.checkSystemCollection(MetricsHistoryHandler.java:282)
 [solr-core-8.0.0-SNAPSHOT.jar:8.0.0-SNAPSHOT 
7773bf67643a152e1d12bed253345a40ef14f0e9 - yonik - 2018-06-11 20:14:07]
at 
org.apache.solr.handler.admin.MetricsHistoryHandler.(MetricsHistoryHandler.java:235)
 [solr-core-8.0.0-SNAPSHOT.jar:8.0.0-SNAPSHOT 
7773bf67643a152e1d12bed253345a40ef14f0e9 - yonik - 2018-06-11 20:14:07]
at 
org.apache.solr.core.CoreContainer.createMetricsHistoryHandler(CoreContainer.java:780)
 [solr-core-8.0.0-SNAPSHOT.jar:8.0.0-SNAPSHOT 
7773bf67643a152e1d12bed253345a40ef14f0e9 - yonik - 2018-06-11 20:14:07]
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:578) 
[solr-core-8.0.0-SNAPSHOT.jar:8.0.0-SNAPSHOT 
7773bf67643a152e1d12bed253345a40ef14f0e9 - yonik - 2018-06-11 20:14:07]
at 
org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:252)
 [solr-core-8.0.0-SNAPSHOT.jar:8.0.0-SNAPSHOT 
7773bf67643a152e1d12bed253345a40ef14f0e9 - yonik - 2018-06-11 20:14:07]
at 
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:172) 
[solr-core-8.0.0-SNAPSHOT.jar:8.0.0-SNAPSHOT 
7773bf67643a152e1d12bed253345a40ef14f0e9 - yonik - 2018-06-11 20:14:07]
at 
org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:139) 
[jetty-servlet-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:741) 
[jetty-servlet-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:374)
 [jetty-servlet-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497) 
[jetty-webapp-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1459) 
[jetty-webapp-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:785)
 [jetty-server-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:287)
 [jetty-servlet-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545) 
[jetty-webapp-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
 [jetty-util-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
 [jetty-deploy-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:192) 
[jetty-deploy-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:505)
 [jetty-deploy-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:151) 
[jetty-deploy-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:180)
 [jetty-deploy-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:453)
 [jetty-deploy-9.4.10.v20180503.jar:9.4.10.v20180503]
at 
org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:64)
 [jetty-deploy-9.4.10.v20180503.jar:9.4.10.v20180503]
at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:610) 

[jira] [Resolved] (SOLR-12208) Don't use "INDEX.sizeInBytes" as a tag name in policy calculations

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul resolved SOLR-12208.
---
   Resolution: Fixed
Fix Version/s: 7.5
   master (8.0)

> Don't use "INDEX.sizeInBytes" as a tag name in policy calculations
> --
>
> Key: SOLR-12208
> URL: https://issues.apache.org/jira/browse/SOLR-12208
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12208.patch, SOLR-12208.patch, SOLR-12208.patch
>
>
> CORE_IDX and FREEDISK ConditionType reuse this metric name, but they assume 
> the values are expressed in gigabytes. This alone is confusing considering 
> the name of the metric.
> Additionally, it causes conflicts in the simulation framework that would 
> require substantial changes to resolve (ReplicaInfo-s in 
> SimClusterStateProvider keep metric values in their variables, expressed in 
> original units - but then the Policy assumes it can put the values expressed 
> in GB under the same key... hilarity ensues).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12208) Don't use "INDEX.sizeInBytes" as a tag name in policy calculations

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509128#comment-16509128
 ] 

ASF subversion and git services commented on SOLR-12208:


Commit f847488e8dc59b5562f1a15db10ca12ba50814a7 in lucene-solr's branch 
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f847488 ]

SOLR-12208: Renamed the autoscaling variable 'INDEX.sizeInBytes' to 
'INDEX.sizeInGB'


> Don't use "INDEX.sizeInBytes" as a tag name in policy calculations
> --
>
> Key: SOLR-12208
> URL: https://issues.apache.org/jira/browse/SOLR-12208
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-12208.patch, SOLR-12208.patch, SOLR-12208.patch
>
>
> CORE_IDX and FREEDISK ConditionType reuse this metric name, but they assume 
> the values are expressed in gigabytes. This alone is confusing considering 
> the name of the metric.
> Additionally, it causes conflicts in the simulation framework that would 
> require substantial changes to resolve (ReplicaInfo-s in 
> SimClusterStateProvider keep metric values in their variables, expressed in 
> original units - but then the Policy assumes it can put the values expressed 
> in GB under the same key... hilarity ensues).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12208) Don't use "INDEX.sizeInBytes" as a tag name in policy calculations

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509127#comment-16509127
 ] 

ASF subversion and git services commented on SOLR-12208:


Commit 98a4dd29ef615897656f01ebac40957ca5fce432 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=98a4dd2 ]

SOLR-12208: Renamed the autoscaling variable 'INDEX.sizeInBytes' to 
'INDEX.sizeInGB'


> Don't use "INDEX.sizeInBytes" as a tag name in policy calculations
> --
>
> Key: SOLR-12208
> URL: https://issues.apache.org/jira/browse/SOLR-12208
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-12208.patch, SOLR-12208.patch, SOLR-12208.patch
>
>
> CORE_IDX and FREEDISK ConditionType reuse this metric name, but they assume 
> the values are expressed in gigabytes. This alone is confusing considering 
> the name of the metric.
> Additionally, it causes conflicts in the simulation framework that would 
> require substantial changes to resolve (ReplicaInfo-s in 
> SimClusterStateProvider keep metric values in their variables, expressed in 
> original units - but then the Policy assumes it can put the values expressed 
> in GB under the same key... hilarity ensues).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: BadApple report

[Erick Erickson]

Great! I won't BadApple those of course.

Erick

On Mon, Jun 11, 2018 at 1:33 PM, Andrzej Białecki
 wrote:
>
>
> On 11 Jun 2018, at 17:51, Erick Erickson  wrote:
>
> IndexSizeTriggerTest.testMixedBounds
>
>
> I committed a change today that should fix this.
>
> SearchRateTriggerTest.testTrigger
>
>
> TestLargeCluster.testBasic
> TestLargeCluster.testNodeLost
>
>
> On June 6 I made a change that should fix these tests.
>
> --
> Best regards,
> Andrzej Bialecki
>
> --=# http://www.lucidworks.com #=--
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9685) tag a query in JSON syntax

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509052#comment-16509052
 ] 

Yonik Seeley commented on SOLR-9685:


Stepping through with the debugger, it looks like this is the type of 
local-params string being built:
{code}
{!bool should={!tag=MYTAG}id:1 should=$_tt0 }
{code}

So we need to use variables for parameters here as well.

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509023#comment-16509023
 ] 

Robert Muir commented on LUCENE-8041:
-

{quote}
That sounds like the cart leading the horse (allowing how CheckIndex works 
today prevent us from remaking how we want Lucene to be tomorrow). Can't we 
just relax what CheckIndex checks here – like have it check but report a 
warning if only some docs have TVs and others not which is generally not 
normal? I think that's what you're getting at but I'm not sure. I've only 
looked at CheckIndex in passing.
{quote}

That's absolutely not the case at all. The user is allowed to do this, hence 
checkindex must validate it. Please don't make checkindex the bad guy here, its 
not. The problem is related to indexwriter allowing users to do this.

> All Fields.terms(fld) impls should be O(1) not O(log(N))
> 
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds.  The O(log(N)) 
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time, 
> if I recall.  There are many Field implementations that are impacted... in 
> part because Fields is the base class of FieldsProducer.  
> As an aside, I hope Fields to go away some day; FieldsProducer should be 
> TermsProducer and not have an iterator of fields. If DocValuesProducer 
> doesn't have this then why should the terms index part of our API have it?  
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator 
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap 
> in many cases if we can assume when we initialize these internal maps that we 
> consume them in sorted order to begin with.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9685) tag a query in JSON syntax

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509002#comment-16509002
 ] 

Yonik Seeley commented on SOLR-9685:


Here's one of the simplest examples of a query that fails to parse:
{code}
curl http://localhost:8983/solr/techproducts/query -d ' {
  query:{bool:{
must:{"#TOP" : "text:memory"}
  }}
}'
{code}

{code}
{
  "responseHeader":{
"status":400,
"QTime":8,
"params":{
  "json":" {\n  query:{bool:{\nmust:{\"#TOP\" : \"text:memory\"}\n  
}}\n}"}},
  "error":{
"metadata":[
  "error-class","org.apache.solr.common.SolrException",
  "root-error-class","org.apache.solr.search.SyntaxError"],
"msg":"org.apache.solr.search.SyntaxError: Missing end to unquoted value 
starting at 6 str='{!tag=TOP'",
"code":400}}
{code}

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-repro - Build # 802 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/802/

[...truncated 29 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/239/consoleText

[repro] Revision: cfac2ab80d12f4fc82d26ffdf392b0774aa77644

[repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9
[repro] Repro line:  ant test  -Dtestcase=SolrRrdBackendFactoryTest 
-Dtests.method=testBasic -Dtests.seed=874F1FAB3732B36D -Dtests.multiplier=2 
-Dtests.locale=is-IS -Dtests.timezone=America/Yakutat -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestComputePlanAction 
-Dtests.method=testNodeAdded -Dtests.seed=874F1FAB3732B36D -Dtests.multiplier=2 
-Dtests.locale=und -Dtests.timezone=Asia/Brunei -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
ead05a10b1eff181ef24f64cf7feee91ed5a5155
[repro] git fetch
[repro] git checkout cfac2ab80d12f4fc82d26ffdf392b0774aa77644

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   SolrRrdBackendFactoryTest
[repro]   TestComputePlanAction
[repro] ant compile-test

[...truncated 3318 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.SolrRrdBackendFactoryTest|*.TestComputePlanAction" 
-Dtests.showOutput=onerror 
-DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 
-Dtests.seed=874F1FAB3732B36D -Dtests.multiplier=2 -Dtests.locale=is-IS 
-Dtests.timezone=America/Yakutat -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[...truncated 2486 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest
[repro]   2/5 failed: 
org.apache.solr.cloud.autoscaling.sim.TestComputePlanAction
[repro] git checkout ead05a10b1eff181ef24f64cf7feee91ed5a5155

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 76 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/76/

6 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testAddAndDeleteReplica

Error Message:
Could not load collection from ZK: solrj_replicatests

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
solrj_replicatests
at 
__randomizedtesting.SeedInfo.seed([F64145A395D086EC:18F13CF6921C9156]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1316)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:732)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:148)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:131)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:117)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:256)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testAddAndDeleteReplica(CollectionsAPISolrJTest.java:350)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[GitHub] lucene-solr issue #379: add ë, ö and ï to norm()

[Bruno86]

Github user Bruno86 commented on the issue:

https://github.com/apache/lucene-solr/pull/379
  
The issue is here : https://issues.apache.org/jira/browse/LUCENE-8353


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-8353) FrenchLightStemmer dont work with ë, ö and ï

[Bruno CAILLAUD (JIRA)]

Bruno CAILLAUD created LUCENE-8353:
--

 Summary: FrenchLightStemmer dont work with ë, ö and ï
 Key: LUCENE-8353
 URL: https://issues.apache.org/jira/browse/LUCENE-8353
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/analysis
Reporter: Bruno CAILLAUD


ë, ö and ï are not present in FrenchLightStemmer so if you search per exemple

Laicité when you index contains Laïcité, that's not match

I try to fixe this issue in https://github.com/apache/lucene-solr/pull/379



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10.0.1) - Build # 2106 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2106/
Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/71)={   
"replicationFactor":"2",   "pullReplicas":"0",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0",   
"autoCreated":"true",   "shards":{ "shard2":{   "replicas":{ 
"core_node3":{   
"core":"testSplitIntegration_collection_shard2_replica_n3",   
"leader":"true",   "SEARCHER.searcher.maxDoc":11,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":1,   
"node_name":"127.0.0.1:1_solr",   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":11}, "core_node4":{ 
  "core":"testSplitIntegration_collection_shard2_replica_n4",   
"SEARCHER.searcher.maxDoc":11,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",  
 "state":"active",   "type":"NRT",   
"SEARCHER.searcher.numDocs":11}},   "range":"0-7fff",   
"state":"active"}, "shard1":{   "stateTimestamp":"1528757625120319650", 
  "replicas":{ "core_node1":{   
"core":"testSplitIntegration_collection_shard1_replica_n1",   
"leader":"true",   "SEARCHER.searcher.maxDoc":14,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":1,   
"node_name":"127.0.0.1:1_solr",   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":14}, "core_node2":{ 
  "core":"testSplitIntegration_collection_shard1_replica_n2",   
"SEARCHER.searcher.maxDoc":14,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",  
 "state":"active",   "type":"NRT",   
"SEARCHER.searcher.numDocs":14}},   "range":"8000-",   
"state":"inactive"}, "shard1_1":{   "parent":"shard1",   
"stateTimestamp":"1528757625138458000",   "range":"c000-",  
 "state":"active",   "replicas":{ "core_node10":{   
"leader":"true",   
"core":"testSplitIntegration_collection_shard1_1_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}, 
"core_node9":{   
"core":"testSplitIntegration_collection_shard1_1_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}}}, "shard1_0":{  
 "parent":"shard1",   "stateTimestamp":"1528757625138081050",   
"range":"8000-bfff",   "state":"active",   "replicas":{ 
"core_node7":{   "leader":"true",   
"core":"testSplitIntegration_collection_shard1_0_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}, 
"core_node8":{   
"core":"testSplitIntegration_collection_shard1_0_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}

Stack Trace:
java.util.concurrent.TimeoutException: last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/71)={
  "replicationFactor":"2",
  "pullReplicas":"0",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0",
  "autoCreated":"true",
  "shards":{
"shard2":{
  "replicas":{
"core_node3":{
  "core":"testSplitIntegration_collection_shard2_replica_n3",
  "leader":"true",
  "SEARCHER.searcher.maxDoc":11,
  "SEARCHER.searcher.deletedDocs":0,
  "INDEX.sizeInBytes":1,
  "node_name":"127.0.0.1:1_solr",
  

[jira] [Updated] (SOLR-9685) tag a query in JSON syntax

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev updated SOLR-9685:
---
Attachment: SOLR-9685-doc.patch

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9685) tag a query in JSON syntax

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev updated SOLR-9685:
---
Attachment: (was: SOLR-9685-doc.patch)

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7193) Concatenate words from token stream

[Alexandre Rafalovitch (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508806#comment-16508806
 ] 

Alexandre Rafalovitch commented on SOLR-7193:
-

This seems to be satisfied by LUCENE-8332 and SOLR-12376, both coming in 7.4.

> Concatenate words from token stream
> ---
>
> Key: SOLR-7193
> URL: https://issues.apache.org/jira/browse/SOLR-7193
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Reporter: Abhishek Bafna
>Priority: Major
> Attachments: concatenate_words.patch
>
>
> The user entered data often don't have proper spacing between words and words 
> spelling and format also varies from data like business names, address etc. 
> After tokenizing data, we might perform pattern replacement, stop word 
> filtering etc. Later we want to concatenate all the tokens and generate 
> n-grams token for indexing business name and perform the fuzzy match.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-8278) UAX29URLEmailTokenizer is not detecting some tokens as URL type

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated LUCENE-8278:
---
Fix Version/s: 7.5
   master (8.0)

> UAX29URLEmailTokenizer is not detecting some tokens as URL type
> ---
>
> Key: LUCENE-8278
> URL: https://issues.apache.org/jira/browse/LUCENE-8278
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Junte Zhang
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: master (8.0), 7.5
>
> Attachments: LUCENE-8278.patch, patched.png, unpatched.png
>
>
> We are using the UAX29URLEmailTokenizer so we can use the token types in our 
> plugins.
> However, I noticed that the tokenizer is not detecting certain URLs as  
> but  instead.
> Examples that are not working:
>  * example.com is 
>  * example.net is 
> But:
>  * https://example.com is 
>  * as is https://example.net
> Examples that work:
>  * example.ch is 
>  * example.co.uk is 
>  * example.nl is 
> I have checked this JIRA, and could not find an issue. I have tested this on 
> Lucene (Solr) 6.4.1 and 7.3.
> Could someone confirm my findings and advise what I could do to (help) 
> resolve this issue?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Lucene/Solr 7.4

[Steve Rowe]

Adrien,

Are you okay with including the fix on LUCENE-8278 in 7.4?

--
Steve
www.lucidworks.com

> On Jun 11, 2018, at 11:24 AM, Adrien Grand  wrote:
> 
> No worries Uwe, we'll wait. Enjoy Buzzwords!
> 
> Le lun. 11 juin 2018 à 17:08, Uwe Schindler  a écrit :
> I still have this new security issue and to fix it finally everywhere, it 
> requires API changes. So please wait, I am working but buzzwords is so 
> interesting! 勞
> 
> Uwe
> 
> 
> Am June 11, 2018 2:45:54 PM UTC schrieb David Smiley 
> :
> It'd be nice to get in this bug 
> https://issues.apache.org/jira/browse/LUCENE-8344 but is pending a review.
> 
> On Tue, Jun 5, 2018 at 4:24 AM Adrien Grand  wrote:
> Hi all,
> 
> We released 7.3 two months ago on April 4th and we accumulated quite a number 
> of features, enhancements and fixes that are not released yet, so I'd like to 
> start working on releasing Lucene/Solr 7.4.0.
> 
> I propose to create the 7.4 branch later this week and build the first RC 
> early next week if that works for everyone. Please let me know if that are 
> bug fixes that we think should make it to 7.4 and might not be ready by then.
> 
> Adrien
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
> http://www.solrenterprisesearchserver.com
> 
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8278) UAX29URLEmailTokenizer is not detecting some tokens as URL type

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508766#comment-16508766
 ] 

ASF subversion and git services commented on LUCENE-8278:
-

Commit 6140d8be05d1b7aad565f53dd2ee66b984b9a379 in lucene-solr's branch 
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6140d8b ]

LUCENE-8278: Some end-of-input no-scheme domain-only URL tokens are typed as 
 rather than 


> UAX29URLEmailTokenizer is not detecting some tokens as URL type
> ---
>
> Key: LUCENE-8278
> URL: https://issues.apache.org/jira/browse/LUCENE-8278
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Junte Zhang
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: LUCENE-8278.patch, patched.png, unpatched.png
>
>
> We are using the UAX29URLEmailTokenizer so we can use the token types in our 
> plugins.
> However, I noticed that the tokenizer is not detecting certain URLs as  
> but  instead.
> Examples that are not working:
>  * example.com is 
>  * example.net is 
> But:
>  * https://example.com is 
>  * as is https://example.net
> Examples that work:
>  * example.ch is 
>  * example.co.uk is 
>  * example.nl is 
> I have checked this JIRA, and could not find an issue. I have tested this on 
> Lucene (Solr) 6.4.1 and 7.3.
> Could someone confirm my findings and advise what I could do to (help) 
> resolve this issue?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8278) UAX29URLEmailTokenizer is not detecting some tokens as URL type

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508767#comment-16508767
 ] 

ASF subversion and git services commented on LUCENE-8278:
-

Commit ead05a10b1eff181ef24f64cf7feee91ed5a5155 in lucene-solr's branch 
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ead05a1 ]

LUCENE-8278: Some end-of-input no-scheme domain-only URL tokens are typed as 
 rather than 


> UAX29URLEmailTokenizer is not detecting some tokens as URL type
> ---
>
> Key: LUCENE-8278
> URL: https://issues.apache.org/jira/browse/LUCENE-8278
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Junte Zhang
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: LUCENE-8278.patch, patched.png, unpatched.png
>
>
> We are using the UAX29URLEmailTokenizer so we can use the token types in our 
> plugins.
> However, I noticed that the tokenizer is not detecting certain URLs as  
> but  instead.
> Examples that are not working:
>  * example.com is 
>  * example.net is 
> But:
>  * https://example.com is 
>  * as is https://example.net
> Examples that work:
>  * example.ch is 
>  * example.co.uk is 
>  * example.nl is 
> I have checked this JIRA, and could not find an issue. I have tested this on 
> Lucene (Solr) 6.4.1 and 7.3.
> Could someone confirm my findings and advise what I could do to (help) 
> resolve this issue?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508756#comment-16508756
 ] 

David Smiley commented on LUCENE-8041:
--

bq. I don't think we should remove field iteration/Fields unless we remove the 
ability to change term vectors "per-doc". It is currently needed (e.g. by 
CheckIndex) to know what fields were truly indexed for a specific document with 
vectors, since that may disagree with FieldInfos. If we fixed that, then it 
would truly be unnecessary and FieldInfos would be all we need.

That sounds like the cart leading the horse  (allowing how CheckIndex works 
today prevent us from remaking how we want Lucene to be tomorrow).  Can't we 
just relax what CheckIndex checks here -- like have it check but report a 
warning if only some docs have TVs and others not which is generally not 
normal?  I think that's what you're getting at but I'm not sure.  I've only 
looked at CheckIndex in passing.

bq. The only thing blocking this is the fact that term-vector options are 
configurable per-doc, which doesnt make sense anyway.

+1 I agree; if this feature is a casualty of the refactor then I'm fine with it 
going away.  I haven't looked close enough to see how much these things are 
linked (i.e. can we really not have it both ways).

> All Fields.terms(fld) impls should be O(1) not O(log(N))
> 
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds.  The O(log(N)) 
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time, 
> if I recall.  There are many Field implementations that are impacted... in 
> part because Fields is the base class of FieldsProducer.  
> As an aside, I hope Fields to go away some day; FieldsProducer should be 
> TermsProducer and not have an iterator of fields. If DocValuesProducer 
> doesn't have this then why should the terms index part of our API have it?  
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator 
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap 
> in many cases if we can assume when we initialize these internal maps that we 
> consume them in sorted order to begin with.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Reopened] (SOLR-9685) tag a query in JSON syntax

[Yonik Seeley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley reopened SOLR-9685:


> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9685) tag a query in JSON syntax

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508753#comment-16508753
 ] 

Yonik Seeley commented on SOLR-9685:


Looks like escaping bugs when producing the local-params variant from the JSON 
one.
If possible, this should be fixed for 7.4.

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9685) tag a query in JSON syntax

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508736#comment-16508736
 ] 

Mikhail Khludnev commented on SOLR-9685:


[~ctargett], [~ysee...@gmail.com] please find [^SOLR-9685-doc.patch], I'll put 
it in all three branches this week with your improvements. 

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9685) tag a query in JSON syntax

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev updated SOLR-9685:
---
Attachment: SOLR-9685-doc.patch

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-11779) Basic long-term collection of aggregated metrics

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508731#comment-16508731
 ] 

ASF subversion and git services commented on SOLR-11779:


Commit 30ed80092b789359e00b12097a5f6ed02aa1f995 in lucene-solr's branch 
refs/heads/branch_7_4 from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=30ed800 ]

SOLR-11779: Ref Guide: minor typos; capitalize section titles; remove monospace 
from section titles


> Basic long-term collection of aggregated metrics
> 
>
> Key: SOLR-11779
> URL: https://issues.apache.org/jira/browse/SOLR-11779
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3, master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11779.patch, SOLR-11779.patch, SOLR-11779.patch, 
> SOLR-11779.patch, c1.png, c2.png, core.json, d1.png, d2.png, d3.png, 
> jvm-list.json, jvm-string.json, jvm.json, o1.png, u1.png
>
>
> Tracking the key metrics over time is very helpful in understanding the 
> cluster and user behavior.
> Currently even basic metrics tracking requires setting up an external system 
> and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The 
> advantage of this setup is that these external tools usually provide a lot of 
> sophisticated functionality. The downside is that they don't ship out of the 
> box with Solr and require additional admin effort to set up.
> Solr could collect some of the key metrics and keep their historical values 
> in a round-robin database (eg. using RRD4j) to keep the size of the historic 
> data constant (eg. ~64kB per metric), but at the same providing out of the 
> box useful insights into the basic system behavior over time. This data could 
> be persisted to the {{.system}} collection as blobs, and it could be also 
> presented in the Admin UI as graphs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-repro - Build # 800 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/800/

[...truncated 29 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/239/consoleText

[repro] Revision: cfac2ab80d12f4fc82d26ffdf392b0774aa77644

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=OverseerTaskQueueTest 
-Dtests.method=testDistributedQueueBlocking -Dtests.seed=2F7EF5D9AC2CE7A7 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=hu-HU -Dtests.timezone=Europe/Brussels -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=CdcrRequestHandlerTest 
-Dtests.method=testLifeCycleActions -Dtests.seed=2F7EF5D9AC2CE7A7 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=ar-AE -Dtests.timezone=America/Indiana/Indianapolis 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestCloudConsistency 
-Dtests.method=testOutOfSyncReplicasCannotBecomeLeaderAfterRestart 
-Dtests.seed=2F7EF5D9AC2CE7A7 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=sr-Latn-BA -Dtests.timezone=Europe/Rome -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestCloudConsistency 
-Dtests.method=testOutOfSyncReplicasCannotBecomeLeader 
-Dtests.seed=2F7EF5D9AC2CE7A7 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=sr-Latn-BA -Dtests.timezone=Europe/Rome -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestStressCloudBlindAtomicUpdates 
-Dtests.method=test_stored_idx -Dtests.seed=2F7EF5D9AC2CE7A7 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=zh-SG -Dtests.timezone=CST -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestStressCloudBlindAtomicUpdates 
-Dtests.method=test_dv_stored_idx -Dtests.seed=2F7EF5D9AC2CE7A7 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=zh-SG -Dtests.timezone=CST -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
fc3f64269272f6daba3cad5bb4a8b623cc7b9373
[repro] git fetch

[...truncated 2 lines...]
[repro] git checkout cfac2ab80d12f4fc82d26ffdf392b0774aa77644

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   TestStressCloudBlindAtomicUpdates
[repro]   TestCloudConsistency
[repro]   CdcrRequestHandlerTest
[repro]   OverseerTaskQueueTest
[repro] ant compile-test

[...truncated 3318 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=20 
-Dtests.class="*.TestStressCloudBlindAtomicUpdates|*.TestCloudConsistency|*.CdcrRequestHandlerTest|*.OverseerTaskQueueTest"
 -Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=2F7EF5D9AC2CE7A7 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=zh-SG -Dtests.timezone=CST -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[...truncated 2857 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.OverseerTaskQueueTest
[repro]   0/5 failed: org.apache.solr.cloud.TestCloudConsistency
[repro]   0/5 failed: org.apache.solr.cloud.cdcr.CdcrRequestHandlerTest
[repro]   2/5 failed: org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates
[repro] git checkout fc3f64269272f6daba3cad5bb4a8b623cc7b9373

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 5 lines...]

-
To unsubscribe, e-mail: 

[jira] [Commented] (LUCENE-8278) UAX29URLEmailTokenizer is not detecting some tokens as URL type

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508726#comment-16508726
 ] 

Steve Rowe commented on LUCENE-8278:


I made a Solr configset with an analyzer containing only a 
{{solr.UAX29URLEmailTokenizerFactory}} tokenizer, then ran Solr on master both 
without the patch: !unpatched.png! and with the patch: !patched.png!.

[~drjz]: I think you're just having issues running the modified code.

Committing shortly.

> UAX29URLEmailTokenizer is not detecting some tokens as URL type
> ---
>
> Key: LUCENE-8278
> URL: https://issues.apache.org/jira/browse/LUCENE-8278
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Junte Zhang
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: LUCENE-8278.patch, patched.png, unpatched.png
>
>
> We are using the UAX29URLEmailTokenizer so we can use the token types in our 
> plugins.
> However, I noticed that the tokenizer is not detecting certain URLs as  
> but  instead.
> Examples that are not working:
>  * example.com is 
>  * example.net is 
> But:
>  * https://example.com is 
>  * as is https://example.net
> Examples that work:
>  * example.ch is 
>  * example.co.uk is 
>  * example.nl is 
> I have checked this JIRA, and could not find an issue. I have tested this on 
> Lucene (Solr) 6.4.1 and 7.3.
> Could someone confirm my findings and advise what I could do to (help) 
> resolve this issue?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-11779) Basic long-term collection of aggregated metrics

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508725#comment-16508725
 ] 

ASF subversion and git services commented on SOLR-11779:


Commit 4505e40846fa1d560bb7e24bc794a85cd7ac9e00 in lucene-solr's branch 
refs/heads/branch_7x from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4505e40 ]

SOLR-11779: Ref Guide: minor typos; capitalize section titles; remove monospace 
from section titles


> Basic long-term collection of aggregated metrics
> 
>
> Key: SOLR-11779
> URL: https://issues.apache.org/jira/browse/SOLR-11779
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3, master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11779.patch, SOLR-11779.patch, SOLR-11779.patch, 
> SOLR-11779.patch, c1.png, c2.png, core.json, d1.png, d2.png, d3.png, 
> jvm-list.json, jvm-string.json, jvm.json, o1.png, u1.png
>
>
> Tracking the key metrics over time is very helpful in understanding the 
> cluster and user behavior.
> Currently even basic metrics tracking requires setting up an external system 
> and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The 
> advantage of this setup is that these external tools usually provide a lot of 
> sophisticated functionality. The downside is that they don't ship out of the 
> box with Solr and require additional admin effort to set up.
> Solr could collect some of the key metrics and keep their historical values 
> in a round-robin database (eg. using RRD4j) to keep the size of the historic 
> data constant (eg. ~64kB per metric), but at the same providing out of the 
> box useful insights into the basic system behavior over time. This data could 
> be persisted to the {{.system}} collection as blobs, and it could be also 
> presented in the Admin UI as graphs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-9685) tag a query in JSON syntax

[Dr Oleg Savrasov (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508720#comment-16508720
 ] 

Dr Oleg Savrasov edited comment on SOLR-9685 at 6/11/18 8:56 PM:
-

[~mkhludnev], sorry for invalid JSON, my fault. An attempt to make it valid 
didn't help as well

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    query : "{!parent tag=top filters=$child.fq which=scope:product 
v=$childquery}",
    filter :  "{!tag=top}category:clothes",
    params:{
        childquery : "scope:sku",
        child.fq : { "#color" : "color:black" }
    }
}'{code}
 

I've tried to rework the request according to JSON DSL and just want to share 
my results, because I'm not sure if they are supposed to work or not.

This one works fine

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    "query" : {
    "parent": {
    "query": "scope:sku",
    "filters" : [
        "{!tag=color}color:black",
        "{!tag=size}size:L"
    ],
    "which": "scope:product"
    }
    }
}'
{code}
while this

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    "query" : {
    "parent": {
    "query": "scope:sku",
    "filters" : [
        { "#color" :  "color:black" },
        { "#size" : "size:L" }
    ],
    "which": "scope:product"
    }
    }
}'{code}
 

responds with

 
{code:java}
"error":{
    "metadata":[
  "error-class","org.apache.solr.common.SolrException",
  "root-error-class","org.apache.solr.search.SyntaxError"],
    "msg":"org.apache.solr.search.SyntaxError: Missing end to unquoted value 
starting at 6 str='{!tag=color'",
    "code":400}}{code}
 

Absolutely the same results I've got with

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    "query" : {
    "parent": {
 "which": "scope:product",
    "query": {
   "bool": {
   "must":"scope:sku",
   "filter":[ 
    "{!tag=color}color:black",
        "{!tag=size}size:L"
    ] 
 }
 } 
    }
    }
}'{code}
 

and

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    "query" : {
    "parent": {
 "which": "scope:product",
    "query": {
   "bool": {
   "must":"scope:sku",
   "filter":[ 
    { "#color" :  "color:black" },
        { "#size" : "size:L" }
    ] 
 }
 } 
    }
    }
}'{code}
 

Finally [~mkhludnev]'s helped to find a working version, which doesn't look 
obvious for me.
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    "query" : {
    "parent": {
 "which": "scope:product",
    "query": {
   "bool": {
   "must":"scope:sku",
   "filter":[ 
   { "#color" : {lucene: { "query":"color:black"} 
}},
   { "#size" : {lucene: { "query":"size:L"} }}
            
    ] 
 }
 } 
    }
    }
}'{code}
Let me express my huge thanks to [~mkhludnev] for his incredible creativity and 
support.


was (Author: osavrasov):
[~mkhludnev], sorry for invalid JSON, my fault. An attempt to make it valid 
didn't help as well 

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    query : "{!parent tag=top filters=$child.fq which=scope:product 
v=$childquery}",
    filter :  "{!tag=top}category:clothes",
    params:{
        childquery : "scope:sku",
        child.fq : { "#color" : "color:black" }
    }
}'{code}
 

I've tried to rework the request according to JSON DSL and just want to share 
my results, because I'm not sure if they are supposed to work or not.

This one works fine

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    "query" : {
    "parent": {
    "query": "scope:sku",
    "filters" : [
        "{!tag=color}color:black",
        "{!tag=size}size:L"
    ],
    "which": "scope:product"
    }
    }
}'
{code}
while this

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    "query" : {
    "parent": {
    "query": "scope:sku",
    "filters" : [
        { "#color" :  "color:black" },
        { "#size" : "size:L" }
    ],
    "which": "scope:product"
    }
    }
}'{code}
 

responds with

 
{code:java}

[jira] [Commented] (SOLR-11779) Basic long-term collection of aggregated metrics

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508722#comment-16508722
 ] 

ASF subversion and git services commented on SOLR-11779:


Commit 7773bf67643a152e1d12bed253345a40ef14f0e9 in lucene-solr's branch 
refs/heads/master from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7773bf67 ]

SOLR-11779: Ref Guide: minor typos; capitalize section titles; remove monospace 
from section titles


> Basic long-term collection of aggregated metrics
> 
>
> Key: SOLR-11779
> URL: https://issues.apache.org/jira/browse/SOLR-11779
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3, master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11779.patch, SOLR-11779.patch, SOLR-11779.patch, 
> SOLR-11779.patch, c1.png, c2.png, core.json, d1.png, d2.png, d3.png, 
> jvm-list.json, jvm-string.json, jvm.json, o1.png, u1.png
>
>
> Tracking the key metrics over time is very helpful in understanding the 
> cluster and user behavior.
> Currently even basic metrics tracking requires setting up an external system 
> and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The 
> advantage of this setup is that these external tools usually provide a lot of 
> sophisticated functionality. The downside is that they don't ship out of the 
> box with Solr and require additional admin effort to set up.
> Solr could collect some of the key metrics and keep their historical values 
> in a round-robin database (eg. using RRD4j) to keep the size of the historic 
> data constant (eg. ~64kB per metric), but at the same providing out of the 
> box useful insights into the basic system behavior over time. This data could 
> be persisted to the {{.system}} collection as blobs, and it could be also 
> presented in the Admin UI as graphs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9685) tag a query in JSON syntax

[Dr Oleg Savrasov (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508720#comment-16508720
 ] 

Dr Oleg Savrasov commented on SOLR-9685:


[~mkhludnev], sorry for invalid JSON, my fault. An attempt to make it valid 
didn't help as well 

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    query : "{!parent tag=top filters=$child.fq which=scope:product 
v=$childquery}",
    filter :  "{!tag=top}category:clothes",
    params:{
        childquery : "scope:sku",
        child.fq : { "#color" : "color:black" }
    }
}'{code}
 

I've tried to rework the request according to JSON DSL and just want to share 
my results, because I'm not sure if they are supposed to work or not.

This one works fine

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    "query" : {
    "parent": {
    "query": "scope:sku",
    "filters" : [
        "{!tag=color}color:black",
        "{!tag=size}size:L"
    ],
    "which": "scope:product"
    }
    }
}'
{code}
while this

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    "query" : {
    "parent": {
    "query": "scope:sku",
    "filters" : [
        { "#color" :  "color:black" },
        { "#size" : "size:L" }
    ],
    "which": "scope:product"
    }
    }
}'{code}
 

responds with

 
{code:java}
"error":{
    "metadata":[
  "error-class","org.apache.solr.common.SolrException",
  "root-error-class","org.apache.solr.search.SyntaxError"],
    "msg":"org.apache.solr.search.SyntaxError: Missing end to unquoted value 
starting at 6 str='{!tag=color'",
    "code":400}}{code}
 

Absolutely the same results I've got with

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    "query" : {
    "parent": {
 "which": "scope:product",
    "query": {
   "bool": {
   "must":"scope:sku",
   "filter":[ 
    "{!tag=color}color:black",
        "{!tag=size}size:L"
    ] 
 }
 } 
    }
    }
}'{code}
 

and

 
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    "query" : {
    "parent": {
 "which": "scope:product",
    "query": {
   "bool": {
   "must":"scope:sku",
   "filter":[ 
    { "#color" :  "color:black" },
        { "#size" : "size:L" }
    ] 
 }
 } 
    }
    }
}'{code}
 

Finally [~mkhludnev]'s helped me to find a working version, which doesn't look 
obvious for me.
{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
    "query" : {
    "parent": {
 "which": "scope:product",
    "query": {
   "bool": {
   "must":"scope:sku",
   "filter":[ 
   { "#color" : {lucene: { "query":"color:black"} 
}},
   { "#size" : {lucene: { "query":"size:L"} }}
            
    ] 
 }
 } 
    }
    }
}'{code}
Let me express my huge thanks to [~mkhludnev] for his incredible creativity and 
support.

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-8278) UAX29URLEmailTokenizer is not detecting some tokens as URL type

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated LUCENE-8278:
---
Attachment: unpatched.png
patched.png

> UAX29URLEmailTokenizer is not detecting some tokens as URL type
> ---
>
> Key: LUCENE-8278
> URL: https://issues.apache.org/jira/browse/LUCENE-8278
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Junte Zhang
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: LUCENE-8278.patch, patched.png, unpatched.png
>
>
> We are using the UAX29URLEmailTokenizer so we can use the token types in our 
> plugins.
> However, I noticed that the tokenizer is not detecting certain URLs as  
> but  instead.
> Examples that are not working:
>  * example.com is 
>  * example.net is 
> But:
>  * https://example.com is 
>  * as is https://example.net
> Examples that work:
>  * example.ch is 
>  * example.co.uk is 
>  * example.nl is 
> I have checked this JIRA, and could not find an issue. I have tested this on 
> Lucene (Solr) 6.4.1 and 7.3.
> Could someone confirm my findings and advise what I could do to (help) 
> resolve this issue?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1045 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1045/

No tests ran.

Build Log:
[...truncated 10 lines...]
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git fetch --tags --progress 
git://git.apache.org/lucene-solr.git +refs/heads/*:refs/remotes/origin/*" 
returned status code 128:
stdout: 
stderr: remote: Counting objects: 156561   
remote: Counting objects: 320904   
remote: Counting objects: 449064   
remote: Counting objects: 571288   
remote: Counting objects: 718670   
remote: Counting objects: 877624   
remote: Counting objects: 969773, done.
remote: Compressing objects:   0% (1/187895)   
remote: Compressing objects:   1% (1879/187895)   
remote: Compressing objects:   2% (3758/187895)   
remote: Compressing objects:   3% (5637/187895)   
remote: Compressing objects:   4% (7516/187895)   
remote: Compressing objects:   5% (9395/187895)   
remote: Compressing objects:   6% (11274/187895)   
remote: Compressing objects:   7% (13153/187895)   
remote: Compressing objects:   8% (15032/187895)   
remote: Compressing objects:   9% (16911/187895)   
remote: Compressing objects:  10% (18790/187895)   
remote: Compressing objects:  11% (20669/187895)   
remote: Compressing objects:  12% (22548/187895)   
remote: Compressing objects:  13% (24427/187895)   
remote: Compressing objects:  14% (26306/187895)   
remote: Compressing objects:  15% (28185/187895)   
remote: Compressing objects:  16% (30064/187895)   
remote: Compressing objects:  17% (31943/187895)   
remote: Compressing objects:  18% (33822/187895)   
remote: Compressing objects:  19% (35701/187895)   
remote: Compressing objects:  20% (37579/187895)   
remote: Compressing objects:  21% (39458/187895)   
remote: Compressing objects:  22% (41337/187895)   
remote: Compressing objects:  23% (43216/187895)   
remote: Compressing objects:  24% (45095/187895)   
remote: Compressing objects:  25% (46974/187895)   
remote: Compressing objects:  26% (48853/187895)   
remote: Compressing objects:  27% (50732/187895)   
remote: Compressing objects:  28% (52611/187895)   
remote: Compressing objects:  29% (54490/187895)   
remote: Compressing objects:  30% (56369/187895)   
remote: Compressing objects:  31% (58248/187895)   
remote: Compressing objects:  32% (60127/187895)   
remote: Compressing objects:  33% (62006/187895)   
remote: Compressing objects:  34% (63885/187895)   
remote: Compressing objects:  35% (65764/187895)   
remote: Compressing objects:  36% (67643/187895)   
remote: Compressing objects:  37% (69522/187895)   
remote: Compressing objects:  38% (71401/187895)   
remote: Compressing objects:  39% (73280/187895)   
remote: Compressing objects:  40% (75158/187895)   
remote: Compressing objects:  41% (77037/187895)   
remote: Compressing objects:  42% (78916/187895)   
remote: Compressing objects:  43% (80795/187895)   
remote: Compressing objects:  44% (82674/187895)   
remote: Compressing objects:  45% (84553/187895)   
remote: Compressing objects:  46% (86432/187895)   
remote: Compressing objects:  47% (88311/187895)   
remote: Compressing objects:  48% (90190/187895)   
remote: Compressing objects:  49% (92069/187895)   
remote: Compressing objects:  50% (93948/187895)   
remote: Compressing objects:  51% (95827/187895)   
remote: Compressing objects:  52% (97706/187895)   
remote: Compressing objects:  53% (99585/187895)   
remote: Compressing objects:  54% (101464/187895)   
remote: Compressing objects:  55% (103343/187895)   
remote: Compressing objects:  56% (105222/187895)   
remote: Compressing objects:  57% (107101/187895)   
remote: Compressing objects:  58% (108980/187895)   
remote: Compressing objects:  59% (110859/187895)   
remote: Compressing objects:  60% (112737/187895)   
remote: Compressing objects:  61% (114616/187895)   
remote: Compressing objects:  62% (116495/187895)   
remote: Compressing objects:  63% (118374/187895)   
remote: Compressing objects:  64% (120253/187895)   
remote: Compressing objects:  65% (122132/187895)   
remote: Compressing objects:  66% (124011/187895)   
remote: Compressing objects:  67% (125890/187895)   
remote: Compressing objects:  68% (127769/187895)   
remote: Compressing objects:  69% (129648/187895)   
remote: Compressing objects:  70% (131527/187895)   
remote: Compressing objects:  71% (133406/187895)  

Re: BadApple report

[Andrzej Białecki]

> On 11 Jun 2018, at 17:51, Erick Erickson  wrote:
> 
> IndexSizeTriggerTest.testMixedBounds

I committed a change today that should fix this.

> SearchRateTriggerTest.testTrigger

> TestLargeCluster.testBasic
> TestLargeCluster.testNodeLost

On June 6 I made a change that should fix these tests.

--
Best regards,
Andrzej Bialecki

--=# http://www.lucidworks.com #=--

[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508692#comment-16508692
 ] 

Robert Muir commented on LUCENE-8041:
-

This has the downside that it sorts all fields on every call to iterator(). My 
concern is mainly that it will introduce performance problems down the line, 
ones that are difficult to find/debug because of java's syntactic sugar around 
iterator(). Especially if someone is using MultiFields (slow-wrapper crap), 
they will be doing a bunch of sorts on each segment, then merging those, and 
all hidden behind a single call to iterator().

I still feel the best would be to remove this map entirely: then you can be 
sure there aren't traps. The only thing blocking this is the fact that 
term-vector options are configurable per-doc, which doesnt make sense anyway.

> All Fields.terms(fld) impls should be O(1) not O(log(N))
> 
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds.  The O(log(N)) 
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time, 
> if I recall.  There are many Field implementations that are impacted... in 
> part because Fields is the base class of FieldsProducer.  
> As an aside, I hope Fields to go away some day; FieldsProducer should be 
> TermsProducer and not have an iterator of fields. If DocValuesProducer 
> doesn't have this then why should the terms index part of our API have it?  
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator 
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap 
> in many cases if we can assume when we initialize these internal maps that we 
> consume them in sorted order to begin with.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-12477) Return server error(500) for AlreadyClosedException instead of client Errors(400)

[jefferyyuan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jefferyyuan updated SOLR-12477:
---
Environment: (was: In some cases(for example: corrupt index), addDoc0 
throws AlreadyClosedException, but solr server returns client error 400 to 
client

This will confuse customers and especially monitoring tool.

Patch: https://github.com/apache/lucene-solr/pull/402)
 Labels: update  (was: )
Description: 
In some cases(for example: corrupt index), addDoc0 throws 
AlreadyClosedException, but solr server returns client error 400 to client

This will confuse customers and especially monitoring tool.

Patch: [https://github.com/apache/lucene-solr/pull/402]

> Return server error(500) for AlreadyClosedException instead of client 
> Errors(400)
> -
>
> Key: SOLR-12477
> URL: https://issues.apache.org/jira/browse/SOLR-12477
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: 7.3.1, master (8.0)
>Reporter: jefferyyuan
>Priority: Minor
>  Labels: update
> Fix For: 7.3.2, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In some cases(for example: corrupt index), addDoc0 throws 
> AlreadyClosedException, but solr server returns client error 400 to client
> This will confuse customers and especially monitoring tool.
> Patch: [https://github.com/apache/lucene-solr/pull/402]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-12477) Return server error(500) for AlreadyClosedException instead of client Errors(400)

[jefferyyuan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jefferyyuan updated SOLR-12477:
---
Environment: 
In some cases(for example: corrupt index), addDoc0 throws 
AlreadyClosedException, but solr server returns client error 400 to client

This will confuse customers and especially monitoring tool.

Patch: https://github.com/apache/lucene-solr/pull/402

  was:
In some cases(for example: corrupt index), addDoc0 throws 
AlreadyClosedException, but solr server returns client error 400 to client

This will confuse customers and especially monitoring tool.


> Return server error(500) for AlreadyClosedException instead of client 
> Errors(400)
> -
>
> Key: SOLR-12477
> URL: https://issues.apache.org/jira/browse/SOLR-12477
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: 7.3.1, master (8.0)
> Environment: In some cases(for example: corrupt index), addDoc0 
> throws AlreadyClosedException, but solr server returns client error 400 to 
> client
> This will confuse customers and especially monitoring tool.
> Patch: https://github.com/apache/lucene-solr/pull/402
>Reporter: jefferyyuan
>Priority: Minor
> Fix For: 7.3.2, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #402: SOLR-12477 - Return server error(500) for Alr...

[jefferyyuan]

GitHub user jefferyyuan opened a pull request:

https://github.com/apache/lucene-solr/pull/402

SOLR-12477 - Return server error(500) for AlreadyClosedException instead of 
client Errors(400)



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jefferyyuan/lucene-solr master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/402.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 #402


commit 5a9ceb63511de3fd3452f6b0cc65cc41dc5ae6e9
Author: yyuan2 
Date:   2018-06-11T20:22:14Z

SOLR-12477 - Return server error(500) for AlreadyClosedException instead of 
client Errors(400)




---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-12477) Return server error(500) for AlreadyClosedException instead of client Errors(400)

[jefferyyuan (JIRA)]

jefferyyuan created SOLR-12477:
--

 Summary: Return server error(500) for AlreadyClosedException 
instead of client Errors(400)
 Key: SOLR-12477
 URL: https://issues.apache.org/jira/browse/SOLR-12477
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: update
Affects Versions: 7.3.1, master (8.0)
 Environment: In some cases(for example: corrupt index), addDoc0 throws 
AlreadyClosedException, but solr server returns client error 400 to client

This will confuse customers and especially monitoring tool.
Reporter: jefferyyuan
 Fix For: 7.3.2, master (8.0)






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))

[David Smiley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-8041:
-
Summary: All Fields.terms(fld) impls should be O(1) not O(log(N))  (was: 
All Fields.terms(fld) impls should be O(N) not O(log(N)))

> All Fields.terms(fld) impls should be O(1) not O(log(N))
> 
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds.  The O(log(N)) 
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time, 
> if I recall.  There are many Field implementations that are impacted... in 
> part because Fields is the base class of FieldsProducer.  
> As an aside, I hope Fields to go away some day; FieldsProducer should be 
> TermsProducer and not have an iterator of fields. If DocValuesProducer 
> doesn't have this then why should the terms index part of our API have it?  
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator 
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap 
> in many cases if we can assume when we initialize these internal maps that we 
> consume them in sorted order to begin with.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12223) Document 'Initial Startup' for bidirectional approach in CDCR

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508651#comment-16508651
 ] 

ASF subversion and git services commented on SOLR-12223:


Commit 930603e2323222928882bc23f7bfbf1b9bb0a207 in lucene-solr's branch 
refs/heads/branch_7_4 from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=930603e ]

SOLR-12223: Update docs to add Initial Startup section for bi-directional 
updates


> Document 'Initial Startup' for bidirectional approach in CDCR
> -
>
> Key: SOLR-12223
> URL: https://issues.apache.org/jira/browse/SOLR-12223
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, documentation
>Affects Versions: 7.3
>Reporter: Amrit Sarkar
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: 7.4
>
> Attachments: SOLR-12223.patch
>
>
> Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12223) Document 'Initial Startup' for bidirectional approach in CDCR

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508650#comment-16508650
 ] 

ASF subversion and git services commented on SOLR-12223:


Commit 6cfd3b78845409ea9f2ef5b7a6e2703a8aecca2c in lucene-solr's branch 
refs/heads/branch_7x from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6cfd3b7 ]

SOLR-12223: Update docs to add Initial Startup section for bi-directional 
updates


> Document 'Initial Startup' for bidirectional approach in CDCR
> -
>
> Key: SOLR-12223
> URL: https://issues.apache.org/jira/browse/SOLR-12223
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, documentation
>Affects Versions: 7.3
>Reporter: Amrit Sarkar
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: 7.4
>
> Attachments: SOLR-12223.patch
>
>
> Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12223) Document 'Initial Startup' for bidirectional approach in CDCR

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508644#comment-16508644
 ] 

ASF subversion and git services commented on SOLR-12223:


Commit fc3f64269272f6daba3cad5bb4a8b623cc7b9373 in lucene-solr's branch 
refs/heads/master from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fc3f642 ]

SOLR-12223: Update docs to add Initial Startup section for bi-directional 
updates


> Document 'Initial Startup' for bidirectional approach in CDCR
> -
>
> Key: SOLR-12223
> URL: https://issues.apache.org/jira/browse/SOLR-12223
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, documentation
>Affects Versions: 7.3
>Reporter: Amrit Sarkar
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: 7.4
>
> Attachments: SOLR-12223.patch
>
>
> Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10.0.1) - Build # 2105 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2105/
Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/45)={   
"replicationFactor":"2",   "pullReplicas":"0",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0",   
"autoCreated":"true",   "shards":{ "shard2":{   "replicas":{ 
"core_node3":{   
"core":"testSplitIntegration_collection_shard2_replica_n3",   
"leader":"true",   "SEARCHER.searcher.maxDoc":11,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":1,   
"node_name":"127.0.0.1:10002_solr",   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":11}, "core_node4":{ 
  "core":"testSplitIntegration_collection_shard2_replica_n4",   
"SEARCHER.searcher.maxDoc":11,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",  
 "state":"active",   "type":"NRT",   
"SEARCHER.searcher.numDocs":11}},   "range":"0-7fff",   
"state":"active"}, "shard1":{   "stateTimestamp":"1528796007711408300", 
  "replicas":{ "core_node1":{   
"core":"testSplitIntegration_collection_shard1_replica_n1",   
"leader":"true",   "SEARCHER.searcher.maxDoc":14,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":1,   
"node_name":"127.0.0.1:10002_solr",   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":14}, "core_node2":{ 
  "core":"testSplitIntegration_collection_shard1_replica_n2",   
"SEARCHER.searcher.maxDoc":14,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",  
 "state":"active",   "type":"NRT",   
"SEARCHER.searcher.numDocs":14}},   "range":"8000-",   
"state":"inactive"}, "shard1_1":{   "parent":"shard1",   
"stateTimestamp":"1528796007725371100",   "range":"c000-",  
 "state":"active",   "replicas":{ "core_node10":{   
"leader":"true",   
"core":"testSplitIntegration_collection_shard1_1_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10002_solr",   
"base_url":"http://127.0.0.1:10002/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}, 
"core_node9":{   
"core":"testSplitIntegration_collection_shard1_1_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}}}, "shard1_0":{  
 "parent":"shard1",   "stateTimestamp":"1528796007725053350",   
"range":"8000-bfff",   "state":"active",   "replicas":{ 
"core_node7":{   "leader":"true",   
"core":"testSplitIntegration_collection_shard1_0_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}, 
"core_node8":{   
"core":"testSplitIntegration_collection_shard1_0_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10002_solr",   
"base_url":"http://127.0.0.1:10002/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}

Stack Trace:
java.util.concurrent.TimeoutException: last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/45)={
  "replicationFactor":"2",
  "pullReplicas":"0",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0",
  "autoCreated":"true",
  "shards":{
"shard2":{
  "replicas":{
"core_node3":{
  "core":"testSplitIntegration_collection_shard2_replica_n3",
  "leader":"true",
  "SEARCHER.searcher.maxDoc":11,
  "SEARCHER.searcher.deletedDocs":0,
  "INDEX.sizeInBytes":1,
  "node_name":"127.0.0.1:10002_solr",
  

[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(N) not O(log(N))

[Nhat Nguyen (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508636#comment-16508636
 ] 

Nhat Nguyen commented on LUCENE-8041:
-

I submitted a simple patch that replaces TreeMap by HashMap in 
BlockTreeTermsReader and PerFieldPostingsFormat#FieldsReader. Can someone 
please update the title of the issue? It should be O(1) instead of O(N). Thanks!

> All Fields.terms(fld) impls should be O(N) not O(log(N))
> 
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds.  The O(log(N)) 
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time, 
> if I recall.  There are many Field implementations that are impacted... in 
> part because Fields is the base class of FieldsProducer.  
> As an aside, I hope Fields to go away some day; FieldsProducer should be 
> TermsProducer and not have an iterator of fields. If DocValuesProducer 
> doesn't have this then why should the terms index part of our API have it?  
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator 
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap 
> in many cases if we can assume when we initialize these internal maps that we 
> consume them in sorted order to begin with.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-8041) All Fields.terms(fld) impls should be O(N) not O(log(N))

[Nhat Nguyen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nhat Nguyen updated LUCENE-8041:

Attachment: LUCENE-8041.patch

> All Fields.terms(fld) impls should be O(N) not O(log(N))
> 
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds.  The O(log(N)) 
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time, 
> if I recall.  There are many Field implementations that are impacted... in 
> part because Fields is the base class of FieldsProducer.  
> As an aside, I hope Fields to go away some day; FieldsProducer should be 
> TermsProducer and not have an iterator of fields. If DocValuesProducer 
> doesn't have this then why should the terms index part of our API have it?  
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator 
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap 
> in many cases if we can assume when we initialize these internal maps that we 
> consume them in sorted order to begin with.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12476) Upgrade Notes for 7.4 Ref Guide

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508619#comment-16508619
 ] 

Cassandra Targett commented on SOLR-12476:
--

ack, typo in my commit message which I cherrypicked through the 
branches...here's links to the commits for this:

master: 
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=16242997
branch_7x: 
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=5f6677e9
branch_7_4: 
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=dc94a76b

> Upgrade Notes for 7.4 Ref Guide
> ---
>
> Key: SOLR-12476
> URL: https://issues.apache.org/jira/browse/SOLR-12476
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
> Fix For: 7.4
>
>
> Add upgrade notes from CHANGES to the Ref Guide for 7.4



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-12476) Upgrade Notes for 7.4 Ref Guide

[Cassandra Targett (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cassandra Targett resolved SOLR-12476.
--
Resolution: Fixed

> Upgrade Notes for 7.4 Ref Guide
> ---
>
> Key: SOLR-12476
> URL: https://issues.apache.org/jira/browse/SOLR-12476
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
> Fix For: 7.4
>
>
> Add upgrade notes from CHANGES to the Ref Guide for 7.4



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #400: Put example query on its own line. Also fixes...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/lucene-solr/pull/400


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #401: Autoscaling Suggestions API page typo

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/lucene-solr/pull/401


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-6733) Umbrella issue - Solr as a standalone application

[Shawn Heisey (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508512#comment-16508512
 ] 

Shawn Heisey commented on SOLR-6733:


I can't seem to get the branch to work right, so I've gone another way.  I've 
forked it on github.

https://github.com/elyograg/solr-6733

As soon as I get it checked out, I will apply my patch and push the change.  
Give it an hour, should be done by then.


> Umbrella issue - Solr as a standalone application
> -
>
> Key: SOLR-6733
> URL: https://issues.apache.org/jira/browse/SOLR-6733
> Project: Solr
>  Issue Type: New Feature
>Reporter: Shawn Heisey
>Priority: Major
>
> Umbrella issue.
> Solr should be a standalone application, where the main method is provided by 
> Solr source code.
> Here are the major tasks I envision, if we choose to embed Jetty:
>  * Create org.apache.solr.start.Main (and possibly other classes in the same 
> package), to be placed in solr-start.jar.  The Main class will contain the 
> main method that starts the embedded Jetty and Solr.  I do not know how to 
> adjust the build system to do this successfully.
>  * Handle central configurations in code -- TCP port, SSL, and things like 
> web.xml.
>  * For each of these steps, clean up any test fallout.
>  * Handle cloud-related configurations in code -- port, hostname, protocol, 
> etc.  Use the same information as the central configurations.
>  * Consider whether things like authentication need changes.
>  * Handle any remaining container configurations.
> I am currently imagining this work happening in a new branch and ultimately 
> being applied only to master, not the stable branch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-9685) tag a query in JSON syntax

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508417#comment-16508417
 ] 

Mikhail Khludnev edited comment on SOLR-9685 at 6/11/18 6:35 PM:
-

[~osavrasov], beside of incorrect json, it seems like JSON DSL makes 
{{filters}} a little bit redundant. It's worth to try to write {{parent}} in 
JSON query DSL and use 
[bool|https://lucene.apache.org/solr/guide/7_3/json-query-dsl.html#compound-queries]
 as a child query with tagged filter clauses. 


was (Author: mkhludnev):
[~osavrasov], beside of incorrect json, it seems like JSON DSL makes 
{{filters}} a little bit redundant. It's worth to try to write {{parent}} in 
JSON query DSL and use 
[https://lucene.apache.org/solr/guide/7_3/json-query-dsl.html#compound-queries|bool]
 as a child query with tagged filter clauses. 

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-12476) Upgrade Notes for 7.4 Ref Guide

[Cassandra Targett (JIRA)]

Cassandra Targett created SOLR-12476:


 Summary: Upgrade Notes for 7.4 Ref Guide
 Key: SOLR-12476
 URL: https://issues.apache.org/jira/browse/SOLR-12476
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Reporter: Cassandra Targett
 Fix For: 7.4


Add upgrade notes from CHANGES to the Ref Guide for 7.4



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-12476) Upgrade Notes for 7.4 Ref Guide

[Cassandra Targett (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cassandra Targett reassigned SOLR-12476:


Assignee: Cassandra Targett

> Upgrade Notes for 7.4 Ref Guide
> ---
>
> Key: SOLR-12476
> URL: https://issues.apache.org/jira/browse/SOLR-12476
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
> Fix For: 7.4
>
>
> Add upgrade notes from CHANGES to the Ref Guide for 7.4



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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 # 2561 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2561/

2 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCloudCollectionsListeners.testCollectionDeletion

Error Message:
Could not load collection from ZK: testcollection1

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
testcollection1
at 
__randomizedtesting.SeedInfo.seed([C7A6837356307D97:16FB8B77FFC3A461]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1316)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:732)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:148)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:131)
at 
org.apache.solr.common.cloud.ZkStateReader.registerCollectionStateWatcher(ZkStateReader.java:1434)
at 
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1464)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:450)
at 
org.apache.solr.common.cloud.TestCloudCollectionsListeners.testCollectionDeletion(TestCloudCollectionsListeners.java:137)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

Re: [Lucene/Solr] Patches pending for review

[Jan Høydahl]

+1 same here. You communicate with the community in a clear and structured way. 
Often a nudge or two is necessary for attention...

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 11. jun. 2018 kl. 17:35 skrev David Smiley :
> 
> Although not a direct response to the issues you've raised, I just want to 
> say that your contributions are much appreciated and to keep up the good 
> work!   Thank you.
> 
> On Mon, Jun 11, 2018 at 6:00 AM Alessandro Benedetti  > wrote:
> UP
> Any feedback from the community ?
> I would be more than happy to contribute these bugfixes/improvements.
> 
> If any of them is not of interest/ has been superseded by other developments 
> I would be equally happy to know and  move on to other activities.
> 
> Regards
> 
> --
> Alessandro Benedetti
> Search Consultant, R Software Engineer, Director
> 
> www.sease.io 
> On Wed, Jun 6, 2018 at 11:30 AM, Alessandro Benedetti  > wrote:
> Hi all,
> I have a lot of Lucene/Solr patches covering different areas waiting for an 
> initial review.
> 
> All of them have  :
> - Code change
> - Related tests
> - Pull Request in Github
> - Patch attached
> 
> I am sure they are not perfect, but I believe they are ready for a review.
> Happy to work on the contributions and to fix/improve anything necessary.
> 
> Some of them are bug fixes, some of them are improvements.
> It's a couple of months I don't get any progress in the review process for 
> some of them, so I hope listing them here would help the community :
> 
> Bugs
> [LUCENE-6687]  More Like 
> This Bug
> [LUCENE-8343]  
> BlendedInfixSuggester Bug
> [LUCENE-8329]  Size 
> Estimator Bug
> [SOLR-12304]  More Like 
> This Bug Solr side
> 
> Improvements
> [LUCENE-8326 ] More Like 
> This Params Refactor
> [LUCENE-8347]  
> BlendedInfixSuggester Improvement
> [SOLR-12238]  Synonym Query 
> Style Boost By Payload
> [SOLR-12243]  Edismax Bug ( 
> Elizabeth Haubert, me)
> 
> Regards
> --
> Alessandro Benedetti
> Search Consultant, R Software Engineer, Director
> 
> www.sease.io 
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley 
>  | Book: 
> http://www.solrenterprisesearchserver.com 
> 

[jira] [Commented] (SOLR-12392) IndexSizeTriggerTest fails too frequently.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508427#comment-16508427
 ] 

ASF subversion and git services commented on SOLR-12392:


Commit 2556faefe042bd38395c93fb252055f7569af35d in lucene-solr's branch 
refs/heads/branch_7x from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2556fae ]

SOLR-12392: Don't create conflicting ops when docs / index size criteria 
conflict.


> IndexSizeTriggerTest fails too frequently.
> --
>
> Key: SOLR-12392
> URL: https://issues.apache.org/jira/browse/SOLR-12392
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12457) Multi valued field sorting doesn't work on trie fields

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508423#comment-16508423
 ] 

Hoss Man commented on SOLR-12457:
-

Hmmm... i guess it never occured to me to add a cloud based test to SOLR-2522? 
... crap, sorry about that.

(FWIW: I think TestMinMaxOnMultiValuedField could be converted to a MiniCloud 
based test fairly easily)



I'm not possitive, but I *think* the fix here is that the Trie based fields 
need to override FieldType.marshalSortValue (& maybe unmarshalSortValue) to 
check if the field is multivalued & if so explicitly deal with the BytesRef 
values that come out of the SortedSetDocValuesField ... i think the marshal 
method can probably just go ahead and convert to the "real" numeric value, and 
the unmarshal method can just inherit the default behavior? ... not certain.

I suspect this bug may also affect StrField (SOLR-11854) and SortableTextField 
(SOLR-11916) but the fix should likewise be straight forward (i hope)

> Multi valued field sorting doesn't work on trie fields
> --
>
> Key: SOLR-12457
> URL: https://issues.apache.org/jira/browse/SOLR-12457
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1
>Reporter: Varun Thacker
>Priority: Major
>
> When I go to sort on a multi-valued field in a 2 shard collection, which has 
> trie fields the query fails.
> To reproduce we need 2+ shards, a multi-valued trie field and "desc" sort 
> criteria.
> Here's my schema
> {code:java}
>  multiValued="true" docValues="true"/>
>  positionIncrementGap="0" precisionStep="0"/>
>  multiValued="true"/>
> 
> {code}
> Now If I add a few docs
> {code:java}
> [
> {"id" : "1", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2", 
> "3", "4", "5"]},
> {"id" : "2", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2", 
> "3", "4", "5"]},
> {"id" : "3", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2", 
> "3", "4", "5"]}
> ]{code}
> Works:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_i,max)%20desc]
>  
> Doesn't Work:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_is,max)%20desc]
>  
> To be more clear when I say it doesn't work , the query throws and error and 
> here's the stack trace for it:
> {code:java}
> ERROR - 2018-06-06 22:55:06.599; [c:gettingstarted s:shard2 r:core_node8 
> x:gettingstarted_shard2_replica_n5] org.apache.solr.common.SolrException; 
> null:java.lang.ClassCastException: java.lang.String cannot be cast to 
> org.apache.lucene.util.BytesRef
>         at 
> org.apache.lucene.search.FieldComparator$TermOrdValComparator.compareValues(FieldComparator.java:561)
>         at 
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:161)
>         at 
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:153)
>         at 
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:91)
>         at 
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:33)
>         at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:263)
>         at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:140)
>         at 
> org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:156)
>         at 
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:924)
>         at 
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
>         at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
>         at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
>         at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>         at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
>         at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
>         at 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:526){code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9685) tag a query in JSON syntax

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508417#comment-16508417
 ] 

Mikhail Khludnev commented on SOLR-9685:


[~osavrasov], beside of incorrect json, it seems like JSON DSL makes 
{{filters}} a little bit redundant. It's worth to try to write {{parent}} in 
JSON query DSL and use 
[https://lucene.apache.org/solr/guide/7_3/json-query-dsl.html#compound-queries|bool]
 as a child query with tagged filter clauses. 

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9685) tag a query in JSON syntax

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508387#comment-16508387
 ] 

Mikhail Khludnev commented on SOLR-9685:


[~ctargett], I'm working on ref guide, turns out it requires to document some 
details in json facet as well. 

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9480) Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508381#comment-16508381
 ] 

ASF subversion and git services commented on SOLR-9480:
---

Commit 5ad72490a0d0bfca045549f11fff3deb655fec3c in lucene-solr's branch 
refs/heads/branch_7_4 from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5ad7249 ]

SOLR-9480: Ref Guide minor typo cleanup; remove outdated/unnecessary anchors


> Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)
> --
>
> Key: SOLR-9480
> URL: https://issues.apache.org/jira/browse/SOLR-9480
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Trey Grainger
>Assignee: Hoss Man
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9480.patch, SOLR-9480.patch, SOLR-9480.patch, 
> SOLR-9480.patch, SOLR-9480.patch, SOLR-9480.patch
>
>
> This issue is to track the contribution of the Semantic Knowledge Graph Solr 
> Plugin (request handler), which exposes a graph-like interface for 
> discovering and traversing significant relationships between entities within 
> an inverted index.
> This data model has been described in the following research paper: [The 
> Semantic Knowledge Graph: A compact, auto-generated model for real-time 
> traversal and ranking of any relationship within a 
> domain|https://arxiv.org/abs/1609.00464], as well as in presentations I gave 
> in October 2015 at [Lucene/Solr 
> Revolution|http://www.slideshare.net/treygrainger/leveraging-lucenesolr-as-a-knowledge-graph-and-intent-engine]
>  and November 2015 at the [Bay Area Search 
> Meetup|http://www.treygrainger.com/posts/presentations/searching-on-intent-knowledge-graphs-personalization-and-contextual-disambiguation/].
> The source code for this project is currently available at 
> [https://github.com/careerbuilder/semantic-knowledge-graph], and the folks at 
> CareerBuilder (where this was built) have given me the go-ahead to now 
> contribute this back to the Apache Solr Project, as well.
> Check out the Github repository, research paper, or presentations for a more 
> detailed description of this contribution. Initial patch coming soon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9480) Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508380#comment-16508380
 ] 

ASF subversion and git services commented on SOLR-9480:
---

Commit eb9493552ac2709b7e656c685967a14ec66ddb8b in lucene-solr's branch 
refs/heads/branch_7x from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eb94935 ]

SOLR-9480: Ref Guide minor typo cleanup; remove outdated/unnecessary anchors


> Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)
> --
>
> Key: SOLR-9480
> URL: https://issues.apache.org/jira/browse/SOLR-9480
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Trey Grainger
>Assignee: Hoss Man
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9480.patch, SOLR-9480.patch, SOLR-9480.patch, 
> SOLR-9480.patch, SOLR-9480.patch, SOLR-9480.patch
>
>
> This issue is to track the contribution of the Semantic Knowledge Graph Solr 
> Plugin (request handler), which exposes a graph-like interface for 
> discovering and traversing significant relationships between entities within 
> an inverted index.
> This data model has been described in the following research paper: [The 
> Semantic Knowledge Graph: A compact, auto-generated model for real-time 
> traversal and ranking of any relationship within a 
> domain|https://arxiv.org/abs/1609.00464], as well as in presentations I gave 
> in October 2015 at [Lucene/Solr 
> Revolution|http://www.slideshare.net/treygrainger/leveraging-lucenesolr-as-a-knowledge-graph-and-intent-engine]
>  and November 2015 at the [Bay Area Search 
> Meetup|http://www.treygrainger.com/posts/presentations/searching-on-intent-knowledge-graphs-personalization-and-contextual-disambiguation/].
> The source code for this project is currently available at 
> [https://github.com/careerbuilder/semantic-knowledge-graph], and the folks at 
> CareerBuilder (where this was built) have given me the go-ahead to now 
> contribute this back to the Apache Solr Project, as well.
> Check out the Github repository, research paper, or presentations for a more 
> detailed description of this contribution. Initial patch coming soon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9480) Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508378#comment-16508378
 ] 

ASF subversion and git services commented on SOLR-9480:
---

Commit 74576b008311a0d2f84a8ad196957cbad1b3fc05 in lucene-solr's branch 
refs/heads/master from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=74576b0 ]

SOLR-9480: Ref Guide minor typo cleanup; remove outdated/unnecessary anchors


> Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)
> --
>
> Key: SOLR-9480
> URL: https://issues.apache.org/jira/browse/SOLR-9480
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Trey Grainger
>Assignee: Hoss Man
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9480.patch, SOLR-9480.patch, SOLR-9480.patch, 
> SOLR-9480.patch, SOLR-9480.patch, SOLR-9480.patch
>
>
> This issue is to track the contribution of the Semantic Knowledge Graph Solr 
> Plugin (request handler), which exposes a graph-like interface for 
> discovering and traversing significant relationships between entities within 
> an inverted index.
> This data model has been described in the following research paper: [The 
> Semantic Knowledge Graph: A compact, auto-generated model for real-time 
> traversal and ranking of any relationship within a 
> domain|https://arxiv.org/abs/1609.00464], as well as in presentations I gave 
> in October 2015 at [Lucene/Solr 
> Revolution|http://www.slideshare.net/treygrainger/leveraging-lucenesolr-as-a-knowledge-graph-and-intent-engine]
>  and November 2015 at the [Bay Area Search 
> Meetup|http://www.treygrainger.com/posts/presentations/searching-on-intent-knowledge-graphs-personalization-and-contextual-disambiguation/].
> The source code for this project is currently available at 
> [https://github.com/careerbuilder/semantic-knowledge-graph], and the folks at 
> CareerBuilder (where this was built) have given me the go-ahead to now 
> contribute this back to the Apache Solr Project, as well.
> Check out the Github repository, research paper, or presentations for a more 
> detailed description of this contribution. Initial patch coming soon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-12138) CLONE - AutoscalingHistoryHandlerTest fails frequently

[Andrzej Bialecki (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrzej Bialecki  resolved SOLR-12138.
--
Resolution: Duplicate

> CLONE - AutoscalingHistoryHandlerTest fails frequently
> --
>
> Key: SOLR-12138
> URL: https://issues.apache.org/jira/browse/SOLR-12138
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Xijia Ding
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 7.4, master (8.0)
>
> Attachments: tests-failures.txt
>
>
> This test fails frequently on jenkins with a failed assertion (see also 
> SOLR-11378 for other failure mode):
> {code}
>[junit4] FAILURE 6.49s J2 | AutoscalingHistoryHandlerTest.testHistory <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<8> but 
> was:<6>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([164F10BB7F145FDE:7BB3B446C55CA0D9]:0)
>[junit4]>  at 
> org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory(AutoscalingHistoryHandlerTest.java:194)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-12181) Add trigger based on document count

[Andrzej Bialecki (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrzej Bialecki  resolved SOLR-12181.
--
Resolution: Fixed

The work here is done - occasional test failures are tracked in SOLR-12392.

> Add trigger based on document count
> ---
>
> Key: SOLR-12181
> URL: https://issues.apache.org/jira/browse/SOLR-12181
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12181.patch
>
>
> This may turn out to be as simple as using a {{MetricTrigger}} but it's 
> likely this will require some specialization, and we may want to add this 
> type of trigger anyway for convenience.
> The two control actions associated with this trigger will be SPLITSHARD and 
> (yet nonexistent) MERGESHARD.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-12070) TestJMXIntegration.testJMXOnCoreReload always fails

[Andrzej Bialecki (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrzej Bialecki  resolved SOLR-12070.
--
   Resolution: Fixed
Fix Version/s: 7.3
   master (8.0)

> TestJMXIntegration.testJMXOnCoreReload always fails
> ---
>
> Key: SOLR-12070
> URL: https://issues.apache.org/jira/browse/SOLR-12070
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3, master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: master (8.0), 7.3
>
>
> This test is marked @BadApple but the issue it refers to probably doesn't 
> apply anymore since the JMX integration has been substantially changed as a 
> part of the metrics refactoring.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-11407) AutoscalingHistoryHandlerTest fails frequently

[Andrzej Bialecki (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrzej Bialecki  resolved SOLR-11407.
--
Resolution: Fixed

Not seen in recent builds.

> AutoscalingHistoryHandlerTest fails frequently
> --
>
> Key: SOLR-11407
> URL: https://issues.apache.org/jira/browse/SOLR-11407
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 7.4, master (8.0)
>
> Attachments: tests-failures.txt
>
>
> This test fails frequently on jenkins with a failed assertion (see also 
> SOLR-11378 for other failure mode):
> {code}
>[junit4] FAILURE 6.49s J2 | AutoscalingHistoryHandlerTest.testHistory <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<8> but 
> was:<6>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([164F10BB7F145FDE:7BB3B446C55CA0D9]:0)
>[junit4]>  at 
> org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory(AutoscalingHistoryHandlerTest.java:194)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-11912) TriggerIntegrationTest fails a lot, reproducibly

[Andrzej Bialecki (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-11912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrzej Bialecki  resolved SOLR-11912.
--
Resolution: Fixed

Resolving - I haven't seen these failures for a while now. Please reopen if it 
starts failing again.

> TriggerIntegrationTest fails a lot, reproducibly
> 
>
> Key: SOLR-11912
> URL: https://issues.apache.org/jira/browse/SOLR-11912
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> Multiple tests in this suite are not just flaky, but are failing reproducibly.
> From Hoss'ss report for the last 24 hours 
> [http://fucit.org/solr-jenkins-reports/reports/24hours-method-failures.csv]:
> {noformat}
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testCooldown,thetaphi/Lucene-Solr-master-Linux/21346/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testEventFromRestoredState,apache/Lucene-Solr-NightlyTests-7.x/131/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testEventFromRestoredState,sarowe/Lucene-Solr-tests-master/14874/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testEventFromRestoredState,thetaphi/Lucene-Solr-7.x-Solaris/412/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testEventFromRestoredState,thetaphi/Lucene-Solr-master-MacOSX/4408/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testListeners,thetaphi/Lucene-Solr-master-Windows/7140/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testMetricTrigger,apache/Lucene-Solr-Tests-7.x/334/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testMetricTrigger,sarowe/Lucene-Solr-tests-7.x/2526/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testMetricTrigger,thetaphi/Lucene-Solr-7.x-Linux/1243/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testMetricTrigger,thetaphi/Lucene-Solr-7.x-Windows/424/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testMetricTrigger,thetaphi/Lucene-Solr-master-Linux/21344/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testMetricTrigger,thetaphi/Lucene-Solr-master-Linux/21345/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testMetricTrigger,thetaphi/Lucene-Solr-master-Linux/21350/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testNodeAddedTrigger,thetaphi/Lucene-Solr-master-Windows/7139/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testNodeAddedTriggerRestoreState,apache/Lucene-Solr-Tests-7.x/334/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testNodeAddedTriggerRestoreState,thetaphi/Lucene-Solr-7.x-Solaris/412/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testNodeAddedTriggerRestoreState,thetaphi/Lucene-Solr-master-MacOSX/4408/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testNodeLostTrigger,thetaphi/Lucene-Solr-7.x-Solaris/413/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testNodeLostTrigger,thetaphi/Lucene-Solr-master-Linux/21351/
> org.apache.solr.cloud.autoscaling.TriggerIntegrationTest,testNodeLostTriggerRestoreState,thetaphi/Lucene-Solr-master-MacOSX/440
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-11899) TestDistribStateManager.testGetSetRemoveData failure

[Andrzej Bialecki (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-11899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrzej Bialecki  resolved SOLR-11899.
--
Resolution: Fixed

I didn't see any failures for quite a while now.

> TestDistribStateManager.testGetSetRemoveData failure
> 
>
> Key: SOLR-11899
> URL: https://issues.apache.org/jira/browse/SOLR-11899
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
>
> {code:java}
>   [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestDistribStateManager -Dtests.method=testGetSetRemoveData 
> -Dtests.seed=2409B3FE130DD727 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.locale=es-CO -Dtests.timezone=Turkey -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>   [junit4] FAILURE 5.41s J2 | TestDistribStateManager.testGetSetRemoveData <<<
>   [junit4]    > Throwable #1: java.lang.AssertionError: Node watch should 
> have fired!
>   [junit4]    > at 
> __randomizedtesting.SeedInfo.seed([2409B3FE130DD727:2995CAC4783112D]:0)
>   [junit4]    > at 
> org.apache.solr.cloud.autoscaling.sim.TestDistribStateManager.testGetSetRemoveData(TestDistribStateManager.java:256)
>   [junit4]    > at java.lang.Thread.run(Thread.java:748)
>   [junit4]   2> 2019666 INFO  
> (TEST-TestDistribStateManager.testMulti-seed#[2409B3FE130DD727]) [    ] 
> o.a.s.SolrTestCaseJ4 ###Starting testMulti
>   [junit4]   2> 2019666 INFO  
> (TEST-TestDistribStateManager.testMulti-seed#[2409B3FE130DD727]) [    ] 
> o.a.s.c.a.s.TestDistribStateManager Using 
> org.apache.solr.cloud.autoscaling.sim.SimDistribStateManager
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10.0.1) - Build # 2104 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2104/
Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestCloudPivotFacet.test

Error Message:
Error from server at http://127.0.0.1:39207/collection1_shard1_replica_n43: 
ERROR: [doc=1] multiple values encountered for non multiValued field pivot_i: 
[37, 23, 49]

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:39207/collection1_shard1_replica_n43: ERROR: [doc=1] 
multiple values encountered for non multiValued field pivot_i: [37, 23, 49]
at 
__randomizedtesting.SeedInfo.seed([796410D4E17595D7:F1302F0E4F89F82F]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1015)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:886)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:948)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:948)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:948)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:948)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:948)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:173)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:152)
at 
org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:133)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[jira] [Commented] (SOLR-12208) Don't use "INDEX.sizeInBytes" as a tag name in policy calculations

[Andrzej Bialecki (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508311#comment-16508311
 ] 

Andrzej Bialecki  commented on SOLR-12208:
--

True - {{metricsAttribute}} sounds fine.

> Don't use "INDEX.sizeInBytes" as a tag name in policy calculations
> --
>
> Key: SOLR-12208
> URL: https://issues.apache.org/jira/browse/SOLR-12208
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-12208.patch, SOLR-12208.patch, SOLR-12208.patch
>
>
> CORE_IDX and FREEDISK ConditionType reuse this metric name, but they assume 
> the values are expressed in gigabytes. This alone is confusing considering 
> the name of the metric.
> Additionally, it causes conflicts in the simulation framework that would 
> require substantial changes to resolve (ReplicaInfo-s in 
> SimClusterStateProvider keep metric values in their variables, expressed in 
> original units - but then the Policy assumes it can put the values expressed 
> in GB under the same key... hilarity ensues).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508288#comment-16508288
 ] 

Hoss Man commented on SOLR-12194:
-

to clarify: i've never had strong opinions about this, my comments before were 
just to seek clarity on whether this was really moving in the ideal direction 
since it seemed the reverse of one of the intended usecases ... but i don't 
have enough practical experience to know if that even matters -- just wanted to 
make sure it was considered.

since you pinged me though: my only new half thought out comments/questions are 
wether these changes may complicate some of the work miller is doing (or has 
alluded to working on in personal branch i haven't seen) to "modernize" the 
solr client APIs to allow HTTP/2 and true async stuff ... ie: is exposing an 
ability to set arbitrary headers going to be problematic for that? can/should 
we ensure/enforce they are "request level" headers and prevent "connection 
level" headers? (i honestly don't even know which category authorization 
headers fall into ... 

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 7.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12274) Ref guide references to JTS is dated/inaccurate

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508284#comment-16508284
 ] 

ASF subversion and git services commented on SOLR-12274:


Commit bede9cdedce712333f3b782a3c79120c728a929d in lucene-solr's branch 
refs/heads/branch_7_4 from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bede9cd ]

SOLR-12274: Solr Ref Guide, spatial-search: Corrected obsolete JTS license info 
& location

(cherry picked from commit 9c66cd5)


> Ref guide references to JTS is dated/inaccurate
> ---
>
> Key: SOLR-12274
> URL: https://issues.apache.org/jira/browse/SOLR-12274
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.4
>
>
> The spatial-search.adoc page has two problems related to JTS:
>  # It says it's LGPL licensed.  However the version Solr now requires is ASL 
> licensed.
>  # The link is to the older version of JTS (which is not supported by Solr; 
> the package changed).  It should link to the current one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-12274) Ref guide references to JTS is dated/inaccurate

[David Smiley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved SOLR-12274.
-
   Resolution: Fixed
Fix Version/s: 7.4

> Ref guide references to JTS is dated/inaccurate
> ---
>
> Key: SOLR-12274
> URL: https://issues.apache.org/jira/browse/SOLR-12274
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.4
>
>
> The spatial-search.adoc page has two problems related to JTS:
>  # It says it's LGPL licensed.  However the version Solr now requires is ASL 
> licensed.
>  # The link is to the older version of JTS (which is not supported by Solr; 
> the package changed).  It should link to the current one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-8352) Make TokenStreamComponents final

[Mark Harwood (JIRA)]

Mark Harwood created LUCENE-8352:


 Summary: Make TokenStreamComponents final
 Key: LUCENE-8352
 URL: https://issues.apache.org/jira/browse/LUCENE-8352
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/analysis
Reporter: Mark Harwood


The current design is a little trappy. Any specialised subclasses of 
TokenStreamComponents _(see_ _StandardAnalyzer, ClassicAnalyzer, 
UAX29URLEmailAnalyzer)_ are discarded by any subsequent Analyzers that wrap 
them _(see LimitTokenCountAnalyzer, QueryAutoStopWordAnalyzer, 
ShingleAnalyzerWrapper and other examples in elasticsearch)_. 

The current design means each AnalyzerWrapper.wrapComponents() implementation 
discards any custom TokenStreamComponents and replaces it with one of its own 
choosing (a vanilla TokenStreamComponents class from examples I've seen).

This is a trap I fell into when writing a custom TokenStreamComponents with a 
custom setReader() and I wondered why it was not being triggered when wrapped 
by other analyzers.

If AnalyzerWrapper is designed to encourage composition it's arguably a mistake 
to also permit custom TokenStreamComponent subclasses  - the composition 
process does not preserve the choice of custom classes and any behaviours they 
might add. For this reason we should not encourage extensions to 
TokenStreamComponents (or if TSC extensions are required we should somehow mark 
an Analyzer as "unwrappable" to prevent lossy compositions).

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12274) Ref guide references to JTS is dated/inaccurate

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508283#comment-16508283
 ] 

ASF subversion and git services commented on SOLR-12274:


Commit 9c66cd5c32bc303d72f14e54de9af9b9cba74641 in lucene-solr's branch 
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9c66cd5 ]

SOLR-12274: Solr Ref Guide, spatial-search: Corrected obsolete JTS license info 
& location

(cherry picked from commit 4f1b83b)


> Ref guide references to JTS is dated/inaccurate
> ---
>
> Key: SOLR-12274
> URL: https://issues.apache.org/jira/browse/SOLR-12274
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>
> The spatial-search.adoc page has two problems related to JTS:
>  # It says it's LGPL licensed.  However the version Solr now requires is ASL 
> licensed.
>  # The link is to the older version of JTS (which is not supported by Solr; 
> the package changed).  It should link to the current one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9685) tag a query in JSON syntax

[Dr Oleg Savrasov (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508275#comment-16508275
 ] 

Dr Oleg Savrasov commented on SOLR-9685:


Is it supposed to work with BJQ?
I'm trying to replace

{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
query : "{!parent tag=top filters=$child.fq which=scope:product 
v=$childquery}",
filter :  "{!tag=top}category:clothes",
params:{
childquery : "scope:sku",
child.fq : "{!tag=color}color:black"
}
}'
{code}

with

{code:java}
curl http://localhost:8983/solr/collection1/query -d 'json={
query : "{!parent tag=top filters=$child.fq which=scope:product 
v=$childquery}",
filter :  "{!tag=top}category:clothes",
params:{
childquery : "scope:sku",
child.fq : "{ "#color" : "color:black" }"
}
}'
{code}

and have an exception

{code:java}
"msg":"org.apache.solr.search.SyntaxError: Cannot parse '{ ': Encountered 
\"\" at line 1, column 2.\nWas expecting one of:\n\"TO\" ...\n
 ...\n ...\n",
"code":400}}
{code}


> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12274) Ref guide references to JTS is dated/inaccurate

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508277#comment-16508277
 ] 

ASF subversion and git services commented on SOLR-12274:


Commit 4f1b83bd850343c5ddd45dbf68c4d75b9a910cf7 in lucene-solr's branch 
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4f1b83b ]

SOLR-12274: Solr Ref Guide, spatial-search: Corrected obsolete JTS license info 
& location


> Ref guide references to JTS is dated/inaccurate
> ---
>
> Key: SOLR-12274
> URL: https://issues.apache.org/jira/browse/SOLR-12274
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>
> The spatial-search.adoc page has two problems related to JTS:
>  # It says it's LGPL licensed.  However the version Solr now requires is ASL 
> licensed.
>  # The link is to the older version of JTS (which is not supported by Solr; 
> the package changed).  It should link to the current one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-12274) Ref guide references to JTS is dated/inaccurate

[David Smiley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley reassigned SOLR-12274:
---

Assignee: David Smiley

> Ref guide references to JTS is dated/inaccurate
> ---
>
> Key: SOLR-12274
> URL: https://issues.apache.org/jira/browse/SOLR-12274
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>
> The spatial-search.adoc page has two problems related to JTS:
>  # It says it's LGPL licensed.  However the version Solr now requires is ASL 
> licensed.
>  # The link is to the older version of JTS (which is not supported by Solr; 
> the package changed).  It should link to the current one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

BadApple report

[Erick Erickson]

This is much easier now than it used to be now that I just process
Hoss' reports, vastly less time-consuming than trying to go through
the e-mails..

I've attached the latest report. let me know if the text file doesn't
come through and we'll figure out how to make it available.

In brief, I'll make these changes on Thursday:

***Removing annotations for:

   AutoAddReplicasIntegrationTest.testSimple
   ChaosMonkeySafeLeaderWithPullReplicasTest.test
   ComputePlanActionTest.testSelectedCollections
   ConcurrentCreateRoutedAliasTest
   CustomCollectionTest.testCustomCollectionsAPI
   DocValuesNotIndexedTest.testGroupingDVOnly
   DocValuesNotIndexedTest.testGroupingDocAbsent
   DocValuesNotIndexedTest.testGroupingSorting
   ForceLeaderTest.testReplicasInLIRNoLeader
   HdfsDirectoryTest.testEOF
   HdfsRestartWhileUpdatingTest
   HdfsTlogReplayBufferedWhileIndexingTest
   LIRRollingUpdatesTest.testNewLeaderAndMixedReplicas
   LIRRollingUpdatesTest.testNewLeaderOldReplica
   LIRRollingUpdatesTest.testNewReplicaOldLeader
   LIRRollingUpdatesTest.testOldLeaderAndMixedReplicas
   LeaderElectionIntegrationTest.testSimpleSliceLeaderElection
   MathExpressionTest.testDistributions
   MathExpressionTest.testGammaDistribution
   MathExpressionTest.testMultiVariateNormalDistribution
   MissingSegmentRecoveryTest.testLeaderRecovery
   MoveReplicaHDFSTest.testNormalFailedMove
   MoveReplicaTest.testFailedMove
   ReplaceNodeNoTargetTest
   ReplaceNodeNoTargetTest.test
   ReplicationFactorTest
   ScheduledTriggerIntegrationTest
   ScheduledTriggerTest.testTrigger
   ShardSplitTest.test
   SharedFSAutoReplicaFailoverTest.test
   SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection
   TestCloudSchemaless.test
   TestCollapseQParserPlugin.testStringCollapse
   
TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete
   TestDynamicLoading.testDynamicLoading
   TestICUNormalizer2CharFilter.testRandomStrings
   TestImpersonationWithHadoopAuth.testForwarding
   TestLTRReRankingPipeline.testDifferentTopN
   TestMinMaxOnMultiValuedField.testDoubleFieldCache
   TestMinMaxOnMultiValuedField.testFloatFieldCache
   TestMinMaxOnMultiValuedField.testIntFieldCache
   TestMinMaxOnMultiValuedField.testLongFieldCache
   TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery
   TestPrepRecovery.testLeaderNotResponding
   TestPrepRecovery.testLeaderUnloaded
   TestPullReplica.testAddDocs
   TestReplicationHandler.doTestIndexAndConfigAliasReplication
   TestSegmentSorting.testAtomicUpdateOfSegmentSortField
   TestSegmentSorting.testSegmentTerminateEarly
   TestStressCloudBlindAtomicUpdates.test_dv_stored
   TestStressRecovery.testStressRecovery
   TestV2Request.testCloudSolrClient
   TestV2Request.testHttpSolrClient
   UIMABaseAnalyzerTest.testRandomStrings
   UIMABaseAnalyzerTest.testRandomStringsWithConfigurationParameters
   UIMATypeAwareAnalyzerTest.testRandomStrings

**Adding annotations for the following. These have failed
every week for the last 4 weeks:

BasicDistributedZkTest(suite)
BasicDistributedZkTest.test
BlockCacheTest(suite)
BlockDirectoryTest(suite)
CheckHdfsIndexTest(suite)
HdfsBasicDistributedZkTest(suite)
HdfsCollectionsAPIDistributedZkTest(suite)
HdfsNNFailoverTest(suite)
HdfsSyncSliceTest(suite)
HdfsWriteToMultipleCollectionsTest(suite)
IndexSizeTriggerTest.testMixedBounds
MaxSizeAutoCommitTest(suite)
MaxSizeAutoCommitTest.deleteTest
MaxSizeAutoCommitTest.endToEndTest
MoveReplicaHDFSTest.testFailedMove
SearchRateTriggerTest.testTrigger
TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader
TestCollectionStateWatchers.testCanWaitForNonexistantCollection
TestCollectionStateWatchers.testPredicateFailureTimesOut
TestCollectionStateWatchers.testSimpleCollectionWatch
TestCollectionStateWatchers.testStateWatcherChecksCurrentStateOnRegister
TestCollectionStateWatchers.testWaitForStateWatcherIsRetainedOnPredicateFailure
TestCollectionStateWatchers.testWatcherIsRemovedAfterTimeout
TestCollectionStateWatchers.testWatchesWorkForStateFormat1
TestDocTermOrdsUninvertLimit.testTriggerUnInvertLimit
TestGenericDistributedQueue.testDistributedQueue
TestLargeCluster.testBasic
TestLargeCluster.testNodeLost
TestRandomChains.testRandomChains
TestRandomChains.testRandomChainsWithLargeStrings
TestRecoveryHdfs(suite)
TestReplicationHandler(suite)
TestSolrCloudWithHadoopAuthPlugin(suite)
TestTriggerIntegration.testNodeAddedTrigger
TestTriggerIntegration.testTriggerThrottling
DO NOT ENABLE LIST:
TestControlledRealTimeReopenThread.testCRTReopen
TestICUTokenizerCJK

Processing file (History bit 3): HOSS-06-11.csv
Processing file (History bit 2): HOSS-06-05.csv
Processing file (History bit 1): HOSS-05-29.csv
Processing file (History bit 0): HOSS-05-21.csv


**Annotated tests/suites that didn't fail in the last 4 weeks.

  **Tests and suites removed from the next two lists because they were 
specified in 'doNotEnable' in the properties file
 

[GitHub] lucene-solr issue #362: LUCENE-7960 N-Gram filters: Add options to keep orig...

[iwesp]

Github user iwesp commented on the issue:

https://github.com/apache/lucene-solr/pull/362
  
Of course, thank you.


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #362: LUCENE-7960 N-Gram filters: Add options to ke...

[iwesp]

Github user iwesp closed the pull request at:

https://github.com/apache/lucene-solr/pull/362


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-repro - Build # 799 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/799/

[...truncated 70 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-master/2560/consoleText

[repro] Revision: b7e9fb43d0f08b68ffa6050f62351dd57495ea87

[repro] Repro line:  ant test  -Dtestcase=TestTriggerIntegration 
-Dtests.method=testNodeAddedTrigger -Dtests.seed=6DA487E1F7E5D975 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=fi 
-Dtests.timezone=Pacific/Bougainville -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=TestTriggerIntegration 
-Dtests.method=testTriggerThrottling -Dtests.seed=6DA487E1F7E5D975 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=fi 
-Dtests.timezone=Pacific/Bougainville -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testTrigger -Dtests.seed=6DA487E1F7E5D975 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=zh-HK -Dtests.timezone=Europe/Minsk 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
8095139da3598e9f76c8d960855535553b753ee9
[repro] git fetch

[...truncated 2 lines...]
[repro] git checkout b7e9fb43d0f08b68ffa6050f62351dd57495ea87

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   TestTriggerIntegration
[repro]   IndexSizeTriggerTest
[repro] ant compile-test

[...truncated 3300 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.TestTriggerIntegration|*.IndexSizeTriggerTest" 
-Dtests.showOutput=onerror  -Dtests.seed=6DA487E1F7E5D975 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=fi -Dtests.timezone=Pacific/Bougainville 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[...truncated 14644 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   4/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest
[repro]   5/5 failed: 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration

[repro] Re-testing 100% failures at the tip of master
[repro] ant clean

[...truncated 8 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   TestTriggerIntegration
[repro] ant compile-test

[...truncated 3300 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestTriggerIntegration" -Dtests.showOutput=onerror  
-Dtests.seed=6DA487E1F7E5D975 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=fi -Dtests.timezone=Pacific/Bougainville -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[...truncated 7434 lines...]
[repro] Setting last failure code to 256

[repro] Failures at the tip of master:
[repro]   4/5 failed: 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration
[repro] git checkout 8095139da3598e9f76c8d960855535553b753ee9

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 5 lines...]

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [Lucene/Solr] Patches pending for review

[David Smiley]

Although not a direct response to the issues you've raised, I just want to
say that your contributions are much appreciated and to keep up the good
work!   Thank you.

On Mon, Jun 11, 2018 at 6:00 AM Alessandro Benedetti 
wrote:

> UP
> Any feedback from the community ?
> I would be more than happy to contribute these bugfixes/improvements.
>
> If any of them is not of interest/ has been superseded by other
> developments I would be equally happy to know and  move on to other
> activities.
>
> Regards
>
> --
> Alessandro Benedetti
> Search Consultant, R Software Engineer, Director
> www.sease.io
>
> On Wed, Jun 6, 2018 at 11:30 AM, Alessandro Benedetti <
> a.benede...@sease.io> wrote:
>
>> Hi all,
>> I have a lot of Lucene/Solr patches covering different areas waiting for
>> an initial review.
>>
>> *All of them have  :*
>> *- Code change*
>> *- Related tests*
>> *- Pull Request in Github*
>> *- Patch attached*
>>
>> I am sure they are not perfect, but I believe they are ready for a review.
>> Happy to work on the contributions and to fix/improve anything necessary.
>>
>> Some of them are bug fixes, some of them are improvements.
>> It's a couple of months I don't get any progress in the review process
>> for some of them, so I hope listing them here would help the community :
>>
>> *Bugs*
>> *[LUCENE-6687] * More
>> Like This Bug
>> *[LUCENE-8343]*  
>> BlendedInfixSuggester
>> Bug
>> *[LUCENE-8329]*  Size
>> Estimator Bug
>> *[SOLR-12304]*  More
>> Like This Bug Solr side
>>
>> *Improvements*
>> *[LUCENE-8326 ] *More
>> Like This Params Refactor
>> *[LUCENE-8347]  
>> *BlendedInfixSuggester
>> Improvement
>> *[SOLR-12238]*  Synonym
>> Query Style Boost By Payload
>> *[SOLR-12243]*  Edismax
>> Bug ( Elizabeth Haubert, me)
>>
>> Regards
>> --
>> Alessandro Benedetti
>> Search Consultant, R Software Engineer, Director
>> www.sease.io
>>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/395#discussion_r194446507
  
--- Diff: 
solr/solrj/src/java/org/apache/solr/common/util/JsonRecordReader.java ---
@@ -442,19 +442,18 @@ void walkObject() throws IOException {
   }
 }
 
-private void addChildDoc2ParentDoc(Map record, 
Map values, String path) {
-  String trimmedPath = trimPath(path);
+private void addChildDoc2ParentDoc(Map record, 
Map values, String key) {
--- End diff --

much better; thanks


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/395#discussion_r19902
  
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java 
---
@@ -668,7 +682,40 @@ private boolean isChildDoc(SolrInputDocument 
extendedMap) {
   return 
extendedMap.containsKey(req.getSchema().getUniqueKeyField().getName());
 }
 
-private SolrInputDocument generateExtendedValueMap(int ev) throws 
IOException {
+private boolean entryIsChildDoc(Object val) {
+  if(val instanceof List) {
+List listVal = (List) val;
+if (listVal.size() == 0) return false;
+return  listVal.get(0) instanceof Map;
+  }
+  return val instanceof Map;
+}
+
+private void safeAddValue(SolrInputDocument doc, String fieldName, 
Object value) {
--- End diff --

Okay I see.  Interesting -- there are clearly pros/cons to having 
SolrInputDocument implement core JDK abstractions.  It makes working with it 
easier, though now some things like what you see here happens automatically 
when we don't want it to.

There is no perfect solution here but I'd rather see 
SolrInputField.addValue do an instanceof check when it sees that `v` implements 
Iterable to guard against iterating the child doc.  This is much 
smaller/simpler than your safeAddValue, and it's something that won't be tied 
to Json or any other input format.  Even someone who wants to use SolrJ and 
thinks that they can just call set/addValue would be surprised it doesn't work 
unless we make the change at SolrInputField.
Also admittedly, this is a gotcha to the path of putting nested child docs 
in values, but not a big deal.


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/395#discussion_r194445760
  
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java 
---
@@ -249,14 +251,27 @@ public void handle(Map record, String 
path) {
 private SolrInputDocument buildDoc(Map m) {
   SolrInputDocument result = new SolrInputDocument();
   for (Map.Entry e : m.entrySet()) {
-if (e.getKey() == null) {// special case. JsonRecordReader emits 
child docs with null key
+if (entryIsChildDoc(e.getValue())) {// special case. 
JsonRecordReader emits child docs with null key
   if (e.getValue() instanceof List) {
 List value = (List) e.getValue();
 for (Object o : value) {
-  if (o instanceof Map) result.addChildDocument(buildDoc((Map) 
o));
+  if (o instanceof Map) {
+if (anonChildDocFlag) {
+  result.addChildDocument(buildDoc((Map) o));
+} else {
+  if(!result.containsKey(e.getKey())) {
+result.setField(e.getKey(), new ArrayList<>(1));
--- End diff --

ok so you are trying to retain the semantic information that the input was 
an array (potentially multi-valued) even if the particular input doc only had 
one value.  Maybe say more or that, hinting at why we even care.  (why do we 
care)?  For regular field values, we don't at this level -- the schema holds 
multiValue info so it's dealth with later.  Again I'm liking my suggestion of 
putting a virtual child doc field in the schema as it addresses the desire to 
know this semantic info, plus I think it may add some consistency (avoids 
special case you're doing here)


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Lucene/Solr 7.4

[Adrien Grand]

No worries Uwe, we'll wait. Enjoy Buzzwords!

Le lun. 11 juin 2018 à 17:08, Uwe Schindler  a écrit :

> I still have this new security issue and to fix it finally everywhere, it
> requires API changes. So please wait, I am working but buzzwords is so
> interesting! 勞
>
> Uwe
>
>
> Am June 11, 2018 2:45:54 PM UTC schrieb David Smiley <
> david.w.smi...@gmail.com>:
>>
>> It'd be nice to get in this bug
>> https://issues.apache.org/jira/browse/LUCENE-8344 but is pending a
>> review.
>>
>> On Tue, Jun 5, 2018 at 4:24 AM Adrien Grand  wrote:
>>
>>> Hi all,
>>>
>>> We released 7.3 two months ago on April 4th and we accumulated quite a
>>> number of features, enhancements and fixes that are not released yet, so
>>> I'd like to start working on releasing Lucene/Solr 7.4.0.
>>>
>>> I propose to create the 7.4 branch later this week and build the first
>>> RC early next week if that works for everyone. Please let me know if that
>>> are bug fixes that we think should make it to 7.4 and might not be ready by
>>> then.
>>>
>>> Adrien
>>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> 
> https://www.thetaphi.de
>

[jira] [Updated] (SOLR-11277) Add auto hard commit setting based on tlog size

[Anshum Gupta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-11277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anshum Gupta updated SOLR-11277:

Attachment: SOLR-11277.02.patch

> Add auto hard commit setting based on tlog size
> ---
>
> Key: SOLR-11277
> URL: https://issues.apache.org/jira/browse/SOLR-11277
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Rupa Shankar
>Assignee: Anshum Gupta
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11277.01.patch, SOLR-11277.02.patch, 
> SOLR-11277.patch, SOLR-11277.patch, SOLR-11277.patch, SOLR-11277.patch, 
> SOLR-11277.patch, SOLR-11277.patch, SOLR-11277.patch, 
> max_size_auto_commit.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When indexing documents of variable sizes and at variable schedules, it can 
> be hard to estimate the optimal auto hard commit maxDocs or maxTime settings. 
> We’ve had some occurrences of really huge tlogs, resulting in serious issues, 
> so in an attempt to avoid this, it would be great to have a “maxSize” setting 
> based on the tlog size on disk. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-12441) Add deeply nested documents URP

[David Smiley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley reassigned SOLR-12441:
---

Assignee: David Smiley

> Add deeply nested documents URP
> ---
>
> Key: SOLR-12441
> URL: https://issues.apache.org/jira/browse/SOLR-12441
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Assignee: David Smiley
>Priority: Major
>
> As discussed in 
> [SOLR-12298|https://issues.apache.org/jira/browse/SOLR-12298], there ought to 
> be an URP to add metadata fields to childDocuments in order to allow a 
> transformer to rebuild the original document hierarchy.
> {quote}I propose we add the following fields:
>  # __nestParent__
>  # _nestLevel_
>  # __nestPath__
> __nestParent__: This field wild will store the document's parent docId, to be 
> used for building the whole hierarchy, using a new document transformer, as 
> suggested by Jan on the mailing list.
> _nestLevel_: This field will store the level of the specified field in the 
> document, using an int value. This field can be used for the parentFilter, 
> eliminating the need to provide a parentFilter, which will be set by default 
> as "_level_:queriedFieldLevel".
> _nestLevel_: This field will contain the full path, separated by a specific 
> reserved char e.g., '.'
>  for example: "first.second.third".
>  This will enable users to search for a specific path, or provide a regular 
> expression to search for fields sharing the same name in different levels of 
> the document, filtering using the level key if needed.
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-12298) Index Full nested document Hierarchy For Queries (umbrella issue)

[David Smiley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley reassigned SOLR-12298:
---

Assignee: David Smiley

> Index Full nested document Hierarchy For Queries (umbrella issue)
> -
>
> Key: SOLR-12298
> URL: https://issues.apache.org/jira/browse/SOLR-12298
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Assignee: David Smiley
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Solr ought to have the ability to index deeply nested objects, while storing 
> the original document hierarchy.
>  Currently the client has to index the child document's full path and level 
> to manually reconstruct the original document structure, since the children 
> are flattened and returned in the reserved "__childDocuments__" key.
> Ideally you could index a nested document, having Solr transparently add the 
> required fields while providing a document transformer to rebuild the 
> original document's hierarchy.
>  
> This issue is an umbrella issue for the particular tasks that will make it 
> all happen – either subtasks or issue linking.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr issue #362: LUCENE-7960 N-Gram filters: Add options to keep orig...

[dsmiley]

Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/362
  
can be closed now I believe


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Lucene/Solr 7.4

[Uwe Schindler]

I still have this new security issue and to fix it finally everywhere, it 
requires API changes. So please wait, I am working but buzzwords is so 
interesting! 勞

Uwe

Am June 11, 2018 2:45:54 PM UTC schrieb David Smiley :
>It'd be nice to get in this bug
>https://issues.apache.org/jira/browse/LUCENE-8344 but is pending a
>review.
>
>On Tue, Jun 5, 2018 at 4:24 AM Adrien Grand  wrote:
>
>> Hi all,
>>
>> We released 7.3 two months ago on April 4th and we accumulated quite
>a
>> number of features, enhancements and fixes that are not released yet,
>so
>> I'd like to start working on releasing Lucene/Solr 7.4.0.
>>
>> I propose to create the 7.4 branch later this week and build the
>first RC
>> early next week if that works for everyone. Please let me know if
>that are
>> bug fixes that we think should make it to 7.4 and might not be ready
>by
>> then.
>>
>> Adrien
>>
>-- 
>Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>http://www.solrenterprisesearchserver.com

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

[GitHub] lucene-solr issue #379: add ë, ö and ï to norm()

[dsmiley]

Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/379
  
Can you please file a Lucene JIRA issue, and then edit this PR to include 
the JIRA reference, so they are cross-linked?


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #384: LUCENE-8332 move CompletionTokenStream to Con...

[dsmiley]

Github user dsmiley closed the pull request at:

https://github.com/apache/lucene-solr/pull/384


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-12361) Add solr child documents as values inside SolrInputField

[David Smiley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved SOLR-12361.
-
   Resolution: Fixed
 Assignee: David Smiley
Fix Version/s: 7.5

Note: We accidentally took this issue in a different direction than the 
original title/description called for instead of doing that under another issue 
which already existed SOLR-12383.  So I deleted that other issue, and edited 
this issue to reflect the path taken.

Thanks for contributing Moshe!

> Add solr child documents as values inside SolrInputField
> 
>
> Key: SOLR-12361
> URL: https://issues.apache.org/jira/browse/SOLR-12361
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.5
>
> Attachments: SOLR-12361.patch, SOLR-12361.patch, SOLR-12361.patch, 
> SOLR-12361.patch
>
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> During the discussion on SOLR-12298, there was a proposal to remove 
> _childDocuments, and incorporate the relationship between the parent and its 
> child documents, by holding the child documents inside a solrInputField, 
> inside of the document.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-12361) Add solr child documents as values inside SolrInputField

[David Smiley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated SOLR-12361:

Description: During the discussion on SOLR-12298, there was a proposal to 
remove _childDocuments, and incorporate the relationship between the parent and 
its child documents, by holding the child documents inside a solrInputField, 
inside of the document.  (was: During the discussion on SOLR-12298, there was a 
proposal to change _childDocuments in SolrDocumentBase to a Map, to incorporate 
the relationship between the parent and its child documents.)
Summary: Add solr child documents as values inside SolrInputField  
(was: Change _childDocuments to Map)

> Add solr child documents as values inside SolrInputField
> 
>
> Key: SOLR-12361
> URL: https://issues.apache.org/jira/browse/SOLR-12361
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
> Attachments: SOLR-12361.patch, SOLR-12361.patch, SOLR-12361.patch, 
> SOLR-12361.patch
>
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> During the discussion on SOLR-12298, there was a proposal to remove 
> _childDocuments, and incorporate the relationship between the parent and its 
> child documents, by holding the child documents inside a solrInputField, 
> inside of the document.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org