Re: [VOTE] Release Lucene/Solr 7.2.0 RC1

[Shalin Shekhar Mangar]

+1

SUCCESS! [1:12:05.185679]

On Fri, Dec 15, 2017 at 1:52 PM, Adrien Grand  wrote:
> Please vote for release candidate 1 for Lucene/Solr 7.2.0
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.2.0-RC1-revbca54cad5a9f6a80800944fd5bd585b68acde8c8/
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.2.0-RC1-revbca54cad5a9f6a80800944fd5bd585b68acde8c8/
>
> Here's my +1



-- 
Regards,
Shalin Shekhar Mangar.

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

Re: Welcome Ahmet Arslan as Lucene/Solr committer

[Shalin Shekhar Mangar]

Congratulations and welcome Ahmet!

On Tue, Dec 19, 2017 at 3:48 AM, Ahmet Arslan  wrote:
> Hi,
>
> Thanks to all for the warm welcome.
> It is such an honor to be invited by the PMC.
>
>
> I am an Assistant Professor in the Department of Computer Engineering at
> Anadolu University, Turkey.
> My current research interests include selective information retrieval and
> index term weighting.
>
> I started using Lucene during my master studies for academic purposes.
> Later on, I have worked in a number of commercial search projects using
> Apache Lucene/Solr.
>
> I am very proud of being part of this team!
>
> Thanks,
> Ahmet
>
> On Monday, December 18, 2017, 4:42:34 PM GMT+3, Steve Rowe
>  wrote:
>
>
> Congrats and welcome Ahmet!
>
> --
> Steve
> www.lucidworks.com
>
>> On Dec 17, 2017, at 5:15 AM, Adrien Grand  wrote:
>>
>> Hi all,
>>
>> Please join me in welcoming Ahmet Arslan as the latest Lucene/Solr
>> committer.
>> Ahmet, it's tradition for you to introduce yourself with a brief bio.
>>
>> Congratulations and Welcome!
>>
>> Adrien
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



-- 
Regards,
Shalin Shekhar Mangar.

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

[jira] [Commented] (SOLR-11648) Create a web UI to display and execute suggestions

[Apoorv Bhawsar (JIRA)]

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

Apoorv Bhawsar commented on SOLR-11648:
---

[~noble.paul] have added the suggested changes to my PR

> Create a web UI to display and execute suggestions
> --
>
> Key: SOLR-11648
> URL: https://issues.apache.org/jira/browse/SOLR-11648
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Noble Paul
> Attachments: screen1.png, screen2.png, screen3.png, screen4.png, 
> sidebar.jpg, suggestions_table.jpg, suggestions_table.jpg
>
>
> Steps to show suggestions
> {code}
> bin/solr start -e cloud
> #give the following inputs for prompts
> This interactive session will help you launch a SolrCloud cluster on your 
> local workstation.
> To begin, how many Solr nodes would you like to run in your local cluster? 
> (specify 1-4 nodes) [2]: 
> 4
> Please provide a name for your new collection: [gettingstarted] 
> mycoll
> How many shards would you like to split mycoll into? [2]
> 4
> How many replicas per shard would you like to create? [2] 
> 2
> #run the following command so that there are violating replicas
> curl http://localhost:8983/api/cluster/autoscaling -H 
> 'Content-type:application/json' -d '{
> "set-cluster-policy": [
>   {"replica": "0", "shard": "#EACH", "port": 7574}
>   ]
> }'
> #hit the suggestions end point at the url
> http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}
> add an entry to the sidebar as follows
> !sidebar.jpg!
> use the output of the suggestions API to map to the table data
> !suggestions_table.jpg!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-7.2-Linux (64bit/jdk-10-ea+32) - Build # 84 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Linux/84/
Java: 64bit/jdk-10-ea+32 -XX:+UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudSolrClientTest

Error Message:
Error from server at https://127.0.0.1:33555/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:33555/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([DB2DF2D8228BAF27]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.setupCluster(CloudSolrClientTest.java:103)
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$6.evaluate(RandomizedRunner.java:874)
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.cloud.TestAuthenticationFramework.testBasics

Error Message:
Error from server at 
http://127.0.0.1:36479/solr/testcollection_shard1_replica_n2: Expected mime 
type application/octet-stream but got text/html.Error 
404HTTP ERROR: 404 Problem accessing 
/solr/testcollection_shard1_replica_n2/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n2/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.20.v20170531 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:36479/solr/testcollection_shard1_replica_n2: 
Expected mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: /solr/testcollection_shard1_replica_n2/update
http://eclipse.org/jetty;>Powered by 

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_144) - Build # 1013 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1013/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication

Error Message:
expected:<494> but was:<0>

Stack Trace:
java.lang.AssertionError: expected:<494> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([66D6B10640D5E0B0:91A55F5E863D4F56]: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.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1313)
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)




Build Log:
[...truncated 12616 lines...]
   [junit4] Suite: 

[jira] [Updated] (SOLR-11777) eq() ValueSource (aka Function Query) ought to support strings

[David Smiley (JIRA)]

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

David Smiley updated SOLR-11777:

Description: 
The {{eq()}} (boolean equals) ValueSource (aka Function Query) ought to support 
strings; it currently only supports numeric fields.  

The work-around is to do something like {{exists(query(\{!v=field:value\}))}}. 
That will be slow unless the field is indexed.  For DocValues-only it could be 
efficient but is dependent on LUCENE-8103.

  was:
The {{eq()}} ValueSource (aka Function Query) ought to support strings; it 
currently only supports numeric fields.  

The work-around is to do something like {{exists(query({!v=field:value}))}}. 
That will be slow unless the field is indexed.  For DocValues-only it could be 
efficient but is dependent on LUCENE-8103.


> eq() ValueSource (aka Function Query) ought to support strings
> --
>
> Key: SOLR-11777
> URL: https://issues.apache.org/jira/browse/SOLR-11777
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>
> The {{eq()}} (boolean equals) ValueSource (aka Function Query) ought to 
> support strings; it currently only supports numeric fields.  
> The work-around is to do something like 
> {{exists(query(\{!v=field:value\}))}}. That will be slow unless the field is 
> indexed.  For DocValues-only it could be efficient but is dependent on 
> LUCENE-8103.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11777) eq() ValueSource (aka Function Query) ought to support strings

[David Smiley (JIRA)]

David Smiley created SOLR-11777:
---

 Summary: eq() ValueSource (aka Function Query) ought to support 
strings
 Key: SOLR-11777
 URL: https://issues.apache.org/jira/browse/SOLR-11777
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: David Smiley


The {{eq()}} ValueSource (aka Function Query) ought to support strings; it 
currently only supports numeric fields.  

The work-around is to do something like {{exists(query({!v=field:value}))}}. 
That will be slow unless the field is indexed.  For DocValues-only it could be 
efficient but is dependent on LUCENE-8103.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk1.8.0) - Build # 348 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/348/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

10 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI

Error Message:
Could not find collection : implicitcoll

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : implicitcoll
at 
__randomizedtesting.SeedInfo.seed([A3BFFE30E3B27591:C95E705BDE28C3E9]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:247)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:68)
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:  
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter

Error Message:
Collection not found: withShardField

Stack Trace:

[jira] [Created] (SOLR-11776) HttpSolrClient should handle SocketException:broken pipe

[Cao Manh Dat (JIRA)]

Cao Manh Dat created SOLR-11776:
---

 Summary: HttpSolrClient should handle SocketException:broken pipe
 Key: SOLR-11776
 URL: https://issues.apache.org/jira/browse/SOLR-11776
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Cao Manh Dat


There is a case when leader sends an update to replica but met 
{{SocketException: broken pipe}} ( HttpPartitionTest ), the leader treat this 
exception as others SocketException and put replica into LIR mode. But this 
exception means an existing connection between leader and replica is closed on 
one side. I think we should handle this exception in a different way ( ex: 
reconnect ) so leader won't blindly put replica into LIR even when the 
connection between leader and replica is healthy.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.1) - Build # 21106 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21106/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseG1GC

7 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.sim.TestExecutePlanAction

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([E1F120F164B118E9]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestCloudSchemaless

Error Message:
66 threads leaked from SUITE scope at 
org.apache.solr.schema.TestCloudSchemaless: 1) Thread[id=9502, 
name=qtp237771039-9502, state=RUNNABLE, group=TGRP-TestCloudSchemaless] 
at java.base@9.0.1/sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
 at 
java.base@9.0.1/sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:265)   
  at 
java.base@9.0.1/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:92)
 at 
java.base@9.0.1/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)   
  at java.base@9.0.1/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)   
  at java.base@9.0.1/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)  
   at 
app//org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:243)
 at 
app//org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:191)
 at 
app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:249)
 at 
app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
 at 
app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
 at java.base@9.0.1/java.lang.Thread.run(Thread.java:844)2) 
Thread[id=9508, name=qtp237771039-9508, state=RUNNABLE, 
group=TGRP-TestCloudSchemaless] at 
java.base@9.0.1/sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) 
at 
java.base@9.0.1/sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:265)   
  at 
java.base@9.0.1/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:92)
 at 
java.base@9.0.1/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)   
  at java.base@9.0.1/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)   
  at java.base@9.0.1/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)  
   at 
app//org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:243)
 at 
app//org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:191)
 at 
app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:249)
 at 
app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
 at 
app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
 at java.base@9.0.1/java.lang.Thread.run(Thread.java:844)3) 
Thread[id=9453, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestCloudSchemaless] at 
java.base@9.0.1/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@9.0.1/java.lang.Thread.run(Thread.java:844)4) 
Thread[id=9515, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestCloudSchemaless] at 
java.base@9.0.1/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@9.0.1/java.lang.Thread.run(Thread.java:844)5) 
Thread[id=9546, name=zkCallback-4682-thread-3, state=TIMED_WAITING, 
group=TGRP-TestCloudSchemaless] at 
java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9.0.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9.0.1/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9.0.1/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9.0.1/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1091)
 at 

[JENKINS] Lucene-Solr-Tests-7.x - Build # 286 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/286/

9 tests failed.
FAILED:  org.apache.solr.TestDistributedSearch.test

Error Message:
Expected to find shardAddress in the up shard info: 
{error=org.apache.solr.client.solrj.SolrServerException: Time allowed to handle 
this request exceeded,trace=org.apache.solr.client.solrj.SolrServerException: 
Time allowed to handle this request exceeded  at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:460)
  at 
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
  at 
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748) ,time=2}

Stack Trace:
java.lang.AssertionError: Expected to find shardAddress in the up shard info: 
{error=org.apache.solr.client.solrj.SolrServerException: Time allowed to handle 
this request exceeded,trace=org.apache.solr.client.solrj.SolrServerException: 
Time allowed to handle this request exceeded
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:460)
at 
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
at 
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
,time=2}
at 
__randomizedtesting.SeedInfo.seed([E7C582025295575F:6F91BDD8FC693AA7]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.TestDistributedSearch.comparePartialResponses(TestDistributedSearch.java:1191)
at 
org.apache.solr.TestDistributedSearch.queryPartialResults(TestDistributedSearch.java:1132)
at 
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:992)
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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1019)
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 

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 4333 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4333/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication

Error Message:
Index 0 out-of-bounds for length 0

Stack Trace:
java.lang.IndexOutOfBoundsException: Index 0 out-of-bounds for length 0
at 
__randomizedtesting.SeedInfo.seed([FB0E478E3EBACD4:1BF8BF2DC0EC11CA]:0)
at 
java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
at 
java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
at 
java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
at java.base/java.util.Objects.checkIndex(Objects.java:372)
at java.base/java.util.ArrayList.get(ArrayList.java:439)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication(TestReplicationHandler.java:561)
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 
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

[jira] [Comment Edited] (SOLR-11771) Overseer can never process some last messages

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat edited comment on SOLR-11771 at 12/19/17 1:49 AM:
---

[~dsmiley] Only since SOLR-11443 get committed so only 7.2 get affected. But 
this case is quite rare to happen in real world. 


was (Author: caomanhdat):
[~dsmiley] Only since SOLR-11443 get committed so only 7.2 get affected.

> Overseer can never process some last messages
> -
>
> Key: SOLR-11771
> URL: https://issues.apache.org/jira/browse/SOLR-11771
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>
> I met this problem when some tests get failed because timeout on creating a 
> new collection. The case here is
> 1. Overseer call DQ.peekElements with LONG.MAX_VALUE timeout.
> 2. DQ fetch children from ZK but it is empty.
> 3. At the same time with 2, a set LEADER message is enqueued, 
> {{changed.signalAll()}} already called.
> 4. The call {{changed.awaitNanos(waitNanos)}} is never end because no new 
> messages get enqueued after this point.
> The fix here is trivial, the call peekElements should have a timeout of 2 
> seconds, that will be appropriate in most cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11771) Overseer can never process some last messages

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-11771:
-

[~dsmiley] Only since SOLR-11443 get committed so only 7.2 get affected.

> Overseer can never process some last messages
> -
>
> Key: SOLR-11771
> URL: https://issues.apache.org/jira/browse/SOLR-11771
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>
> I met this problem when some tests get failed because timeout on creating a 
> new collection. The case here is
> 1. Overseer call DQ.peekElements with LONG.MAX_VALUE timeout.
> 2. DQ fetch children from ZK but it is empty.
> 3. At the same time with 2, a set LEADER message is enqueued, 
> {{changed.signalAll()}} already called.
> 4. The call {{changed.awaitNanos(waitNanos)}} is never end because no new 
> messages get enqueued after this point.
> The fix here is trivial, the call peekElements should have a timeout of 2 
> seconds, that will be appropriate in most cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-3218) Range faceting support for CurrencyField

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-3218:
--

 Assignee: Hoss Man
Fix Version/s: (was: 6.0)
   (was: 4.9)

> Range faceting support for CurrencyField
> 
>
> Key: SOLR-3218
> URL: https://issues.apache.org/jira/browse/SOLR-3218
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Hoss Man
> Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch, SOLR-3218.patch, 
> SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch, 
> SOLR-3218.patch, SOLR-3218.patch
>
>
> Spinoff from SOLR-2202. Need to add range faceting capabilities for 
> CurrencyField



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3218) Range faceting support for CurrencyField

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-3218:
---
Attachment: SOLR-3218.patch

I'm going to try to see this through -- but at this point I don't think it's a 
good idea to add {{facet.range}} support w/o also adding {{json.facet}} 
{{type:range}} support as well -- so i'm working on that at the same time.

Here's what i've got so far...

* massaged the latest path to apply to master
** along the way i droped the StatsValuesFactory changes since:
*** they were causing a lot of headaches
*** they weren't directly related to the objective
*** they didn't have any distrib tests and i was 99% certain at a glance that 
the distrib stats code wasn't going to work as is since it seemed to expect 
{{CurrencyValue}} objects from the shards
* beefed up the existing tests a bit and added some cloud based test equivilents
* adapted the minimal changes to the {{json.facet}} {{FacetRange}} class...
** added a new {{CurrencyCalc}} impl
** added a new {{buildRangeLabel}} method to the {{Calc}} API since the 
existing logic (to always use the "low" value as the {{Range.label}} ) isn't 
viable for {{CurrencyCalc}} because the {{CurrencyValue}} objects aren't 
suitable for being included directly in the response writer.
** added some very basic variants on the (new) tests for the {{json.facet}} 
code.

There are still more tests I want to write related to the {{json.facet}} code 
-- partly because of how {{type:range}} can be used in broader ways in the 
{{json.facet}} then the equivilent {{facet.range}} code (see nocommits in the 
test) ... but more notably because of the following points of confusion I have 
about the code in the existing patch that I'm hoping Yonik can provide some 
guidance on...


# The {{Calc}} API includes 2 "bits" related methods whose purpose I don't 
understand and at a glance I don't see used anywhere.  I'm not sure if they are 
dead code, but with these impls in {{CurrencyCalc}} that do nothing but throw 
Exceptions I'm not getting any errors -- so if they aren't dead code then they 
only get used via some code path I haven't yet identified/tested...{code}
@Override
public Comparable bitsToValue(long bits) {
  throw new RuntimeException("nocommit: dead code??"); // return bits;
}

@Override
public long bitsToSortableBits(long bits) {
  throw new RuntimeException("nocommit: dead code??"); // return bits;
}
{code}
# even though the {{FacetRange.Range}} class already has an existing {{Object 
label}} variable that's used in most places as the {{"val"}} when generating 
the {{"buckets"}} SimpleOrderedMap for the response, there is one code path in 
the {{refineBucket}} method that goes out of it's way to use 
{{FacetRange.Range.low}} instead of {{FacetRange.Range.label}} with a 
perplexing comment...{code}
bucket.add("val", range.low); // use "low" instead of bucketVal because it will 
be the right type (we may have been passed back long instead of int for example)
{code}
#* It's not clear to me what the meaning of this comment is and how/why using 
{{range.low}} is better then using {{range.label}} here since in every 
(pre-patch) code path I see {{range.low == range.label}}
#** When would the {{label}} ever have the wrong type?!?!?
#* As things stand right now, the {{CurencyValue}} objects that get put into 
the {{range.low}} variable (when {{CurrencyCalc}} is used) should never be 
included directly in the response -- and yet nothing in my currency cloud test 
seems to trigger this code path (yet)
#* Given that the "buckets" of a range facet should always be deterministic, 
I'm not actually clear on when/how/why a FacetRange bucket would ever need to 
be "refined" ?


[~yo...@apache.org] can you help shed some light on when/how these methods are 
used to save me some time in figuring out how to write additional test cases 
explicitly targeting these code paths?


> Range faceting support for CurrencyField
> 
>
> Key: SOLR-3218
> URL: https://issues.apache.org/jira/browse/SOLR-3218
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
> Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch, SOLR-3218.patch, 
> SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch, 
> SOLR-3218.patch, SOLR-3218.patch
>
>
> Spinoff from SOLR-2202. Need to add range faceting capabilities for 
> CurrencyField



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk1.8.0_144) - Build # 349 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/349/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseSerialGC

6 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.lucene.store.TestMultiMMap

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_A2470EF42927C3FE-001\testSeekSliceZero-018:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_A2470EF42927C3FE-001\testSeekSliceZero-018
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_A2470EF42927C3FE-001\testSeekSliceZero-018:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_A2470EF42927C3FE-001\testSeekSliceZero-018

at __randomizedtesting.SeedInfo.seed([A2470EF42927C3FE]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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:  org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue

Error Message:
action wasn't interrupted

Stack Trace:
java.lang.AssertionError: action wasn't interrupted
at 
__randomizedtesting.SeedInfo.seed([9504AD70F8EB96A5:5CB1EFDEF18C5050]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue(TriggerIntegrationTest.java:707)
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 

Re: Welcome Ahmet Arslan as Lucene/Solr committer

[Tomás Fernández Löbbe]

Congratulations and welcome Ahmet!

On Mon, Dec 18, 2017 at 2:18 PM, Ahmet Arslan 
wrote:

> Hi,
>
> Thanks to all for the warm welcome.
> It is such an honor to be invited by the PMC.
>
>
> I am an Assistant Professor in the Department of Computer Engineering at
> Anadolu University, Turkey.
> My current research interests include selective information retrieval and
> index term weighting.
>
> I started using Lucene during my master studies for academic purposes.
> Later on, I have worked in a number of commercial search projects using
> Apache Lucene/Solr.
>
> I am very proud of being part of this team!
>
> Thanks,
> Ahmet
>
> On Monday, December 18, 2017, 4:42:34 PM GMT+3, Steve Rowe <
> sar...@gmail.com> wrote:
>
>
> Congrats and welcome Ahmet!
>
> --
> Steve
> www.lucidworks.com
>
> > On Dec 17, 2017, at 5:15 AM, Adrien Grand  wrote:
> >
> > Hi all,
> >
> > Please join me in welcoming Ahmet Arslan as the latest Lucene/Solr
> committer.
> > Ahmet, it's tradition for you to introduce yourself with a brief bio.
> >
> > Congratulations and Welcome!
> >
> > Adrien
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-2899:


bq. My Jenkins found a reproducing seed on master for a 
TestOpenNLPPOSFilterFactory.testPos() failure

I committed a fix for this and all other Jenkins failures I could find for this 
test suite: {{OpenNLPPosFilter.reset()}} wasn't working properly, resulting in 
state being inappropriately carried over from previous invocations.

> Add OpenNLP Analysis capabilities as a module
> -
>
> Key: LUCENE-2899
> URL: https://issues.apache.org/jira/browse/LUCENE-2899
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Grant Ingersoll
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: LUCENE-2899-6.1.0.patch, LUCENE-2899-RJN.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, OpenNLPFilter.java, 
> OpenNLPTokenizer.java
>
>
> Now that OpenNLP is an ASF project and has a nice license, it would be nice 
> to have a submodule (under analysis) that exposed capabilities for it. Drew 
> Farris, Tom Morton and I have code that does:
> * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
> would have to change slightly to buffer tokens)
> * NamedEntity recognition as a TokenFilter
> We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
> either payloads (PartOfSpeechAttribute?) on a token or at the same position.
> I'd propose it go under:
> modules/analysis/opennlp



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-2899.

Resolution: Fixed

> Add OpenNLP Analysis capabilities as a module
> -
>
> Key: LUCENE-2899
> URL: https://issues.apache.org/jira/browse/LUCENE-2899
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Grant Ingersoll
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: LUCENE-2899-6.1.0.patch, LUCENE-2899-RJN.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, OpenNLPFilter.java, 
> OpenNLPTokenizer.java
>
>
> Now that OpenNLP is an ASF project and has a nice license, it would be nice 
> to have a submodule (under analysis) that exposed capabilities for it. Drew 
> Farris, Tom Morton and I have code that does:
> * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
> would have to change slightly to buffer tokens)
> * NamedEntity recognition as a TokenFilter
> We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
> either payloads (PartOfSpeechAttribute?) on a token or at the same position.
> I'd propose it go under:
> modules/analysis/opennlp



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-7.2-Linux (64bit/jdk-10-ea+32) - Build # 83 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Linux/83/
Java: 64bit/jdk-10-ea+32 -XX:+UseCompressedOops -XX:+UseSerialGC

6 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:46179/qs_/m

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:46179/qs_/m
at 
__randomizedtesting.SeedInfo.seed([483BAEA4B7592474:C06F917E19A5498C]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1668)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1607)
at 
org.apache.solr.cloud.ShardSplitTest.splitByRouteKeyTest(ShardSplitTest.java:751)
at org.apache.solr.cloud.ShardSplitTest.test(ShardSplitTest.java:102)
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 

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-2899: OpenNLPPOSFilter: fix reset() to fully reset


> Add OpenNLP Analysis capabilities as a module
> -
>
> Key: LUCENE-2899
> URL: https://issues.apache.org/jira/browse/LUCENE-2899
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Grant Ingersoll
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: LUCENE-2899-6.1.0.patch, LUCENE-2899-RJN.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, OpenNLPFilter.java, 
> OpenNLPTokenizer.java
>
>
> Now that OpenNLP is an ASF project and has a nice license, it would be nice 
> to have a submodule (under analysis) that exposed capabilities for it. Drew 
> Farris, Tom Morton and I have code that does:
> * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
> would have to change slightly to buffer tokens)
> * NamedEntity recognition as a TokenFilter
> We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
> either payloads (PartOfSpeechAttribute?) on a token or at the same position.
> I'd propose it go under:
> modules/analysis/opennlp



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

[ASF subversion and git services (JIRA)]

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

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

Commit 42239ea51d9b1c34f20d273ab06821e22b421e54 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=42239ea ]

LUCENE-2899: OpenNLPPOSFilter: fix reset() to fully reset


> Add OpenNLP Analysis capabilities as a module
> -
>
> Key: LUCENE-2899
> URL: https://issues.apache.org/jira/browse/LUCENE-2899
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Grant Ingersoll
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: LUCENE-2899-6.1.0.patch, LUCENE-2899-RJN.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, OpenNLPFilter.java, 
> OpenNLPTokenizer.java
>
>
> Now that OpenNLP is an ASF project and has a nice license, it would be nice 
> to have a submodule (under analysis) that exposed capabilities for it. Drew 
> Farris, Tom Morton and I have code that does:
> * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
> would have to change slightly to buffer tokens)
> * NamedEntity recognition as a TokenFilter
> We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
> either payloads (PartOfSpeechAttribute?) on a token or at the same position.
> I'd propose it go under:
> modules/analysis/opennlp



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-2899: tests: remove unused constants


> Add OpenNLP Analysis capabilities as a module
> -
>
> Key: LUCENE-2899
> URL: https://issues.apache.org/jira/browse/LUCENE-2899
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Grant Ingersoll
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: LUCENE-2899-6.1.0.patch, LUCENE-2899-RJN.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, OpenNLPFilter.java, 
> OpenNLPTokenizer.java
>
>
> Now that OpenNLP is an ASF project and has a nice license, it would be nice 
> to have a submodule (under analysis) that exposed capabilities for it. Drew 
> Farris, Tom Morton and I have code that does:
> * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
> would have to change slightly to buffer tokens)
> * NamedEntity recognition as a TokenFilter
> We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
> either payloads (PartOfSpeechAttribute?) on a token or at the same position.
> I'd propose it go under:
> modules/analysis/opennlp



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

[ASF subversion and git services (JIRA)]

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

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

Commit 40ed963b362281c67b37efaca51a3dafca00762a 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=40ed963 ]

LUCENE-2899: tests: remove unused constants


> Add OpenNLP Analysis capabilities as a module
> -
>
> Key: LUCENE-2899
> URL: https://issues.apache.org/jira/browse/LUCENE-2899
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Grant Ingersoll
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: LUCENE-2899-6.1.0.patch, LUCENE-2899-RJN.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, OpenNLPFilter.java, 
> OpenNLPTokenizer.java
>
>
> Now that OpenNLP is an ASF project and has a nice license, it would be nice 
> to have a submodule (under analysis) that exposed capabilities for it. Drew 
> Farris, Tom Morton and I have code that does:
> * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
> would have to change slightly to buffer tokens)
> * NamedEntity recognition as a TokenFilter
> We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
> either payloads (PartOfSpeechAttribute?) on a token or at the same position.
> I'd propose it go under:
> modules/analysis/opennlp



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs

[Peter Rusko (JIRA)]

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

Peter Rusko commented on SOLR-8389:
---

This patch above is just providing a way for properties to be assigned to 
collections. It is pretty generic at the moment, the value can be anything, so 
you can assign any JSON value you want, it won't require a target collection to 
be set. The interpretation of the value comes down to the code reading the 
value.

It looks like it's missing two things. None of those seem to be important for 
the first iteration to me. One is the ability to assign a value at the 
collection creation time and the other is a support of a property value 
validator, which could check that the assigned value has certain fields for 
instance.

Is it okay if we merge this patch as it is so far, provided someone can review 
it? Then I, or someone else with better ideas can add the two missing pieces 
above later, if they are needed.

> Convert CDCR peer cluster and other configurations into collection properties 
> modifiable via APIs
> -
>
> Key: SOLR-8389
> URL: https://issues.apache.org/jira/browse/SOLR-8389
> Project: Solr
>  Issue Type: Improvement
>  Components: CDCR, SolrCloud
>Reporter: Shalin Shekhar Mangar
> Attachments: SOLR-8389.patch
>
>
> CDCR configuration is kept inside solrconfig.xml which makes it difficult to 
> add or change peer cluster configuration.
> I propose to move all CDCR config to collection level properties in cluster 
> state so that they can be modified using the existing modify collection API.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11769) Sorting performance degrades when useFilterForSortedQuery is enabled and there is no filter query specified

[Betim Deva (JIRA)]

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

Betim Deva commented on SOLR-11769:
---

Thanks [~dsmiley].

As suggested, I've changed lines 1400-1401 to following and verified that the 
performance improves while the result set remains the same. 

{code:java}
List filterList = cmd.getFilterList();
if (filterList != null && !filterList.isEmpty()) {
  DocSet bigFilt = getDocSet(cmd.filterList);
  if (bigFilt != null) {
out.docSet = out.docSet.intersection(bigFilt);
  }
}
{code}

> Sorting performance degrades when useFilterForSortedQuery is enabled and 
> there is no filter query specified
> ---
>
> Key: SOLR-11769
> URL: https://issues.apache.org/jira/browse/SOLR-11769
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 4.10.4
> Environment: OS: macOS Sierra (version 10.12.4)
> Memory: 16GB
> CPU: 2.9 GHz Intel Core i7
> Java Version: 1.8
>Reporter: Betim Deva
>Assignee: David Smiley
>  Labels: performance
>
> The performance of sorting degrades significantly when the 
> {{useFilterForSortedQuery}} is enabled, and there's no filter query specified.
> *Steps to Reproduce:*
> 1. Set {{useFilterForSortedQuery=true}} in {{solrconfig.xml}}
> 2. Run a  query to match and return a single document. Also add sorting
> - Example {{/select?q=foo:123=bar+desc}}
> Having a large index (> 10 million documents), this yields to a slow response 
> (a few hundreds of milliseconds on average) even when the resulting set 
> consists of a single document.
> *Observation 1:*
> - Disabling {{useFilterForSortedQuery}} improves the performance to < 1ms
> *Observation 2:*
> - Removing the {{sort}} improves the performance to < 1ms
> *Observation 3:*
> - Keeping the {{sort}}, and adding any filter query (such as {{fq=\*:\*}}) 
> improves the performance to < 1 ms.
> After profiling 
> [SolrIndexSearcher.java|https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blob;f=solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java;h=9ee5199bdf7511c70f2cc616c123292c97d36b5b;hb=HEAD#l1400]
>  found that the bottleneck is on 
> {{DocSet bigFilt = getDocSet(cmd.getFilterList());}} 
> when {{cmd.getFilterList())}} is passed in as {{null}}. This is making 
> {{getDocSet()}} function collect document ids every single time it is called 
> without any caching.
> {code:java}
> 1394 if (useFilterCache) {
> 1395   // now actually use the filter cache.
> 1396   // for large filters that match few documents, this may be
> 1397   // slower than simply re-executing the query.
> 1398   if (out.docSet == null) {
> 1399 out.docSet = getDocSet(cmd.getQuery(), cmd.getFilter());
> 1400 DocSet bigFilt = getDocSet(cmd.getFilterList());
> 1401 if (bigFilt != null) out.docSet = 
> out.docSet.intersection(bigFilt);
> 1402   }
> 1403   // todo: there could be a sortDocSet that could take a list of
> 1404   // the filters instead of anding them first...
> 1405   // perhaps there should be a multi-docset-iterator
> 1406   sortDocSet(qr, cmd);
> 1407 }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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/jdk1.8.0_144) - Build # 1012 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1012/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  org.apache.solr.cloud.CleanupOldIndexTest.test

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([43CAB3C5B0A06BB3:CB9E8C1F1E5C064B]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1261)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:449)
at 
org.apache.solr.cloud.CleanupOldIndexTest.test(CleanupOldIndexTest.java:114)
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:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at 
http://127.0.0.1:37291/solr/awhollynewcollection_0_shard1_replica_n1: 
ClusterState says we are the leader 

Re: Welcome Ahmet Arslan as Lucene/Solr committer

[Ahmet Arslan]

 Hi,
Thanks to all for the warm welcome.
It is such an honor to be invited by the PMC.

I am an Assistant Professor in the Department of Computer Engineering at 
Anadolu University, Turkey.
My current research interests include selective information retrieval and index 
term weighting.
I started using Lucene during my master studies for academic purposes.Later on, 
I have worked in a number of commercial search projects using Apache 
Lucene/Solr.
I am very proud of being part of this team!
Thanks,
Ahmet
On Monday, December 18, 2017, 4:42:34 PM GMT+3, Steve Rowe 
 wrote:  
 
 Congrats and welcome Ahmet!

--
Steve
www.lucidworks.com

> On Dec 17, 2017, at 5:15 AM, Adrien Grand  wrote:
> 
> Hi all,
> 
> Please join me in welcoming Ahmet Arslan as the latest Lucene/Solr committer.
> Ahmet, it's tradition for you to introduce yourself with a brief bio.
> 
> Congratulations and Welcome!
> 
> Adrien


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

[jira] [Commented] (LUCENE-8103) QueryValueSource should use TwoPhaseIterator

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8103:
--

Ditto for org.apache.lucene.search.DoubleValuesSource.WeightDoubleValuesSource  
 (the newer replacement of QueryValueSource) and the code looks simpler there.

> QueryValueSource should use TwoPhaseIterator
> 
>
> Key: LUCENE-8103
> URL: https://issues.apache.org/jira/browse/LUCENE-8103
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/other
>Reporter: David Smiley
>Priority: Minor
>
> QueryValueSource (in "queries" module) is a ValueSource representation of a 
> Query; the score is the value.  It ought to try to use a TwoPhaseIterator 
> from the query if it can be offered. This will prevent possibly expensive 
> advancing beyond documents that we aren't interested in.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.2-Windows (64bit/jdk-9.0.1) - Build # 22 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Windows/22/
Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.lucene.index.TestFixBrokenOffsets

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestFixBrokenOffsets_127D26B372A08998-001\fixedbrokenoffsets-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestFixBrokenOffsets_127D26B372A08998-001\fixedbrokenoffsets-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestFixBrokenOffsets_127D26B372A08998-001\fixedbrokenoffsets-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestFixBrokenOffsets_127D26B372A08998-001\fixedbrokenoffsets-001

at __randomizedtesting.SeedInfo.seed([127D26B372A08998]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
org.apache.lucene.index.TestDemoParallelLeafReader.testRandomMultipleSchemaGens

Error Message:
this writer hit an unrecoverable error; cannot commit

Stack Trace:
java.lang.IllegalStateException: this writer hit an unrecoverable error; cannot 
commit
at 
org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4742)
at 
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:3326)
at 
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3458)
at org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1276)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1319)
at 
org.apache.lucene.index.TestDemoParallelLeafReader$ReindexingReader.close(TestDemoParallelLeafReader.java:252)
at 
org.apache.lucene.index.TestDemoParallelLeafReader.testRandomMultipleSchemaGens(TestDemoParallelLeafReader.java:1023)
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.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 

Re: VOTE: Release Apache Solr Reference Guide for Solr 7.2

[Alexandre Rafalovitch]

Actually,

I think it would have to be one of the new semi-interactive manuals
both O'Reilly and Mannings are building platforms for. Or a boxset of
end-to-end Solr examples for interesting datasets. I think a lack of
public pre-populated Solr play instances is a limiting factors.

Regards,
   Alex.


On 18 December 2017 at 16:07, David Smiley  wrote:
> On Mon, Dec 18, 2017 at 2:49 PM Alexandre Rafalovitch 
> wrote:
>>
>> 1100+ pages.. This may well be why we don't have any new Solr
>> books. Hard to see the angle to compete with the documentation. :-)
>
>
> LOL right.  If I were ever forced to write another Solr book (and it would
> be at gunpoint and with my wife leaving me) I think the book should be way
> more of a tutorial (or multiple tutorials) + guide and/or "cookbook" style.
> It's no longer realistic to try to document everything.
>
> ~ David
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com

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

Re: VOTE: Release Apache Solr Reference Guide for Solr 7.2

[David Smiley]

On Mon, Dec 18, 2017 at 2:49 PM Alexandre Rafalovitch 
wrote:

> 1100+ pages.. This may well be why we don't have any new Solr
> books. Hard to see the angle to compete with the documentation. :-)
>

LOL right.  If I were ever forced to write another Solr book (and it would
be at gunpoint and with my wife leaving me) I think the book should be way
more of a tutorial (or multiple tutorials) + guide and/or "cookbook"
style.  It's no longer realistic to try to document everything.

~ David
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Commented] (SOLR-11750) Collection aliases should be easier manage

[Scott Stults (JIRA)]

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

Scott Stults commented on SOLR-11750:
-

Exactly right. This is something that I think should be added to the Angular 
CollectionsController, or somewhere thereabout. 

> Collection aliases should be easier manage
> --
>
> Key: SOLR-11750
> URL: https://issues.apache.org/jira/browse/SOLR-11750
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.6, 7.0.1, 7.1
>Reporter: Scott Stults
>Priority: Minor
>
> Currently the only way to determine which aliases apply to a collection is to 
> go into the tree view of the cloud page and look at the contents of the 
> aliases node. It would be handy to have this information alongside the other 
> collection details. Also, the delete alias drop-down shows all of the aliases 
> for all collections, not just the one that applies to the currently viewed 
> collection.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8104) Grouping module should no longer depend on Queries module (ValueSource)

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8104:
--

CC [~romseygeek] and [~martijn.v.groningen]
Note I have no intent to work on this anytime soon but wanted to at least file 
an issue.

BTW [~mikemccand] the facet module depends on the Queries module too but it 
appears it is only to make javadoc references to some classes it no longer 
actually uses ;-)

> Grouping module should no longer depend on Queries module (ValueSource)
> ---
>
> Key: LUCENE-8104
> URL: https://issues.apache.org/jira/browse/LUCENE-8104
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: David Smiley
>
> The Grouping module depends on the Queries module in GroupingSearch / 
> ValueSourceGroupSelector to use the ValueSource framework.  It should instead 
> use the newer DoubleValueSource or LongValueSource framework in Core.  As I 
> write this, this appears to be the last part of Lucene to refer to the 
> ValueSource framework, and I think we should then remove it -- for another 
> issue of course.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (LUCENE-8104) Grouping module should no longer depend on Queries module (ValueSource)

[David Smiley (JIRA)]

David Smiley created LUCENE-8104:


 Summary: Grouping module should no longer depend on Queries module 
(ValueSource)
 Key: LUCENE-8104
 URL: https://issues.apache.org/jira/browse/LUCENE-8104
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/grouping
Reporter: David Smiley


The Grouping module depends on the Queries module in GroupingSearch / 
ValueSourceGroupSelector to use the ValueSource framework.  It should instead 
use the newer DoubleValueSource or LongValueSource framework in Core.  As I 
write this, this appears to be the last part of Lucene to refer to the 
ValueSource framework, and I think we should then remove it -- for another 
issue of course.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: VOTE: Release Apache Solr Reference Guide for Solr 7.2

[Joel Bernstein]

+1

Joel Bernstein
http://joelsolr.blogspot.com/

On Mon, Dec 18, 2017 at 2:48 PM, Alexandre Rafalovitch 
wrote:

> 1100+ pages.. This may well be why we don't have any new Solr
> books. Hard to see the angle to compete with the documentation. :-)
>
> +1
>
> Minor points not intended to stop the process:
> There is a funny page breakdown at the end of the document for "Solr
> Glossary" and "Errata".
> Also Solr Clients page is beyond being out of date (2011! Wiki is more
> up-to-date), not sure if there is a JIRA to fix that.
>
> Regards,
>Alex.
>
> On 18 December 2017 at 14:34, Cassandra Targett 
> wrote:
> > Please vote for the release of the Apache Solr Reference Guide for 7.2.
> >
> > The PDF artifacts can be downloaded from:
> > https://dist.apache.org/repos/dist/dev/lucene/solr/ref-
> guide/apache-solr-ref-guide-7.2-RC1/
> >
> > $ cat apache-solr-ref-guide-7.2.pdf.sha1
> > e07c87e774923af4735e7cdb9f420bb2ad5df860  apache-solr-ref-guide-7.2.pdf
> >
> > The HTML version is also available online:
> > http://lucene.apache.org/solr/guide/7_2/
> >
> > Here's my +1.
> >
> > Thanks,
> > Cassandra
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-11750) Collection aliases should be easier manage

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11750:
-

bq. Currently the only way to determine which aliases apply to a collection is 
to go into the tree view of the cloud page and look at the contents of the 
aliases node.

I believe this is false.  I'm looking at the code for ClusterStatus and it has 
an "aliases" key that maps collection names to the alias(es) that it is a 
member of.
Nevertheless I think your point is centrally about the UI (Component/s:Admin 
UI) not wether or not Solr gives this information in some API call (which it 
does).

> Collection aliases should be easier manage
> --
>
> Key: SOLR-11750
> URL: https://issues.apache.org/jira/browse/SOLR-11750
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.6, 7.0.1, 7.1
>Reporter: Scott Stults
>Priority: Minor
>
> Currently the only way to determine which aliases apply to a collection is to 
> go into the tree view of the cloud page and look at the contents of the 
> aliases node. It would be handy to have this information alongside the other 
> collection details. Also, the delete alias drop-down shows all of the aliases 
> for all collections, not just the one that applies to the currently viewed 
> collection.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_144) - Build # 7061 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7061/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseParallelGC

8 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestBackwardsCompatibility

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_E0154F654AF646BE-001\3.0.0-nocfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_E0154F654AF646BE-001\3.0.0-nocfs-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_E0154F654AF646BE-001\3.0.0-nocfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_E0154F654AF646BE-001\3.0.0-nocfs-001

at __randomizedtesting.SeedInfo.seed([E0154F654AF646BE]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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:  
org.apache.lucene.queryparser.xml.TestCorePlusExtensionsParser.testBoostingQueryXML

Error Message:
No QueryObjectBuilder defined for node BoostingQuery

Stack Trace:
org.apache.lucene.queryparser.xml.ParserException: No QueryObjectBuilder 
defined for node BoostingQuery
at 
__randomizedtesting.SeedInfo.seed([470DFFE88EB93E6D:B7E67B46214C5A73]:0)
at 
org.apache.lucene.queryparser.xml.QueryBuilderFactory.getQuery(QueryBuilderFactory.java:35)
at 
org.apache.lucene.queryparser.xml.CoreParser.getQuery(CoreParser.java:190)
at 
org.apache.lucene.queryparser.xml.CoreParser.parse(CoreParser.java:125)
at 
org.apache.lucene.queryparser.xml.TestCoreParser.implParse(TestCoreParser.java:240)
at 
org.apache.lucene.queryparser.xml.TestCoreParser.parse(TestCoreParser.java:227)
at 
org.apache.lucene.queryparser.xml.TestCorePlusQueriesParser.testBoostingQueryXML(TestCorePlusQueriesParser.java:35)
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 
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 

Re: VOTE: Release Apache Solr Reference Guide for Solr 7.2

[Alexandre Rafalovitch]

1100+ pages.. This may well be why we don't have any new Solr
books. Hard to see the angle to compete with the documentation. :-)

+1

Minor points not intended to stop the process:
There is a funny page breakdown at the end of the document for "Solr
Glossary" and "Errata".
Also Solr Clients page is beyond being out of date (2011! Wiki is more
up-to-date), not sure if there is a JIRA to fix that.

Regards,
   Alex.

On 18 December 2017 at 14:34, Cassandra Targett  wrote:
> Please vote for the release of the Apache Solr Reference Guide for 7.2.
>
> The PDF artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.2-RC1/
>
> $ cat apache-solr-ref-guide-7.2.pdf.sha1
> e07c87e774923af4735e7cdb9f420bb2ad5df860  apache-solr-ref-guide-7.2.pdf
>
> The HTML version is also available online:
> http://lucene.apache.org/solr/guide/7_2/
>
> Here's my +1.
>
> Thanks,
> Cassandra

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

[jira] [Commented] (SOLR-11681) Add ttest and pairedTtest Stream Evaluators

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11681:


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

SOLR-11681: Add ttest and pairedTtest Stream Evaluators


> Add ttest and pairedTtest Stream Evaluators 
> 
>
> Key: SOLR-11681
> URL: https://issues.apache.org/jira/browse/SOLR-11681
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11681.patch
>
>
> This ticket adds the ttest and pairedTtest Stream Evaluator.
> https://en.wikipedia.org/wiki/Student%27s_t-test
> ttest implementation is provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11681) Add ttest and pairedTtest Stream Evaluators

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11681:


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

SOLR-11681: Add ttest and pairedTtest Stream Evaluators


> Add ttest and pairedTtest Stream Evaluators 
> 
>
> Key: SOLR-11681
> URL: https://issues.apache.org/jira/browse/SOLR-11681
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11681.patch
>
>
> This ticket adds the ttest and pairedTtest Stream Evaluator.
> https://en.wikipedia.org/wiki/Student%27s_t-test
> ttest implementation is provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 908 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 28229 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 491 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.07 sec (3.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 30.0 MB in 0.07 sec (448.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 72.2 MB in 0.12 sec (586.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 82.7 MB in 0.24 sec (341.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6239 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6239 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] 
   [smoker] command "export JAVA_HOME="/home/jenkins/tools/java/latest1.8" 
PATH="/home/jenkins/tools/java/latest1.8/bin:$PATH" 
JAVACMD="/home/jenkins/tools/java/latest1.8/bin/java"; ant clean test 
-Dtests.slow=false" failed:
   [smoker] Buildfile: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/build.xml
   [smoker] 
   [smoker] clean:
   [smoker][delete] Deleting directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/build
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] [loadresource] Do not set property disallowed.ivy.jars.list as its 
length is 0.
   [smoker] 
   [smoker] -ivy-fail-disallowed-ivy-version:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: Apache Ivy 2.4.0 - 20141213170938 :: 
http://ant.apache.org/ivy/ ::
   [smoker] [ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/top-level-ivy-settings.xml
   [smoker] 
   [smoker] -clover.load:
   [smoker] 
   [smoker] resolve-groovy:
   [smoker] [ivy:cachepath] :: resolving dependencies :: 
org.codehaus.groovy#groovy-all-caller;working
   [smoker] [ivy:cachepath] confs: [default]
   [smoker] [ivy:cachepath] found org.codehaus.groovy#groovy-all;2.4.12 in 
public
   [smoker] [ivy:cachepath] :: resolution report :: resolve 1175ms :: artifacts 
dl 3ms
   [smoker] 
-
   [smoker] |  |modules||   
artifacts   |
   [smoker] |   conf   | number| search|dwnlded|evicted|| 
number|dwnlded|
   [smoker] 
-
   [smoker] |  default |   1   |   0   |   0   |   0   ||   1   |   
0   |
   [smoker] 
-
   [smoker] 
   [smoker] -init-totals:
   [smoker] 
   [smoker] test-core:
   [smoker] 
   [smoker] -clover.disable:
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] [loadresource] Do not set property disallowed.ivy.jars.list as its 
length is 0.
   [smoker] 
   [smoker] -ivy-fail-disallowed-ivy-version:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/top-level-ivy-settings.xml
   [smoker] 
   [smoker] -clover.load:
   [smoker] 
   [smoker] 

VOTE: Release Apache Solr Reference Guide for Solr 7.2

[Cassandra Targett]

Please vote for the release of the Apache Solr Reference Guide for 7.2.

The PDF artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.2-RC1/

$ cat apache-solr-ref-guide-7.2.pdf.sha1
e07c87e774923af4735e7cdb9f420bb2ad5df860  apache-solr-ref-guide-7.2.pdf

The HTML version is also available online:
http://lucene.apache.org/solr/guide/7_2/

Here's my +1.

Thanks,
Cassandra

[JENKINS] Lucene-Solr-NightlyTests-7.2 - Build # 4 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.2/4/

7 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:39882/a_/fk/forceleader_test_collection

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: 
http://127.0.0.1:39882/a_/fk/forceleader_test_collection
at 
__randomizedtesting.SeedInfo.seed([1A5D9E458891A048:FCCAAA85B1135929]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.realTimeGetDocId(HttpPartitionTest.java:617)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:602)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:557)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:144)
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 
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   

[jira] [Updated] (SOLR-11681) Add ttest and pairedTtest Stream Evaluators

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11681:
--
Attachment: SOLR-11681.patch

> Add ttest and pairedTtest Stream Evaluators 
> 
>
> Key: SOLR-11681
> URL: https://issues.apache.org/jira/browse/SOLR-11681
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11681.patch
>
>
> This ticket adds the ttest and pairedTtest Stream Evaluator.
> https://en.wikipedia.org/wiki/Student%27s_t-test
> ttest implementation is provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11681) Add ttest and pairedTtest Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11681:
--
Summary: Add ttest and pairedTtest Stream Evaluator   (was: Add ttest 
Stream Evaluator )

> Add ttest and pairedTtest Stream Evaluator 
> ---
>
> Key: SOLR-11681
> URL: https://issues.apache.org/jira/browse/SOLR-11681
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
>
> This ticket adds the ttest Stream Evaluator.
> https://en.wikipedia.org/wiki/Student%27s_t-test



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11681) Add ttest and pairedTtest Stream Evaluators

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11681:
--
Summary: Add ttest and pairedTtest Stream Evaluators   (was: Add ttest and 
pairedTtest Stream Evaluator )

> Add ttest and pairedTtest Stream Evaluators 
> 
>
> Key: SOLR-11681
> URL: https://issues.apache.org/jira/browse/SOLR-11681
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
>
> This ticket adds the ttest and pairedTtest Stream Evaluator.
> https://en.wikipedia.org/wiki/Student%27s_t-test
> ttest implementation is provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11681) Add ttest and pairedTtest Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11681:
--
Description: 
This ticket adds the ttest and pairedTtest Stream Evaluator.

https://en.wikipedia.org/wiki/Student%27s_t-test

ttest implementation is provided by Apache Commons Math


  was:
This ticket adds the ttest Stream Evaluator.

https://en.wikipedia.org/wiki/Student%27s_t-test


> Add ttest and pairedTtest Stream Evaluator 
> ---
>
> Key: SOLR-11681
> URL: https://issues.apache.org/jira/browse/SOLR-11681
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
>
> This ticket adds the ttest and pairedTtest Stream Evaluator.
> https://en.wikipedia.org/wiki/Student%27s_t-test
> ttest implementation is provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8389:
--

Haven't looked at all, but a comment on the user's list 

WDYT about making the target collection optional? If omitted it would be the 
same as the source collection



> Convert CDCR peer cluster and other configurations into collection properties 
> modifiable via APIs
> -
>
> Key: SOLR-8389
> URL: https://issues.apache.org/jira/browse/SOLR-8389
> Project: Solr
>  Issue Type: Improvement
>  Components: CDCR, SolrCloud
>Reporter: Shalin Shekhar Mangar
> Attachments: SOLR-8389.patch
>
>
> CDCR configuration is kept inside solrconfig.xml which makes it difficult to 
> add or change peer cluster configuration.
> I propose to move all CDCR config to collection level properties in cluster 
> state so that they can be modified using the existing modify collection API.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11701) Upgrade to Tika 1.17 when available

[Tim Allison (JIRA)]

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

Tim Allison commented on SOLR-11701:


Sounds good.  _Thank you_!

On the git conflict, y, that was caused by the recent addition of opennlp.  
I've updated the PR, but there are, of course, already new conflicts! :)  Let 
me know if I can do anything to help with that. 

On the 401, I'm sure why that was happening...I'll take a look.

On the unused imports, ugh.  Thank you.

> Upgrade to Tika 1.17 when available
> ---
>
> Key: SOLR-11701
> URL: https://issues.apache.org/jira/browse/SOLR-11701
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tim Allison
>Assignee: Erick Erickson
> Attachments: SOLR-11701.patch
>
>
> Kicking off release process for Tika 1.17 in the next few days.  Please let 
> us know if you have any requests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11771) Overseer can never process some last messages

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11771:
-

Does this appear to be a long-standing problem or only with a particular recent 
version?

> Overseer can never process some last messages
> -
>
> Key: SOLR-11771
> URL: https://issues.apache.org/jira/browse/SOLR-11771
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>
> I met this problem when some tests get failed because timeout on creating a 
> new collection. The case here is
> 1. Overseer call DQ.peekElements with LONG.MAX_VALUE timeout.
> 2. DQ fetch children from ZK but it is empty.
> 3. At the same time with 2, a set LEADER message is enqueued, 
> {{changed.signalAll()}} already called.
> 4. The call {{changed.awaitNanos(waitNanos)}} is never end because no new 
> messages get enqueued after this point.
> The fix here is trivial, the call peekElements should have a timeout of 2 
> seconds, that will be appropriate in most cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Heads up for a test error writing too much to stdout/stderr.

[Erick Erickson]

See SOLR-11701 for the full background, but the upshot is that when we
upgrade slf4j we will get more extensive stack traces in some
situations. This can cause the framework to fail tests, there's an
example at that JIRA, the message is:

"The test or suite printed 9268 bytes to stdout and stderr, even
though the limit was set to 8192 bytes. "

This can be fixed with an annotation like:
@TestRuleLimitSysouts.Limit(bytes=12000)

FYI in case this pops out with @Nightly/@Weekly tests

Erick

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

[jira] [Commented] (SOLR-11764) preanalyzed field with highlight option throws exception

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11764:
-

LOL I need another coffee; thanks for the link Steve!  Oh yeah that was with 
[~ab], not you.  Maybe PreAnalyzedField should be deprecated?  I don't think we 
need it; I think the URP version only has advantages over it but not the other 
way.  Sadly the ref guide page you refer to makes no mention of the URP version.

> preanalyzed field with highlight option throws exception
> 
>
> Key: SOLR-11764
> URL: https://issues.apache.org/jira/browse/SOLR-11764
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 6.4
>Reporter: Selvam Raman
>
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
> Error from server at http://localhost:8983/solr/Metadata2: 
> org.apache.solr.client.solrj.SolrServerException:
> No live SolrServers available to handle this 
> request:[/solr/Metadata2_shard1_replica1,
>   solr/Metadata2_shard2_replica2, 
>   solr/Metadata2_shard1_replica2]
> When i look at the solr logs i find the below exception
> Caused by: java.io.IOException: Invalid JSON type java.lang.String, expected 
> Map
>   at 
> org.apache.solr.schema.JsonPreAnalyzedParser.parse(JsonPreAnalyzedParser.java:86)
>   at 
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedTokenizer.decodeInput(PreAnalyzedField.java:345)
>   at 
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedTokenizer.access$000(PreAnalyzedField.java:280)
>   at 
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer$1.setReader(PreAnalyzedField.java:375)
>   at org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:202)
>   at 
> org.apache.lucene.search.uhighlight.AnalysisOffsetStrategy.tokenStream(AnalysisOffsetStrategy.java:58)
>   at 
> org.apache.lucene.search.uhighlight.MemoryIndexOffsetStrategy.getOffsetsEnums(MemoryIndexOffsetStrategy.java:106)
>   ... 37 more
>  I am setting up lot of fields (fq, score, highlight,etc) then put it into 
> solrquery.
> "we are using preanalyzed field and that causing the problem. 
> The actual problem is preanalyzed with highlight option. if i disable 
> highlight option it works fine."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11701) Upgrade to Tika 1.17 when available

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11701:
---

Tim:

I don't see a problem here then, I was mostly worried that this was an 
inexplicable problem that would pop out other places. We'll upgrade slf4j 
sometime anyway, so it seems to me that just adding the annotation is an OK fix.

At most, some of the @Slow or @Nightly or @Weekly tests will error out and need 
a similar annotation, but we're in the beginning of a new release cycle so 
there's time for those to flush out.

Any kind of blanket "don't report the full stack trace" seems like a bad idea 
since that's often so necessary to analysis.

If you find anything out that's germane, let me know otherwise I'll just 
annotate and commit (probably this evening).

Thanks for tracking this down!

> Upgrade to Tika 1.17 when available
> ---
>
> Key: SOLR-11701
> URL: https://issues.apache.org/jira/browse/SOLR-11701
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tim Allison
>Assignee: Erick Erickson
> Attachments: SOLR-11701.patch
>
>
> Kicking off release process for Tika 1.17 in the next few days.  Please let 
> us know if you have any requests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11764) preanalyzed field with highlight option throws exception

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11764:
---

bq. I'm reminded discussing this pre-analysis with you Steve Rowe on some issue 
long ago and suggesting that this whole feature shouldn't be a field type; it 
ought to be an URP.

It already is: 
[https://lucene.apache.org/solr/7_1_0//solr-core/org/apache/solr/update/processor/PreAnalyzedUpdateProcessorFactory.html]



> preanalyzed field with highlight option throws exception
> 
>
> Key: SOLR-11764
> URL: https://issues.apache.org/jira/browse/SOLR-11764
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 6.4
>Reporter: Selvam Raman
>
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
> Error from server at http://localhost:8983/solr/Metadata2: 
> org.apache.solr.client.solrj.SolrServerException:
> No live SolrServers available to handle this 
> request:[/solr/Metadata2_shard1_replica1,
>   solr/Metadata2_shard2_replica2, 
>   solr/Metadata2_shard1_replica2]
> When i look at the solr logs i find the below exception
> Caused by: java.io.IOException: Invalid JSON type java.lang.String, expected 
> Map
>   at 
> org.apache.solr.schema.JsonPreAnalyzedParser.parse(JsonPreAnalyzedParser.java:86)
>   at 
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedTokenizer.decodeInput(PreAnalyzedField.java:345)
>   at 
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedTokenizer.access$000(PreAnalyzedField.java:280)
>   at 
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer$1.setReader(PreAnalyzedField.java:375)
>   at org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:202)
>   at 
> org.apache.lucene.search.uhighlight.AnalysisOffsetStrategy.tokenStream(AnalysisOffsetStrategy.java:58)
>   at 
> org.apache.lucene.search.uhighlight.MemoryIndexOffsetStrategy.getOffsetsEnums(MemoryIndexOffsetStrategy.java:106)
>   ... 37 more
>  I am setting up lot of fields (fq, score, highlight,etc) then put it into 
> solrquery.
> "we are using preanalyzed field and that causing the problem. 
> The actual problem is preanalyzed with highlight option. if i disable 
> highlight option it works fine."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11746) numeric fields need better error handling for prefix/wildcard syntax -- consider uniform support for "foo:* == foo:[* TO *]"

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-11746:
-

bq. IMO it should count as a bug that numeric_field:* doesn't work.

+1

I would go so far as to say thta once we "fix" this bug, we should also update 
QueryEqualityTest to assert that for all indexed/docValues/trie/points 
permutations of "primative" types (numbers, dates, string, boolean) 
{{field:\*}} should produce an identical Query object to {{field:\[\* TO \*\]}} 
-- so that whatever "optimizations" may exist (or be added in the future) in 
one query parser code path, also happen for the other syntax as well.

> numeric fields need better error handling for prefix/wildcard syntax -- 
> consider uniform support for "foo:* == foo:[* TO *]"
> 
>
> Key: SOLR-11746
> URL: https://issues.apache.org/jira/browse/SOLR-11746
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> On the solr-user mailing list, Torsten Krah pointed out that with Trie 
> numeric fields, query syntax such as {{foo_d:\*}} has been functionality 
> equivilent to {{foo_d:\[\* TO \*]}} and asked why this was not also supported 
> for Point based numeric fields.
> The fact that this type of syntax works (for {{indexed="true"}} Trie fields) 
> appears to have been an (untested, undocumented) fluke of Trie fields given 
> that they use indexed terms for the (encoded) numeric terms and inherit the 
> default implementation of {{FieldType.getPrefixQuery}} which produces a 
> prefix query against the {{""}} (empty string) term.  
> (Note that this syntax has aparently _*never*_ worked for Trie fields with 
> {{indexed="false" docValues="true"}} )
> In general, we should assess the behavior users attempt a prefix/wildcard 
> syntax query against numeric fields, as currently the behavior is largely 
> non-sensical:  prefix/wildcard syntax frequently match no docs w/o any sort 
> of error, and the aformentioned {{numeric_field:*}} behaves inconsistently 
> between points/trie fields and between indexed/docValued trie fields.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11701) Upgrade to Tika 1.17 when available

[Tim Allison (JIRA)]

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

Tim Allison commented on SOLR-11701:


Back to keyboard.  You're right in all of the above. When we bump slf4j from 
1.7.7 to 1.7.24, its behavior changes to print out the full stacktrace instead 
of just the message.

In org.slf4j.helpers.MessageFormatter in 1.7.7, the exception is counted as one 
of the members of {{argArray}}, and because of the following snippet, the 
{{throwableCandidate}} is nulled out in the returned {{FormattingTuple}}
{noformat}
if (L < argArray.length - 1) {
return new FormattingTuple(sbuf.toString(), argArray, 
throwableCandidate);
} else {
return new FormattingTuple(sbuf.toString(), argArray, 
(Throwable)null);
}
{noformat}

In 1.7.24, there's an added bit of logic before we get to that location that 
removes the exception from {{argArray}} so that it can't get swept into the 
message.
{noformat}
Object[] args = argArray;
if (throwableCandidate != null) {
args = trimmedCopy(argArray);
}
{noformat}

I have in the back of my mind that there was a reason we upgraded slf4j in 
Tika.  I'll look through our git history to see when/why and if we need to do 
it for the Solr integration.


> Upgrade to Tika 1.17 when available
> ---
>
> Key: SOLR-11701
> URL: https://issues.apache.org/jira/browse/SOLR-11701
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tim Allison
>Assignee: Erick Erickson
> Attachments: SOLR-11701.patch
>
>
> Kicking off release process for Tika 1.17 in the next few days.  Please let 
> us know if you have any requests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11764) preanalyzed field with highlight option throws exception

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11764:
-

Oh I see then it should work.

I'm reminded discussing this pre-analysis with you [~steve_rowe] on some issue 
long ago and suggesting that this whole feature shouldn't be a field type; it 
ought to be an URP.  URPs can return Lucene Field instances, which skip 
FieldType processing.  Then the highlighters wouldn't care as there would be no 
custom/special field type.  Any way, I'm sure whatever the bug is here, we can 
figure it out.

> preanalyzed field with highlight option throws exception
> 
>
> Key: SOLR-11764
> URL: https://issues.apache.org/jira/browse/SOLR-11764
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 6.4
>Reporter: Selvam Raman
>
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
> Error from server at http://localhost:8983/solr/Metadata2: 
> org.apache.solr.client.solrj.SolrServerException:
> No live SolrServers available to handle this 
> request:[/solr/Metadata2_shard1_replica1,
>   solr/Metadata2_shard2_replica2, 
>   solr/Metadata2_shard1_replica2]
> When i look at the solr logs i find the below exception
> Caused by: java.io.IOException: Invalid JSON type java.lang.String, expected 
> Map
>   at 
> org.apache.solr.schema.JsonPreAnalyzedParser.parse(JsonPreAnalyzedParser.java:86)
>   at 
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedTokenizer.decodeInput(PreAnalyzedField.java:345)
>   at 
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedTokenizer.access$000(PreAnalyzedField.java:280)
>   at 
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer$1.setReader(PreAnalyzedField.java:375)
>   at org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:202)
>   at 
> org.apache.lucene.search.uhighlight.AnalysisOffsetStrategy.tokenStream(AnalysisOffsetStrategy.java:58)
>   at 
> org.apache.lucene.search.uhighlight.MemoryIndexOffsetStrategy.getOffsetsEnums(MemoryIndexOffsetStrategy.java:106)
>   ... 37 more
>  I am setting up lot of fields (fq, score, highlight,etc) then put it into 
> solrquery.
> "we are using preanalyzed field and that causing the problem. 
> The actual problem is preanalyzed with highlight option. if i disable 
> highlight option it works fine."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8099) Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8099: Fix xmlqueryparser tests


> Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery
> --
>
> Key: LUCENE-8099
> URL: https://issues.apache.org/jira/browse/LUCENE-8099
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 7.3
>
> Attachments: LUCENE-8099.patch, LUCENE-8099.patch
>
>
> After LUCENE-7998, these three queries can all be replaced by a 
> FunctionScoreQuery.  Using lucene-expressions makes them much easier to use 
> as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11775) json.facet can use inconsistent Long/Integer for "count" depending on shard count

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-11775:
-

Trivial to reproduce...

* "Non-Distributed" request (either standalone, or cloud w/one 
shard)...{noformat}
bin/solr -e techproducts
# (or bin/solr -e cloud, choose 1 shard w/ sample_techproducts_configs, and 
index the docs manually)
...
$ curl http://localhost:8983/solr/techproducts/select -d 
'q=*:*=xml=0={ foo:{type:range, field:price, start:0, 
end:1000, gap:100, other:all } }'




  0
  23
  
*:*
{ foo:{type:range, field:price, start:0, end:1000, 
gap:100, other:all } }
0
xml
  




  32
  

  
0.0
7
  
  
100.0
2
  
  
200.0
1
  
  ...


  0


  1


  15

  


{noformat}
* Using muliple shards...{noformat}
bin/solr -e cloud
# choose multiple shards, any number of replicas, w/ sample_techproducts_configs
bin/post -c techproducts example/exampledocs/
$ curl http://localhost:8983/solr/techproducts/select -d 
'q=*:*=xml=0={ foo:{type:range, field:price, start:0, 
end:1000, gap:100, other:all } }'




  true
  0
  60
  
*:*
{ foo:{type:range, field:price, start:0, end:1000, 
gap:100, other:all } }
0
xml
  




  50
  

  
0.0
17
  
  
100.0
2
  
  
200.0
1
  
  ...


  0


  1


  25

  


{noformat}


> json.facet can use inconsistent Long/Integer for "count" depending on shard 
> count
> -
>
> Key: SOLR-11775
> URL: https://issues.apache.org/jira/browse/SOLR-11775
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> (NOTE: I noticed this while working on a test for {{type: range}} but it's 
> possible other facet types may be affected as well)
> When dealing with a single core request -- either standalone or a collection 
> with only one shard -- json.facet seems to use "Integer" objects to return 
> the "count" of facet buckets, however if the shard count is increased then 
> the end client gets a "Long" object for the "count"
> (This isn't noticable when using {{wt=json}} but can be very problematic when 
> trying to write client code using {{wt=xml}} or SolrJ



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11775) json.facet can use inconsistent Long/Integer for "count" depending on shard count

[Hoss Man (JIRA)]

Hoss Man created SOLR-11775:
---

 Summary: json.facet can use inconsistent Long/Integer for "count" 
depending on shard count
 Key: SOLR-11775
 URL: https://issues.apache.org/jira/browse/SOLR-11775
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


(NOTE: I noticed this while working on a test for {{type: range}} but it's 
possible other facet types may be affected as well)

When dealing with a single core request -- either standalone or a collection 
with only one shard -- json.facet seems to use "Integer" objects to return the 
"count" of facet buckets, however if the shard count is increased then the end 
client gets a "Long" object for the "count"

(This isn't noticable when using {{wt=json}} but can be very problematic when 
trying to write client code using {{wt=xml}} or SolrJ



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: [VOTE] Release Lucene/Solr 7.2.0 RC1

[Martijn v Groningen]

+1

SUCCESS! [1:05:17.701417]

On Mon, Dec 18, 2017 at 1:26 AM Michael McCandless <
luc...@mikemccandless.com> wrote:

> +1
>
> SUCCESS! [0:36:22.387901]
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Fri, Dec 15, 2017 at 3:22 AM, Adrien Grand  wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 7.2.0The artifacts can 
>> be downloaded 
>> from:https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.2.0-RC1-revbca54cad5a9f6a80800944fd5bd585b68acde8c8/You
>>  can run the smoke tester directly with this command:python3 -u 
>> dev-tools/scripts/smokeTestRelease.py 
>> \https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.2.0-RC1-revbca54cad5a9f6a80800944fd5bd585b68acde8c8/Here's
>>  my +1
>>
>>
>

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 1011 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1011/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseParallelGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=3777, name=jetty-launcher-872-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)   
 2) Thread[id=3776, name=jetty-launcher-872-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=3777, name=jetty-launcher-872-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

[jira] [Resolved] (SOLR-11753) Ref Guide: Upgrade notes for 7.2

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-11753.
--
   Resolution: Fixed
Fix Version/s: master (8.0)

> Ref Guide: Upgrade notes for 7.2
> 
>
> Key: SOLR-11753
> URL: https://issues.apache.org/jira/browse/SOLR-11753
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: 7.2, master (8.0)
>
>
> Issue to track adding 7.2 upgrade notes for the Ref Guide.
> Also serves as an umbrella issue for small edits done as part of copy editing 
> the 7.2 release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11753) Ref Guide: Upgrade notes for 7.2

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11753:


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

SOLR-11753: minor typos


> Ref Guide: Upgrade notes for 7.2
> 
>
> Key: SOLR-11753
> URL: https://issues.apache.org/jira/browse/SOLR-11753
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: 7.2
>
>
> Issue to track adding 7.2 upgrade notes for the Ref Guide.
> Also serves as an umbrella issue for small edits done as part of copy editing 
> the 7.2 release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11753) Ref Guide: Upgrade notes for 7.2

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11753:


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

SOLR-11753: minor typos


> Ref Guide: Upgrade notes for 7.2
> 
>
> Key: SOLR-11753
> URL: https://issues.apache.org/jira/browse/SOLR-11753
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: 7.2
>
>
> Issue to track adding 7.2 upgrade notes for the Ref Guide.
> Also serves as an umbrella issue for small edits done as part of copy editing 
> the 7.2 release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-8099) Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery

[Alan Woodward (JIRA)]

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

Alan Woodward resolved LUCENE-8099.
---
   Resolution: Fixed
Fix Version/s: 7.3

Thanks David!

> Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery
> --
>
> Key: LUCENE-8099
> URL: https://issues.apache.org/jira/browse/LUCENE-8099
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 7.3
>
> Attachments: LUCENE-8099.patch, LUCENE-8099.patch
>
>
> After LUCENE-7998, these three queries can all be replaced by a 
> FunctionScoreQuery.  Using lucene-expressions makes them much easier to use 
> as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8099) Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8099: Remove deprecated CustomScoreQuery, BoostedQuery, BoostingQuery


> Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery
> --
>
> Key: LUCENE-8099
> URL: https://issues.apache.org/jira/browse/LUCENE-8099
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 7.3
>
> Attachments: LUCENE-8099.patch, LUCENE-8099.patch
>
>
> After LUCENE-7998, these three queries can all be replaced by a 
> FunctionScoreQuery.  Using lucene-expressions makes them much easier to use 
> as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11753) Ref Guide: Upgrade notes for 7.2

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11753:


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

SOLR-11753: minor typos


> Ref Guide: Upgrade notes for 7.2
> 
>
> Key: SOLR-11753
> URL: https://issues.apache.org/jira/browse/SOLR-11753
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: 7.2
>
>
> Issue to track adding 7.2 upgrade notes for the Ref Guide.
> Also serves as an umbrella issue for small edits done as part of copy editing 
> the 7.2 release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8099) Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8099: Deprecate CustomScoreQuery, BoostedQuery, BoostingQuery


> Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery
> --
>
> Key: LUCENE-8099
> URL: https://issues.apache.org/jira/browse/LUCENE-8099
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 7.3
>
> Attachments: LUCENE-8099.patch, LUCENE-8099.patch
>
>
> After LUCENE-7998, these three queries can all be replaced by a 
> FunctionScoreQuery.  Using lucene-expressions makes them much easier to use 
> as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8099) Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8099: Deprecate CustomScoreQuery, BoostedQuery, BoostingQuery


> Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery
> --
>
> Key: LUCENE-8099
> URL: https://issues.apache.org/jira/browse/LUCENE-8099
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 7.3
>
> Attachments: LUCENE-8099.patch, LUCENE-8099.patch
>
>
> After LUCENE-7998, these three queries can all be replaced by a 
> FunctionScoreQuery.  Using lucene-expressions makes them much easier to use 
> as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11774) langid.map.individual won't work with langid.map.keepOrig

[Marco Remy (JIRA)]

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

Marco Remy updated SOLR-11774:
--
Description: 
Tried to get language detection to work.

*Setting:*
{code:xml}

  title,author
  detected_languages
  de,en
  txt
  true
  true
  true

{code}

Main purpose
* Map fields individually
* Keep the original field

But the fields won't be mapped individually. They are mapped to a single 
detected language. After some hours of investigation i finally found the 
reason: *The option langid.map.keepOrig breaks the individual mapping 
function.* Only if it is disabled the fields will be mapped as expected.

- Regards

  was:
Tried to get language detection to work.

*Setting:*
{code:xml}

  title,author
  detected_languages
  de,en
  txt
  true
  true
  true

{code}

Main purpose
* Map fields individually
* Keep the original field

But the fields won't mapped individually. They are mapped to a single detected 
language. After some hours of investigation i finally found the reason: *The 
option langid.map.keepOrig breaks the individual mapping function.* When it is 
disabled the fields will be mapped as expected.

- Regards


> langid.map.individual won't work with langid.map.keepOrig
> -
>
> Key: SOLR-11774
> URL: https://issues.apache.org/jira/browse/SOLR-11774
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 6.5
>Reporter: Marco Remy
>Priority: Minor
>
> Tried to get language detection to work.
> *Setting:*
> {code:xml}
>  class="org.apache.solr.update.processor.LangDetectLanguageIdentifierUpdateProcessorFactory">
>   title,author
>   detected_languages
>   de,en
>   txt
>   true
>   true
>   true
> 
> {code}
> Main purpose
> * Map fields individually
> * Keep the original field
> But the fields won't be mapped individually. They are mapped to a single 
> detected language. After some hours of investigation i finally found the 
> reason: *The option langid.map.keepOrig breaks the individual mapping 
> function.* Only if it is disabled the fields will be mapped as expected.
> - Regards



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11774) langid.map.individual won't work with langid.map.keepOrig

[Marco Remy (JIRA)]

Marco Remy created SOLR-11774:
-

 Summary: langid.map.individual won't work with langid.map.keepOrig
 Key: SOLR-11774
 URL: https://issues.apache.org/jira/browse/SOLR-11774
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: contrib - LangId
Affects Versions: 6.5
Reporter: Marco Remy
Priority: Minor


Tried to get language detection to work.

*Setting:*
{code:xml}

  title,author
  detected_languages
  de,en
  txt
  true
  true
  true

{code}

Main purpose
* Map fields individually
* Keep the original field

But the fields won't mapped individually. They are mapped to a single detected 
language. After some hours of investigation i finally found the reason: *The 
option langid.map.keepOrig breaks the individual mapping function.* When it is 
disabled the fields will be mapped as expected.

- Regards



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Lucene/Solr 7.2

[Cassandra Targett]

The Ref Guide is pretty much ready also. I'm going to commit a few more
little typos/fixes and try to spin an RC for that by the end of the day
today. I'm traveling mid-week but would be able to do the release at the
end of the week (or respin if it comes to that).

Cassandra

On Wed, Dec 13, 2017 at 11:08 AM, Adrien Grand  wrote:

> https://issues.apache.org/jira/browse/LUCENE-8090 and
> https://issues.apache.org/jira/browse/SOLR-11740 are now resolved, so as
> far as I know there are no more blockers. I will build a RC tomorrow.
>
> Le lun. 11 déc. 2017 à 11:33, Adrien Grand  a écrit :
>
>> We have another blocker: https://issues.apache.org/
>> jira/browse/LUCENE-8090.
>>
>> Could someone help Varun investigate https://issues.apache.org/
>> jira/browse/SOLR-11740? I just made it a blocker as well until we know
>> more about it.
>>
>> Le sam. 9 déc. 2017 à 08:57, Varun Thacker  a écrit :
>>
>>> This fails for me every single time : https://issues.apache.org/
>>> jira/browse/SOLR-11740
>>>
>>> Can someone with more knowledge of the bin/solr script confirm if this
>>> effects the "-e cloud" command only or is it more widespread .
>>> That might help determine if we want to fix this before the release.
>>>
>>> On Fri, Dec 8, 2017 at 10:41 AM, Adrien Grand  wrote:
>>>
 FYI we are backporting SOLR-11423
  to 7.2 so I'll
 build a RC on Monday (assuming it will have been backported by then).

 Le jeu. 7 déc. 2017 à 20:17, Adrien Grand  a écrit :

> OK, it looks like all changes that we wanted to be included are now
> in? Please let me know if there is still something left to include in 7.2
> before building a RC.
>
> I noticed SOLR-11423 is in a weird state, it is included in the
> changelog in 7.1 but has only been committed to master. Did we forget to
> backport it?
>
> Le mer. 6 déc. 2017 à 21:13, Andrzej Białecki <
> andrzej.biale...@lucidworks.com> a écrit :
>
>> On 6 Dec 2017, at 18:45, Andrzej Białecki <
>> andrzej.biale...@lucidworks.com> wrote:
>>
>> I attached the patch to SOLR-11714, which disables the ‘searchRate’
>> trigger - if there are no objections I’ll commit it shortly to 
>> branch_7.2.
>>
>>
>>
>> This has been committed now to branch_7_2 and I don’t have any other
>> open issues for 7.2. Thanks!
>>
>>
>>
>> On 6 Dec 2017, at 15:51, Andrzej Białecki <
>> andrzej.biale...@lucidworks.com> wrote:
>>
>>
>> On 6 Dec 2017, at 15:35, Andrzej Białecki <
>> andrzej.biale...@lucidworks.com> wrote:
>>
>> SOLR-11458 is committed and resolved - thanks for the patience.
>>
>>
>>
>> Actually, one more thing … ;) SOLR-11714 is a more serious bug in a
>> new feature (searchRate autoscaling trigger). It’s probably best to 
>> disable
>> this feature in 7.2 rather than releasing a broken version, so I’d like 
>> to
>> commit a patch that disables it (plus a note in CHANGES.txt).
>>
>>
>>
>>
>> On 6 Dec 2017, at 14:02, Adrien Grand  wrote:
>>
>> Thanks for the heads up, Anshum.
>>
>> This leaves us with only SOLR-11458 to wait for before building a RC
>> (which might be ready but just not marked as resolved).
>>
>>
>>
>> Le mer. 6 déc. 2017 à 13:47, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> a écrit :
>>
>>> Hi Adrien,
>>> I'm planning to skip SOLR-11624 for this release (as per my last
>>> comment https://issues.apache.org/jira/browse/SOLR-11624?
>>> focusedCommentId=16280121=com.atlassian.jira.
>>> plugin.system.issuetabpanels:comment-tabpanel#comment-16280121). If
>>> someone has an objection, please let me know; otherwise, please feel 
>>> free
>>> to proceed with the release.
>>> I'll continue working on it anyway, and shall try to have it ready
>>> for the next release.
>>> Thanks,
>>> Ishan
>>>
>>> On Wed, Dec 6, 2017 at 2:41 PM, Adrien Grand 
>>> wrote:
>>>
 FYI I created the new branch for 7.2, so you will have to backport
 to this branch. No hurry though, I mostly created the branch so that 
 it's
 fine to cherry-pick changes that may wait for 7.3 to be released.

 Le mer. 6 déc. 2017 à 08:53, Adrien Grand  a
 écrit :

> Sorry to hear that Ishan, I hope you are doing better now. +1 to
> get SOLR-11624 in.
>
> Le mer. 6 déc. 2017 à 07:57, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> a écrit :
>
>> I was a bit unwell over the weekend and yesterday; I'm working on
>> a very targeted fix for SOLR-11624 right now; I expect it to take 
>> 

[jira] [Commented] (LUCENE-8099) Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8099:
--

+1 LGTM, thanks Alan.

> Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery
> --
>
> Key: LUCENE-8099
> URL: https://issues.apache.org/jira/browse/LUCENE-8099
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-8099.patch, LUCENE-8099.patch
>
>
> After LUCENE-7998, these three queries can all be replaced by a 
> FunctionScoreQuery.  Using lucene-expressions makes them much easier to use 
> as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (LUCENE-8103) QueryValueSource should use TwoPhaseIterator

[David Smiley (JIRA)]

David Smiley created LUCENE-8103:


 Summary: QueryValueSource should use TwoPhaseIterator
 Key: LUCENE-8103
 URL: https://issues.apache.org/jira/browse/LUCENE-8103
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/other
Reporter: David Smiley
Priority: Minor


QueryValueSource (in "queries" module) is a ValueSource representation of a 
Query; the score is the value.  It ought to try to use a TwoPhaseIterator from 
the query if it can be offered. This will prevent possibly expensive advancing 
beyond documents that we aren't interested in.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+32) - Build # 21104 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21104/
Java: 64bit/jdk-10-ea+32 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
expected:<3> but was:<1>

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([C303617012824E7D:8B7615C414B161E8]: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.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:466)
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 
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 1780 lines...]
   [junit4] JVM J1: stderr was not empty, see: 

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

[Apache Jenkins Server]

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

17 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.test

Error Message:
Collection not found: testalias1

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: testalias1
at 
__randomizedtesting.SeedInfo.seed([1CE93EE81BD94441:94BD0132B52529B9]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:851)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.AliasIntegrationTest.searchSeveralWays(AliasIntegrationTest.java:296)
at 
org.apache.solr.cloud.AliasIntegrationTest.searchSeveralWays(AliasIntegrationTest.java:290)
at 
org.apache.solr.cloud.AliasIntegrationTest.test(AliasIntegrationTest.java:206)
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 

[jira] [Commented] (SOLR-11764) preanalyzed field with highlight option throws exception

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11764:
---

bq. I suspect that this isn't going to work because the field in question needs 
to be "stored" and I recall that's not possible with a PreAnalyzedField

Looks possible to me?: 
https://lucene.apache.org/solr/guide/7_1/working-with-external-files-and-processes.html#the-preanalyzedfield-type

> preanalyzed field with highlight option throws exception
> 
>
> Key: SOLR-11764
> URL: https://issues.apache.org/jira/browse/SOLR-11764
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 6.4
>Reporter: Selvam Raman
>
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
> Error from server at http://localhost:8983/solr/Metadata2: 
> org.apache.solr.client.solrj.SolrServerException:
> No live SolrServers available to handle this 
> request:[/solr/Metadata2_shard1_replica1,
>   solr/Metadata2_shard2_replica2, 
>   solr/Metadata2_shard1_replica2]
> When i look at the solr logs i find the below exception
> Caused by: java.io.IOException: Invalid JSON type java.lang.String, expected 
> Map
>   at 
> org.apache.solr.schema.JsonPreAnalyzedParser.parse(JsonPreAnalyzedParser.java:86)
>   at 
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedTokenizer.decodeInput(PreAnalyzedField.java:345)
>   at 
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedTokenizer.access$000(PreAnalyzedField.java:280)
>   at 
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer$1.setReader(PreAnalyzedField.java:375)
>   at org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:202)
>   at 
> org.apache.lucene.search.uhighlight.AnalysisOffsetStrategy.tokenStream(AnalysisOffsetStrategy.java:58)
>   at 
> org.apache.lucene.search.uhighlight.MemoryIndexOffsetStrategy.getOffsetsEnums(MemoryIndexOffsetStrategy.java:106)
>   ... 37 more
>  I am setting up lot of fields (fq, score, highlight,etc) then put it into 
> solrquery.
> "we are using preanalyzed field and that causing the problem. 
> The actual problem is preanalyzed with highlight option. if i disable 
> highlight option it works fine."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8102) CompiledAutomaton performance for determining common suffix

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8102:
-

Also here are few more ideas:
* There is a TODO in the code regarding using found sink state... a method 
findSinkState was added here and is actually called, but its not used to 
determine whether or not common suffix should be computed, but only if this 
really works (there should be some tests)
* The optimization could be guarded with a state count check maybe (something 
absurd). 

Either way, I think its really important not to regress on common "stupid 
simple" queries like leading wildcards. 

> CompiledAutomaton performance for determining common suffix
> ---
>
> Key: LUCENE-8102
> URL: https://issues.apache.org/jira/browse/LUCENE-8102
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/FSTs
>Affects Versions: 7.1
>Reporter: Thomas Poppe
>
> We're using the automaton package as part of Elasticsearch for doing regexp 
> queries.  Our business requires us to process rather complex regular 
> expressions, for example (we have more complex examples, but this one 
> illustrates the problem):
> {noformat}
> (¦.)*(¦?[^¦]){1,10}ab(¦.)*(¦?[^¦]){1,10}c(¦.)*(¦?[^¦]){1,10}d
> {noformat}
> With a large enough value of maxDeterminizedStates, this works.  The problem 
> we're having is that the conversion of this regular expression to a 
> CompiledAutomaton takes very long.  Almost all of the time goes into 
> determining the common suffix for the Automaton (which is "d" in this 
> example) - calculated with a call to Operations.getCommonSuffixBytesRef.
> This suffix is only used as an optimization.  Skipping the calculation of 
> this suffix allows us to process these kinds of queries.
> - Would it be possible to introduce a way to skip the calculation of this 
> common suffix (ideally something we control from within our query to 
> Elasticsearch)?
> - Or would it be possible to take a look at this getCommonSuffixBytesRef 
> operation, to see if it can be optimized?  Most of the time goes to 
> determinizing the reversed automaton - maybe this can be avoided somehow?
> Reaction from Mike McCandless on the mailing list:
> This is just an optimization; maybe we should expose an option to disable it?
> Or maybe we can find the common suffix on an NFA instead, to avoid 
> determinization?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1573 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1573/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete

Error Message:
Error from server at 
https://127.0.0.1:33421/solr/testcollection_shard1_replica_n2: Expected mime 
type application/octet-stream but got text/html.Error 
404HTTP ERROR: 404 Problem accessing 
/solr/testcollection_shard1_replica_n2/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n2/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.20.v20170531 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at https://127.0.0.1:33421/solr/testcollection_shard1_replica_n2: 
Expected mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: /solr/testcollection_shard1_replica_n2/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.20.v20170531



at 
__randomizedtesting.SeedInfo.seed([3AA6C11F4E1CC608:995C6FBAC9F42CAD]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:550)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1013)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:167)
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 

[jira] [Commented] (LUCENE-7722) Remove BoostedQuery

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-7722:
---

Think this can be resolved as a duplicate of LUCENE-8099

> Remove BoostedQuery
> ---
>
> Key: LUCENE-7722
> URL: https://issues.apache.org/jira/browse/LUCENE-7722
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
>
> We already  have FunctionScoreQuery, which is more flexible than BoostedQuery 
> as it can combine scores in arbitrary ways and only requests scores on the 
> underlying scorer if they are needed. So let's remove BoostedQuery?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-8099) Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery

[Alan Woodward (JIRA)]

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

Alan Woodward updated LUCENE-8099:
--
Attachment: LUCENE-8099.patch

Patch adding support to MultiTermHighlighting and javadocs to BoostQuery

> Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery
> --
>
> Key: LUCENE-8099
> URL: https://issues.apache.org/jira/browse/LUCENE-8099
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-8099.patch, LUCENE-8099.patch
>
>
> After LUCENE-7998, these three queries can all be replaced by a 
> FunctionScoreQuery.  Using lucene-expressions makes them much easier to use 
> as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8099) Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-8099:
---

bq. RE DoubleValueSource helper: which issue do you refer to?

LUCENE-7723

bq. Something to consider

Let's wait and see if questions appear on the list after deprecation?  
Expressions are going to be much more flexible than a static method.

> Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery
> --
>
> Key: LUCENE-8099
> URL: https://issues.apache.org/jira/browse/LUCENE-8099
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-8099.patch
>
>
> After LUCENE-7998, these three queries can all be replaced by a 
> FunctionScoreQuery.  Using lucene-expressions makes them much easier to use 
> as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11772) Use JDBC-bind variables for DIH to improve performance with oracle db

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11772:
-

Do you have a patch?  If so, does the patch use Oracle-specific code, or is it 
generic JDBC?  If the JDBC driver is NOT Oracle's driver (user has mysql, 
postgres, sql server, etc), does following Oracle's recommendation cause bad 
performance?

Is it possible to set the cursor-sharing parameter in the jdbc url?  If it is, 
then no code changes are needed.

If you can rearrange your SQL queries (using JOIN, VIEW, etc) so DIH can make 
*one* query instead of 17 million, then DIH is probably going to go faster.


> Use JDBC-bind variables for DIH to improve performance with oracle db
> -
>
> Key: SOLR-11772
> URL: https://issues.apache.org/jira/browse/SOLR-11772
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Karl Zweimüller
>Priority: Minor
>
> I just reduced the time for my full-import (solr 6.0.1) on an oracle-database 
> for 1.4mio documents from 36 hours to 5 hours by setting the oracle 
> session-parameter "CURSOR_SHARING=FORCE".
> Here I found one with the same problem:
> http://lucene.472066.n3.nabble.com/Optimizing-Dataimport-from-Oracle-cursor-sharing-changing-oracle-session-parameters-td4350601.html
> I have 1.4 mio documents and for every document i need 12 queries to collect 
> sub-information for the actual document.
> This makes about 17mio sql-Statements to oracle for a full-import.
> As DIH doesn't use bind-variables 
> (https://docs.oracle.com/cd/B28359_01/appdev.111/b28765/addfunc.htm#TDPJD210),
>  every select looks "different" for oracle and a full parse (analyze 
> statement, get optimal query-plan,..) has to be done 17mio times.
> By setting the session parameter "CURSOR_SHARING=FORCE", which can be done in 
> an on_logon_trigger, oracle replaces all literals ins SQL with bind-variables 
> and then can skip the hard-parse.
> This reduced my full-import-time from 36 hours to 5 hours. (With this you get 
> only 13 different sql-statements compared to 17mio different statements 
> before.
> As oracle states, that setting the CURSOR_SHARING=FORCE is only a workaround, 
> it would be fine when DIH would use bind-variables for the variables.
> Charly



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8102) CompiledAutomaton performance for determining common suffix

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8102:
-

The optimization speeds up leading wildcard type-queries (such as wildcard 
"*foo" or regex ".*foo") which are far more common e.g. on the users list than 
the example presented on this issue, so I really think we should keep it. 

The regex here is quite obscene, maybe its the thing that should be optimized? 
:)


> CompiledAutomaton performance for determining common suffix
> ---
>
> Key: LUCENE-8102
> URL: https://issues.apache.org/jira/browse/LUCENE-8102
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/FSTs
>Affects Versions: 7.1
>Reporter: Thomas Poppe
>
> We're using the automaton package as part of Elasticsearch for doing regexp 
> queries.  Our business requires us to process rather complex regular 
> expressions, for example (we have more complex examples, but this one 
> illustrates the problem):
> {noformat}
> (¦.)*(¦?[^¦]){1,10}ab(¦.)*(¦?[^¦]){1,10}c(¦.)*(¦?[^¦]){1,10}d
> {noformat}
> With a large enough value of maxDeterminizedStates, this works.  The problem 
> we're having is that the conversion of this regular expression to a 
> CompiledAutomaton takes very long.  Almost all of the time goes into 
> determining the common suffix for the Automaton (which is "d" in this 
> example) - calculated with a call to Operations.getCommonSuffixBytesRef.
> This suffix is only used as an optimization.  Skipping the calculation of 
> this suffix allows us to process these kinds of queries.
> - Would it be possible to introduce a way to skip the calculation of this 
> common suffix (ideally something we control from within our query to 
> Elasticsearch)?
> - Or would it be possible to take a look at this getCommonSuffixBytesRef 
> operation, to see if it can be optimized?  Most of the time goes to 
> determinizing the reversed automaton - maybe this can be avoided somehow?
> Reaction from Mike McCandless on the mailing list:
> This is just an optimization; maybe we should expose an option to disable it?
> Or maybe we can find the common suffix on an NFA instead, to avoid 
> determinization?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11773) configurable language config for tesseract ocr

[Advokat (JIRA)]

Advokat created SOLR-11773:
--

 Summary: configurable language config for tesseract ocr
 Key: SOLR-11773
 URL: https://issues.apache.org/jira/browse/SOLR-11773
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.1
Reporter: Advokat
Priority: Minor


Currently to change the language for tesseract I have to manipulate the 
\org\apache\tika\parser\ocr\TesseractOCRConfig.properties in 
tika-parsers-1.16.jar.

There is no possibility to set the language in solrconfig.xml or on each 
request to the ExtractingRequestHandler.

If someone has documents with different languages its impossible to configure 
this. Tesseract will not work as good as it could with correct set language.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Welcome Ahmet Arslan as Lucene/Solr committer

[Steve Rowe]

Congrats and welcome Ahmet!

--
Steve
www.lucidworks.com

> On Dec 17, 2017, at 5:15 AM, Adrien Grand  wrote:
> 
> Hi all,
> 
> Please join me in welcoming Ahmet Arslan as the latest Lucene/Solr committer.
> Ahmet, it's tradition for you to introduce yourself with a brief bio.
> 
> Congratulations and Welcome!
> 
> Adrien


-
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-9.0.1) - Build # 1010 - Still Unstable!

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test

Error Message:
Error from server at http://127.0.0.1:34501: Could not fully create collection: 
collection1

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:34501: Could not fully create collection: 
collection1
at 
__randomizedtesting.SeedInfo.seed([7F6F0138C47BC459:F73B3EE26A87A9A1]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:385)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:334)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991)
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 

[GitHub] lucene-solr pull request #293: spellcheck prefix already contains a trailing...

[kevinlacire]

GitHub user kevinlacire opened a pull request:

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

spellcheck prefix already contains a trailing dot



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

$ git pull https://github.com/kevinlacire/lucene-solr patch-1

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

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


commit 42a9aefc6fcba154ed9d969d04658fd563f07421
Author: Kévin 
Date:   2017-12-18T12:53:04Z

spellcheck prefix already contains a trailing dot




---

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.1) - Build # 21103 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21103/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.impl.ConnectionReuseTest

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at __randomizedtesting.SeedInfo.seed([8BECDAAF891E636A]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1261)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:449)
at 
org.apache.solr.client.solrj.impl.ConnectionReuseTest.setupCluster(ConnectionReuseTest.java:67)
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$6.evaluate(RandomizedRunner.java:874)
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 13629 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.impl.ConnectionReuseTest
   [junit4]   2> 1701617 INFO  
(SUITE-ConnectionReuseTest-seed#[8BECDAAF891E636A]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.client.solrj.impl.ConnectionReuseTest_8BECDAAF891E636A-001/init-core-data-001
   [junit4]   2> 1701617 WARN  
(SUITE-ConnectionReuseTest-seed#[8BECDAAF891E636A]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2
   [junit4]   2> 1701617 INFO  
(SUITE-ConnectionReuseTest-seed#[8BECDAAF891E636A]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 1701618 INFO  
(SUITE-ConnectionReuseTest-seed#[8BECDAAF891E636A]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl="None")
   [junit4]   2> 1701618 INFO  
(SUITE-ConnectionReuseTest-seed#[8BECDAAF891E636A]-worker) [] 
o.a.s.c.MiniSolrCloudCluster Starting cluster of 1 servers in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.client.solrj.impl.ConnectionReuseTest_8BECDAAF891E636A-001/tempDir-001
   [junit4]   2> 1701618 INFO  
(SUITE-ConnectionReuseTest-seed#[8BECDAAF891E636A]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1701618 INFO  (Thread-4558) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1701618 INFO  (Thread-4558) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1701620 ERROR (Thread-4558) [] o.a.z.s.ZooKeeperServer 

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk1.8.0_144) - Build # 348 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/348/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testConsistencyOnExceptions

Error Message:
Captured an uncaught exception in thread: Thread[id=18, 
name=ReplicationThread-indexAndTaxo, state=RUNNABLE, 
group=TGRP-IndexAndTaxonomyReplicationClientTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=18, name=ReplicationThread-indexAndTaxo, 
state=RUNNABLE, group=TGRP-IndexAndTaxonomyReplicationClientTest]
at 
__randomizedtesting.SeedInfo.seed([ECBFD4653FFEAAA3:633133C52D92595C]:0)
Caused by: java.lang.AssertionError: handler failed too many times: -1
at __randomizedtesting.SeedInfo.seed([ECBFD4653FFEAAA3]:0)
at 
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest$4.handleUpdateException(IndexAndTaxonomyReplicationClientTest.java:422)
at 
org.apache.lucene.replicator.ReplicationClient$ReplicationThread.run(ReplicationClient.java:77)


FAILED:  org.apache.solr.handler.TestBlobHandler.doBlobHandlerTest

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:57604

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:57604
at 
__randomizedtesting.SeedInfo.seed([EAC1A3309403F2A5:A0081622FEF8457]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:315)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991)
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 

[JENKINS-EA] Lucene-Solr-7.2-Linux (64bit/jdk-10-ea+32) - Build # 80 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Linux/80/
Java: 64bit/jdk-10-ea+32 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.update.TestInPlaceUpdatesDistrib.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:36969/mf/fb/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:36969/mf/fb/collection1
at 
__randomizedtesting.SeedInfo.seed([577EF3B94A888B30:DF2ACC63E474E6C8]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1582)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.docValuesUpdateTest(TestInPlaceUpdatesDistrib.java:349)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
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 

[jira] [Updated] (LUCENE-8102) CompiledAutomaton performance for determining common suffix

[Thomas Poppe (JIRA)]

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

Thomas Poppe updated LUCENE-8102:
-
Description: 
We're using the automaton package as part of Elasticsearch for doing regexp 
queries.  Our business requires us to process rather complex regular 
expressions, for example (we have more complex examples, but this one 
illustrates the problem):

{noformat}
(¦.)*(¦?[^¦]){1,10}ab(¦.)*(¦?[^¦]){1,10}c(¦.)*(¦?[^¦]){1,10}d
{noformat}

With a large enough value of maxDeterminizedStates, this works.  The problem 
we're having is that the conversion of this regular expression to a 
CompiledAutomaton takes very long.  Almost all of the time goes into 
determining the common suffix for the Automaton (which is "d" in this example) 
- calculated with a call to Operations.getCommonSuffixBytesRef.

This suffix is only used as an optimization.  Skipping the calculation of this 
suffix allows us to process these kinds of queries.

- Would it be possible to introduce a way to skip the calculation of this 
common suffix (ideally something we control from within our query to 
Elasticsearch)?
- Or would it be possible to take a look at this getCommonSuffixBytesRef 
operation, to see if it can be optimized?  Most of the time goes to 
determinizing the reversed automaton - maybe this can be avoided somehow?


Reaction from Mike McCandless on the mailing list:
This is just an optimization; maybe we should expose an option to disable it?
Or maybe we can find the common suffix on an NFA instead, to avoid 
determinization?

  was:
We're using the automaton package as part of Elasticsearch for doing regexp 
queries.  Our business requires us to process rather complex regular 
expressions, for example (we have more complex examples, but this one 
illustrates the problem):

(¦.)*(¦?[^¦]){1,10}ab(¦.)*(¦?[^¦]){1,10}c(¦.)*(¦?[^¦]){1,10}d

With a large enough value of maxDeterminizedStates, this works.  The problem 
we're having is that the conversion of this regular expression to a 
CompiledAutomaton takes very long.  Almost all of the time goes into 
determining the common suffix for the Automaton (which is "d" in this example) 
- calculated with a call to Operations.getCommonSuffixBytesRef.

This suffix is only used as an optimization.  Skipping the calculation of this 
suffix allows us to process these kinds of queries.

- Would it be possible to introduce a way to skip the calculation of this 
common suffix (ideally something we control from within our query to 
Elasticsearch)?
- Or would it be possible to take a look at this getCommonSuffixBytesRef 
operation, to see if it can be optimized?  Most of the time goes to 
determinizing the reversed automaton - maybe this can be avoided somehow?


Reaction from Mike McCandless on the mailing list:
This is just an optimization; maybe we should expose an option to disable it?
Or maybe we can find the common suffix on an NFA instead, to avoid 
determinization?


> CompiledAutomaton performance for determining common suffix
> ---
>
> Key: LUCENE-8102
> URL: https://issues.apache.org/jira/browse/LUCENE-8102
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/FSTs
>Affects Versions: 7.1
>Reporter: Thomas Poppe
>
> We're using the automaton package as part of Elasticsearch for doing regexp 
> queries.  Our business requires us to process rather complex regular 
> expressions, for example (we have more complex examples, but this one 
> illustrates the problem):
> {noformat}
> (¦.)*(¦?[^¦]){1,10}ab(¦.)*(¦?[^¦]){1,10}c(¦.)*(¦?[^¦]){1,10}d
> {noformat}
> With a large enough value of maxDeterminizedStates, this works.  The problem 
> we're having is that the conversion of this regular expression to a 
> CompiledAutomaton takes very long.  Almost all of the time goes into 
> determining the common suffix for the Automaton (which is "d" in this 
> example) - calculated with a call to Operations.getCommonSuffixBytesRef.
> This suffix is only used as an optimization.  Skipping the calculation of 
> this suffix allows us to process these kinds of queries.
> - Would it be possible to introduce a way to skip the calculation of this 
> common suffix (ideally something we control from within our query to 
> Elasticsearch)?
> - Or would it be possible to take a look at this getCommonSuffixBytesRef 
> operation, to see if it can be optimized?  Most of the time goes to 
> determinizing the reversed automaton - maybe this can be avoided somehow?
> Reaction from Mike McCandless on the mailing list:
> This is just an optimization; maybe we should expose an option to disable it?
> Or maybe we can find the common suffix on an NFA instead, to avoid 
> determinization?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LUCENE-8102) CompiledAutomaton performance for determining common suffix

[Thomas Poppe (JIRA)]

Thomas Poppe created LUCENE-8102:


 Summary: CompiledAutomaton performance for determining common 
suffix
 Key: LUCENE-8102
 URL: https://issues.apache.org/jira/browse/LUCENE-8102
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/FSTs
Affects Versions: 7.1
Reporter: Thomas Poppe


We're using the automaton package as part of Elasticsearch for doing regexp 
queries.  Our business requires us to process rather complex regular 
expressions, for example (we have more complex examples, but this one 
illustrates the problem):

(¦.)*(¦?[^¦]){1,10}ab(¦.)*(¦?[^¦]){1,10}c(¦.)*(¦?[^¦]){1,10}d

With a large enough value of maxDeterminizedStates, this works.  The problem 
we're having is that the conversion of this regular expression to a 
CompiledAutomaton takes very long.  Almost all of the time goes into 
determining the common suffix for the Automaton (which is "d" in this example) 
- calculated with a call to Operations.getCommonSuffixBytesRef.

This suffix is only used as an optimization.  Skipping the calculation of this 
suffix allows us to process these kinds of queries.

- Would it be possible to introduce a way to skip the calculation of this 
common suffix (ideally something we control from within our query to 
Elasticsearch)?
- Or would it be possible to take a look at this getCommonSuffixBytesRef 
operation, to see if it can be optimized?  Most of the time goes to 
determinizing the reversed automaton - maybe this can be avoided somehow?


Reaction from Mike McCandless on the mailing list:
This is just an optimization; maybe we should expose an option to disable it?
Or maybe we can find the common suffix on an NFA instead, to avoid 
determinization?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

JDK 10 entered Rampdown Phase One on 14th of December

[Rory O'Donnell]

 Hi Uwe & Dawid,

*JDK 10 entered Rampdown Phase One on Thursday, 14 December [1] *

 * The Rampdown Phase One process will be similar to that of JDK 9 [2].

*JDK 10 Early Access  build 36 is available at : - jdk.java.net/10/*

Notable changes since previous email.

*JEPS included **the last 3 builds:*
JDK-8192833  :This is 
the primary implementation subtask of JEP 322 - *Time-Based Release 
Versioning*
JDK-8189941  : 
Implementation JEP 312: Thread-local handshake
JDK-8186571  : 
Implementation: JEP 307: Parallel Full GC for G1
JDK-8190308  : 
Implementation: JEP 316: Heap Allocation on Alternative Memory Devices


*build 36
*JDK-8148421  : 
Transport Layer Security (TLS) Session Hash and Extended Master Secret 
Extension
JDK-5016517  : Replace 
plaintext passwords by hashed passwords for out-of-the-box JMX Agent


**

*build 35 *
JDK-8188870  - Bump 
classfile version number to 54
JDK-8185985  - HTML 
files in doc-files subdirectories are wrapped with standard javadoc 
decorations
JDK-8186535 *- *Remove 
deprecated pre-1.2 SecurityManager methods and fields


*build 34* - JDK-8024352 
 - MBeanOperationInfo 
accepts any int value as "impact"


*Bug fixes reported by Open Source Projects  
:*
JDK-8191078  : Wrong 
"Package not found" warning
JDK-8191636  : 
[Windows] jshell tool: Wrong character in /env class-path command 
crashes jshell
JDK-8191834  : 
Assigning a void expression to a "var" crashes the 
compiler
JDK-8182638  : 
[macosx] Active modal dialog is hidden by another non-active one
JDK-8043315  : Nimbus: 
Setting Nimbus.Overrides property affects custom keymap installation
JDK-8172244  : AIOOBE 
in KeyStore.getCertificateAlias on Windows
JDK-8180141  : Missing 
entry in LineNumberTable for break statement that jumps out of try-finall


JDK 10 Schedule, Status & Features are available [3]

*Feedback* - If you have suggestions or encounter bugs, please submit 
them using the usual Java SE bug-reporting channel.
Be sure to include complete version information from the output of the 
|java --version| command.


Regards,
Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000357.html
[2] http://openjdk.java.net/projects/jdk9/rdp-1
[3] http://openjdk.java.net/projects/jdk/10/

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: Welcome Ahmet Arslan as Lucene/Solr committer

[Alan Woodward]

Welcome Ahmet!

> On 17 Dec 2017, at 10:15, Adrien Grand  wrote:
> 
> Hi all,
> 
> Please join me in welcoming Ahmet Arslan as the latest Lucene/Solr committer.
> Ahmet, it's tradition for you to introduce yourself with a brief bio.
> 
> Congratulations and Welcome!
> 
> Adrien

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-10-ea+32) - Build # 1009 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1009/
Java: 64bit/jdk-10-ea+32 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestAuthenticationFramework.testBasics

Error Message:
Error from server at 
https://127.0.0.1:41489/solr/testcollection_shard1_replica_n2: Expected mime 
type application/octet-stream but got text/html.Error 
404HTTP ERROR: 404 Problem accessing 
/solr/testcollection_shard1_replica_n2/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n2/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.20.v20170531 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at https://127.0.0.1:41489/solr/testcollection_shard1_replica_n2: 
Expected mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: /solr/testcollection_shard1_replica_n2/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.20.v20170531



at 
__randomizedtesting.SeedInfo.seed([46E1B959ED02D05C:7B391775D5EC8E2C]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:550)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1013)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestAuthenticationFramework.collectionCreateSearchDeleteTwice(TestAuthenticationFramework.java:126)
at 
org.apache.solr.cloud.TestAuthenticationFramework.testBasics(TestAuthenticationFramework.java:74)
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 
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 

Re: Welcome Ahmet Arslan as Lucene/Solr committer

[Tommaso Teofili]

congrats and welcome Ahmet!

Regards,
Tommaso

Il giorno lun 18 dic 2017 alle ore 05:48 Christian Moen  ha
scritto:

> Congratulations!
>
>
> On Sun, Dec 17, 2017 at 7:15 PM Adrien Grand  wrote:
>
>> Hi all,
>>
>> Please join me in welcoming Ahmet Arslan as the latest Lucene/Solr
>> committer.
>> Ahmet, it's tradition for you to introduce yourself with a brief bio.
>>
>> Congratulations and Welcome!
>>
>>
>> Adrien
>>
>