[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 17389 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17389/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseParallelGC

3 tests failed.
FAILED:  org.apache.solr.client.solrj.TestLBHttpSolrClient.testReliability

Error Message:
GC overhead limit exceeded

Stack Trace:
java.lang.OutOfMemoryError: GC overhead limit exceeded
at 
__randomizedtesting.SeedInfo.seed([4AE132FBD3725089:8B29EFBD72148120]:0)
at 
sun.security.ssl.SSLAlgorithmDecomposer.decomposes(SSLAlgorithmDecomposer.java:51)
at 
sun.security.ssl.SSLAlgorithmDecomposer.decompose(SSLAlgorithmDecomposer.java:212)
at 
sun.security.ssl.SSLAlgorithmDecomposer.decompose(SSLAlgorithmDecomposer.java:243)
at 
sun.security.util.AbstractAlgorithmConstraints.checkAlgorithm(AbstractAlgorithmConstraints.java:104)
at 
sun.security.util.DisabledAlgorithmConstraints.permits(DisabledAlgorithmConstraints.java:91)
at 
sun.security.ssl.SSLAlgorithmConstraints.permits(SSLAlgorithmConstraints.java:149)
at 
sun.security.ssl.Handshaker.getActiveCipherSuites(Handshaker.java:642)
at sun.security.ssl.Handshaker.activate(Handshaker.java:509)
at 
sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1482)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1351)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:511)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:576)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.client.solrj.TestLBHttpSolrClient.waitForServer(TestLBHttpSolrClient.java:237)


FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'CY val' for path 'params/c' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{ "a":"A 
val", "b":"B val", "wt":"json", "useParams":""},   "context":{ 
"webapp":"", "path":"/dump1", "httpMethod":"GET"}},  from server:  
https://127.0.0.1:44503/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'params/c' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{
"a":"A val",
"b":"B val",
"wt":"json",
"useParams":""},
  "context":{
"webapp":"",
"path":"/dump1",
"httpMethod":"GET"}},  from server:  https://127.0.0.1:44503/collection1
at 
__randomizedtesting.SeedInfo.seed([F7B690EF7A2A7A74:7FE2AF35D4D6178C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:481)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:171)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 128 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/128/

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

Error Message:
Timeout occured while waiting response from server at: https://127.0.0.1:53671

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:53671
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:601)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:399)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:526)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)

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

[Ryan Josal (JIRA)]

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

Ryan Josal commented on LUCENE-2899:


Seconded, this is really useful stuff.

> 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: Grant Ingersoll
>Priority: Minor
> Fix For: 4.9, 6.0
>
> 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, 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.3.4#6332)

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

[jira] [Commented] (SOLR-9351) JSON Facet field should sometimes default to facet.method=stream

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9351:


On a related note, I don't see why "stream" and "enum" are different method 
choices (enum resulting in an UnsupportedOperationException right now).

> JSON Facet field should sometimes default to facet.method=stream
> 
>
> Key: SOLR-9351
> URL: https://issues.apache.org/jira/browse/SOLR-9351
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>
> The {{method}} on a field/term facet could be automatically set to "stream" 
> in some cases and get better results?.  For example if {{limit}} is -1 or is 
> a number that is at a decent proportion of the known available terms, then 
> "stream" makes sense to me.  And also, provided that the "base" docset (aka 
> input domain) is large.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9351) JSON Facet field should sometimes default to facet.method=stream

[David Smiley (JIRA)]

David Smiley created SOLR-9351:
--

 Summary: JSON Facet field should sometimes default to 
facet.method=stream
 Key: SOLR-9351
 URL: https://issues.apache.org/jira/browse/SOLR-9351
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: David Smiley


The {{method}} on a field/term facet could be automatically set to "stream" in 
some cases and get better results?.  For example if {{limit}} is -1 or is a 
number that is at a decent proportion of the known available terms, then 
"stream" makes sense to me.  And also, provided that the "base" docset (aka 
input domain) is large.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9342) Solr GC logging not respecting user timezone

[lvchuanwen (JIRA)]

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

lvchuanwen commented on SOLR-9342:
--

remove -Duser.timezone=PST ，the Solr log and GC log time zone should be uniform.

> Solr GC logging not respecting user timezone 
> -
>
> Key: SOLR-9342
> URL: https://issues.apache.org/jira/browse/SOLR-9342
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>
> When I start Solr with say {{-Duser.timezone=PST}} the solr logging correctly 
> logs in the specified timezone.
> However the solr gc logging is still using my machines default timezone. This 
> can be very confusing and make debugging very tough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9350) JSON Facet method:"stream" configurable use of filter cache threshold

[David Smiley (JIRA)]

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

David Smiley edited comment on SOLR-9350 at 7/28/16 3:51 AM:
-

The bug was locally declaring a variable by the same name as a field.  This 
issue might be considered a bug, or improvement since the API works but now 
it's more efficient :-)


was (Author: dsmiley):
The bug was locally declaring a variable by the same name as a field.  This 
issue might be considered a bug, or improvement since the API works but not it 
works better :-)

> JSON Facet method:"stream" configurable use of filter cache threshold
> -
>
> Key: SOLR-9350
> URL: https://issues.apache.org/jira/browse/SOLR-9350
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_9350.patch
>
>
> When using method:"stream" in the JSON facet API, the code will currently 
> always use the filter cache for each value.  This basically blows out the 
> filter cache.  The code has smarts to pick a doc count threshold to use the 
> filter cache, however a small bug prevents it's use.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9350) JSON Facet method:"stream" configurable use of filter cache threshold

[David Smiley (JIRA)]

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

David Smiley updated SOLR-9350:
---
Attachment: SOLR_9350.patch

The bug was locally declaring a variable by the same name as a field.  This 
issue might be considered a bug, or improvement since the API works but not it 
works better :-)

> JSON Facet method:"stream" configurable use of filter cache threshold
> -
>
> Key: SOLR-9350
> URL: https://issues.apache.org/jira/browse/SOLR-9350
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_9350.patch
>
>
> When using method:"stream" in the JSON facet API, the code will currently 
> always use the filter cache for each value.  This basically blows out the 
> filter cache.  The code has smarts to pick a doc count threshold to use the 
> filter cache, however a small bug prevents it's use.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9350) JSON Facet method:"stream" configurable use of filter cache threshold

[David Smiley (JIRA)]

David Smiley created SOLR-9350:
--

 Summary: JSON Facet method:"stream" configurable use of filter 
cache threshold
 Key: SOLR-9350
 URL: https://issues.apache.org/jira/browse/SOLR-9350
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Facet Module
Reporter: David Smiley
Assignee: David Smiley


When using method:"stream" in the JSON facet API, the code will currently 
always use the filter cache for each value.  This basically blows out the 
filter cache.  The code has smarts to pick a doc count threshold to use the 
filter cache, however a small bug prevents it's use.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9326) Ability to create/delete/list snapshots for a solr collection

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9326:


[~dsmiley] Thanks for the feedback. I think that make sense. I just thought 
having sub-tasks would help us to organize the work appropriately. But JIRA 
linking can also work.

BTW I have implemented the collection level snapshots functionality. I have 
pushed a private branch here,
https://github.com/hgadre/lucene-solr/commit/a0ffa0afa6b88fb4aa4ccf4d7b9c7a2ebd17

Once you commit the changes for SOLR-9269, I will rebase and submit the pull 
request. 

> Ability to create/delete/list snapshots for a solr collection
> -
>
> Key: SOLR-9326
> URL: https://issues.apache.org/jira/browse/SOLR-9326
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+127) - Build # 17388 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17388/
Java: 32bit/jdk-9-ea+127 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:41805/solr/testSolrCloudCollection_shard1_replica2

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
occured when talking to server at: 
http://127.0.0.1:41805/solr/testSolrCloudCollection_shard1_replica2
at 
__randomizedtesting.SeedInfo.seed([C4AC21BD7D73278D:F9748F91459D79FD]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (SOLR-8645) New UI is not HTML Encoding XML

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch updated SOLR-8645:

Assignee: Upayavira  (was: Alexandre Rafalovitch)

> New UI is not HTML Encoding XML
> ---
>
> Key: SOLR-8645
> URL: https://issues.apache.org/jira/browse/SOLR-8645
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 5.4.1
>Reporter: David Johnson
>Assignee: Upayavira
>Priority: Minor
>
> When viewing the Zookeeper configuration, the managed-schema file is 
> displayed without HTML encoding. This results in only the inner text of the 
> configuration elements being displayed, rather than the full XML structure.  
> This only applies to the New UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8379) New admin UI, .txt files don't show in RHS of Cloud/Tree screen

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch updated SOLR-8379:

Assignee: Upayavira

> New admin UI, .txt files don't show in RHS of Cloud/Tree screen
> ---
>
> Key: SOLR-8379
> URL: https://issues.apache.org/jira/browse/SOLR-8379
> Project: Solr
>  Issue Type: Improvement
>  Components: UI
>Affects Versions: 5.4, 6.0
>Reporter: Erick Erickson
>Assignee: Upayavira
>Priority: Minor
>
> In the new admin UI, clicking on the "files" link 
> (cloud>>tree>>configs>>some_config_set) and then randomly clicking on files 
> doesn't always show the text of the file. Sometimes it does, sometimes it is 
> just blank and sometimes it's the previous file.
> An awful lot of space is eaten up by the info on top like "aversion", "ctime" 
> and the like, is this useful? Or could it be shrunk?
> Related: If I select the collection then under that the "files" link this all 
> seems to work fine. But, I cannot see my managed schema. I want to in order 
> to see the fieldTypes I have available, or more accurately the analysis 
> chains associated with them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-8645) New UI is not HTML Encoding XML

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch reassigned SOLR-8645:
---

Assignee: Alexandre Rafalovitch

> New UI is not HTML Encoding XML
> ---
>
> Key: SOLR-8645
> URL: https://issues.apache.org/jira/browse/SOLR-8645
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 5.4.1
>Reporter: David Johnson
>Assignee: Alexandre Rafalovitch
>Priority: Minor
>
> When viewing the Zookeeper configuration, the managed-schema file is 
> displayed without HTML encoding. This results in only the inner text of the 
> configuration elements being displayed, rather than the full XML structure.  
> This only applies to the New UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8911) Admin UI: solr-impl and lucene-impl versions are cut off in SNAPSHOT versions

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch updated SOLR-8911:

Assignee: Upayavira

> Admin UI: solr-impl and lucene-impl versions are cut off in SNAPSHOT versions
> -
>
> Key: SOLR-8911
> URL: https://issues.apache.org/jira/browse/SOLR-8911
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 5.5
>Reporter: Shawn Heisey
>Assignee: Upayavira
>Priority: Minor
> Attachments: solr-version-cutoff.png
>
>
> I just tried to see Solr's "compiled on" date on my dev Solr server, which is 
> running a 5.5.1-SNAPSHOT version, compiled from the branch_5_5 source.
> The "impl" strings are so long that the only thing I could tell is that it 
> was compiled this year.  I will attach a screenshot.
> It wasn't possible to see or highlight the full string.  I did manage to see 
> it all when I maximized my browser window (on a 1680x1050 screen), but I 
> really dislike running with windows maximized.  It's not like I keep the 
> windows *small* either -- the screenshot will reflect this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8596) Web UI doesn't correctly generate queries which include local parameters

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch updated SOLR-8596:

Assignee: Upayavira

> Web UI doesn't correctly generate queries which include local parameters
> 
>
> Key: SOLR-8596
> URL: https://issues.apache.org/jira/browse/SOLR-8596
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 5.4
> Environment: Windows 8.1 Pro x64
>Reporter: Ismael Teijeiro Flórez
>Assignee: Upayavira
>Priority: Minor
>  Labels: local-parameters
>
> When configuring the "Raw Query Parameters" field for a query with a value 
> like the following, the generated query is incorrect:
> {{stats=true=\{!min=true 20max=true\}MYFIELD}}
> The generated query in this case: 
> {noformat}
> http://localhost:8983/solr/mycollection/select?indent=on=*:*=0=\{!min=true=json
> {noformat}
> As you can see, the following fragment is incorrect: {{stats.field=\{!min}}.
> This is the obtained response:
> {noformat}
> {
>   "responseHeader":{
> "status":400,
> "QTime":0,
> "params":{
>   "indent":"on",
>   "stats.field":"{!min",
>   "stats":"true",
>   "q":"*:*",
>   "_":"1453742574279",
>   "wt":"json",
>   "rows":"0"}},
>   "error":{
> "msg":"Unable to parse stats.field: {!min due to: Expected identifier at 
> pos 5 str='{!min'",
> "code":400}}
> {noformat}
> If the following URL is pasted directly in the browser, the query works as 
> expected:
> {noformat}
> http://localhost:8983/solr/mycollection/select?indent=on=*:*=0={!min=true
>  max=true}MYFIELD=true=json
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (LUCENE-7397) Inefficient FVhighlighting when set many HighlightedField.

[donghyun Kim (JIRA)]

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

donghyun Kim edited comment on LUCENE-7397 at 7/28/16 2:41 AM:
---

I think it's better to reuse read termVector when each document x many 
highlight field search.

eg) 
1. each document indexed as many fields.
2. search for document.
3. I want get highlight fragments for many docs each. 
for each doc that searched
for each field that I want to get highlight fragment
4. I may call [getBestFragments] method that takes IndexReader, docId.
5. execute [final Fields vectors = reader.getTermVectors(docId);]. and 
I think It's possibly slow depends on size of termVector
 
we may support read termvector once per doc highlight process outer elsewhere 
and pass (Fields Object) as param I think.
overloading the method possibly can solve my problem.

my scenario is :
for each doc that searched
execute [final Fields vectors = reader.getTermVectors(docId);]. and I think 
It's possibly slow depends on size of 
for each field that I want to get highlight fragment
  I may call [getBestFragments] method that takes IndexReader, docId, 
(Fields vectors).

Any reason to reader.getTermVectors(docId) must located inside each 
getBestFragment?



was (Author: dohykim):
I think it's better to reuse read termVector when each document x many 
highlight field search.

eg) 
1. each document indexed as many fields.
2. search for document.
3. I want get highlight fragments for many docs each. 
for each doc that searched
for each field that I want to get highlight fragment
4. I may call [getBestFragments] method that takes IndexReader, docId.
5. execute [final Fields vectors = reader.getTermVectors(docId);]. and 
I think It's possibly slow depends on size of termVector
 
we may read termvector once per doc highlight process outer elsewhere and pass 
(Fields Object) as param I think.
overloading the method possibly can solve my problem.

my scenario is :
for each doc that searched
execute [final Fields vectors = reader.getTermVectors(docId);]. and I think 
It's possibly slow depends on size of 
for each field that I want to get highlight fragment
  I may call [getBestFragments] method that takes IndexReader, docId, 
(Fields vectors).

Any reason to reader.getTermVectors(docId) must located inside each 
getBestFragment?


> Inefficient FVhighlighting when set many HighlightedField.
> --
>
> Key: LUCENE-7397
> URL: https://issues.apache.org/jira/browse/LUCENE-7397
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
> Environment: CentOS release 6.4 (Final)
> quad core 1.87
> 8gb memory
> tested Elasticsearch - 1.5 with lucene 4.10.4 
> But i see mirrored Master version in github 
> https://github.com/apache/lucene-solr
>Reporter: donghyun Kim
>Priority: Minor
>
> when highlighting, search result 
> org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.java
> getBestFragment method ~ FieldTermStack.java read whole doc's termvector 
> every highlighted field.
> It causes slow query when many highlight field



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (LUCENE-7397) Inefficient FVhighlighting when set many HighlightedField.

[donghyun Kim (JIRA)]

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

donghyun Kim edited comment on LUCENE-7397 at 7/28/16 2:41 AM:
---

I think it's better to reuse read termVector when each document x many 
highlight field search.

eg) 
1. each document indexed as many fields.
2. search for document.
3. I want get highlight fragments for many docs each. 
for each doc that searched
for each field that I want to get highlight fragment
4. I may call [getBestFragments] method that takes IndexReader, docId.
5. execute [final Fields vectors = reader.getTermVectors(docId);]. and 
I think It's possibly slow depends on size of termVector
 
we may support read termvector once per doc highlight process outer elsewhere 
and pass (Fields Object) as param I think.
overloading the method possibly can solve my problem.

my scenario is :
for each doc that searched
execute [final Fields vectors = reader.getTermVectors(docId);].
for each field that I want to get highlight fragment
  I may call [getBestFragments] method that takes IndexReader, docId, 
(Fields vectors).

Any reason to reader.getTermVectors(docId) must located inside each 
getBestFragment?



was (Author: dohykim):
I think it's better to reuse read termVector when each document x many 
highlight field search.

eg) 
1. each document indexed as many fields.
2. search for document.
3. I want get highlight fragments for many docs each. 
for each doc that searched
for each field that I want to get highlight fragment
4. I may call [getBestFragments] method that takes IndexReader, docId.
5. execute [final Fields vectors = reader.getTermVectors(docId);]. and 
I think It's possibly slow depends on size of termVector
 
we may support read termvector once per doc highlight process outer elsewhere 
and pass (Fields Object) as param I think.
overloading the method possibly can solve my problem.

my scenario is :
for each doc that searched
execute [final Fields vectors = reader.getTermVectors(docId);]. and I think 
It's possibly slow depends on size of 
for each field that I want to get highlight fragment
  I may call [getBestFragments] method that takes IndexReader, docId, 
(Fields vectors).

Any reason to reader.getTermVectors(docId) must located inside each 
getBestFragment?


> Inefficient FVhighlighting when set many HighlightedField.
> --
>
> Key: LUCENE-7397
> URL: https://issues.apache.org/jira/browse/LUCENE-7397
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
> Environment: CentOS release 6.4 (Final)
> quad core 1.87
> 8gb memory
> tested Elasticsearch - 1.5 with lucene 4.10.4 
> But i see mirrored Master version in github 
> https://github.com/apache/lucene-solr
>Reporter: donghyun Kim
>Priority: Minor
>
> when highlighting, search result 
> org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.java
> getBestFragment method ~ FieldTermStack.java read whole doc's termvector 
> every highlighted field.
> It causes slow query when many highlight field



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8379) New admin UI, .txt files don't show in RHS of Cloud/Tree screen

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8379:
--

GitHub user arafalov opened a pull request:

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

SOLR-8379: Text file extension is 'txt'

The do-not-highlight comparison was expecting type to be text, but it is 
based on extension, so was actually 'txt'. This was causing a stack trace and 
aborted population of the content box.

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

$ git pull https://github.com/arafalov/lucene-solr-contributions 
alex-SOLR-8379

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

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


commit 8fa73cd6383b3db48d91dd792e756f0471bd0358
Author: Alexandre Rafalovitch 
Date:   2016-07-28T02:35:28Z

SOLR-8379: Text file extension is 'txt'




> New admin UI, .txt files don't show in RHS of Cloud/Tree screen
> ---
>
> Key: SOLR-8379
> URL: https://issues.apache.org/jira/browse/SOLR-8379
> Project: Solr
>  Issue Type: Improvement
>  Components: UI
>Affects Versions: 5.4, 6.0
>Reporter: Erick Erickson
>Priority: Minor
>
> In the new admin UI, clicking on the "files" link 
> (cloud>>tree>>configs>>some_config_set) and then randomly clicking on files 
> doesn't always show the text of the file. Sometimes it does, sometimes it is 
> just blank and sometimes it's the previous file.
> An awful lot of space is eaten up by the info on top like "aversion", "ctime" 
> and the like, is this useful? Or could it be shrunk?
> Related: If I select the collection then under that the "files" link this all 
> seems to work fine. But, I cannot see my managed schema. I want to in order 
> to see the fieldTypes I have available, or more accurately the analysis 
> chains associated with them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7397) Inefficient FVhighlighting when set many HighlightedField.

[donghyun Kim (JIRA)]

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

donghyun Kim commented on LUCENE-7397:
--

I think it's better to reuse read termVector when each document x many 
highlight field search.

eg) 
1. each document indexed as many fields.
2. search for document.
3. I want get highlight fragments for many docs each. 
for each doc that searched
for each field that I want to get highlight fragment
4. I may call [getBestFragments] method that takes IndexReader, docId.
5. execute [final Fields vectors = reader.getTermVectors(docId);]. and 
I think It's possibly slow depends on size of termVector
 
we may read termvector once per doc highlight process outer elsewhere and pass 
(Fields Object) as param I think.
overloading the method possibly can solve my problem.

my scenario is :
for each doc that searched
execute [final Fields vectors = reader.getTermVectors(docId);]. and I think 
It's possibly slow depends on size of 
for each field that I want to get highlight fragment
  I may call [getBestFragments] method that takes IndexReader, docId, 
(Fields vectors).

Any reason to reader.getTermVectors(docId) must located inside each 
getBestFragment?


> Inefficient FVhighlighting when set many HighlightedField.
> --
>
> Key: LUCENE-7397
> URL: https://issues.apache.org/jira/browse/LUCENE-7397
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
> Environment: CentOS release 6.4 (Final)
> quad core 1.87
> 8gb memory
> tested Elasticsearch - 1.5 with lucene 4.10.4 
> But i see mirrored Master version in github 
> https://github.com/apache/lucene-solr
>Reporter: donghyun Kim
>Priority: Minor
>
> when highlighting, search result 
> org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.java
> getBestFragment method ~ FieldTermStack.java read whole doc's termvector 
> every highlighted field.
> It causes slow query when many highlight field



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request #58: SOLR-8379: Text file extension is 'txt'

[arafalov]

GitHub user arafalov opened a pull request:

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

SOLR-8379: Text file extension is 'txt'

The do-not-highlight comparison was expecting type to be text, but it is 
based on extension, so was actually 'txt'. This was causing a stack trace and 
aborted population of the content box.

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

$ git pull https://github.com/arafalov/lucene-solr-contributions 
alex-SOLR-8379

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

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


commit 8fa73cd6383b3db48d91dd792e756f0471bd0358
Author: Alexandre Rafalovitch 
Date:   2016-07-28T02:35:28Z

SOLR-8379: Text file extension is 'txt'




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (SOLR-8379) New admin UI, .txt files don't show in RHS of Cloud/Tree screen

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8379:
-

Exception (in Firefox tools):

{code}
Error: y is undefined
p@http://localhost:8983/solr/libs/highlight.js:31:1
f@http://localhost:8983/solr/libs/highlight.js:31:2547
d@http://localhost:8983/solr/libs/highlight.js:31:3865
@http://localhost:8983/solr/js/angular/app.js:151:47
$parseFilter@http://localhost:8983/solr/libs/angular.js:12165:16
$parseFilter@http://localhost:8983/solr/libs/angular.js:12156:19
regularInterceptedExpression@http://localhost:8983/solr/libs/angular.js:12855:21
expressionInputsWatch@http://localhost:8983/solr/libs/angular.js:12783:24
$RootScopeProvider/this.$gethttp://localhost:8983/solr/libs/angular.js:14240:34
$RootScopeProvider/this.$gethttp://localhost:8983/solr/libs/angular.js:14511:13
done@http://localhost:8983/solr/libs/angular.js:9669:36
completeRequest@http://localhost:8983/solr/libs/angular.js:9859:7
requestLoaded@http://localhost:8983/solr/libs/angular.js:9800:9
{code}

> New admin UI, .txt files don't show in RHS of Cloud/Tree screen
> ---
>
> Key: SOLR-8379
> URL: https://issues.apache.org/jira/browse/SOLR-8379
> Project: Solr
>  Issue Type: Improvement
>  Components: UI
>Affects Versions: 5.4, 6.0
>Reporter: Erick Erickson
>Priority: Minor
>
> In the new admin UI, clicking on the "files" link 
> (cloud>>tree>>configs>>some_config_set) and then randomly clicking on files 
> doesn't always show the text of the file. Sometimes it does, sometimes it is 
> just blank and sometimes it's the previous file.
> An awful lot of space is eaten up by the info on top like "aversion", "ctime" 
> and the like, is this useful? Or could it be shrunk?
> Related: If I select the collection then under that the "files" link this all 
> seems to work fine. But, I cannot see my managed schema. I want to in order 
> to see the fieldTypes I have available, or more accurately the analysis 
> chains associated with them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9310:
-

bq.  am wondering why REPLAY flag is treated differently than PEER_SYNC

REPLAY updates are not written to update log because that would be redundant. 
The update log itself is the source of the updates being replayed. PEER_SYNC 
updates come from a different node and they certainly weren't present in the 
local update log already (or else we would not have requested them). This is 
why they must be written to the tlog.

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9252) Feature selection and logistic regression on text

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-9252:


+1, that's make sense!

> Feature selection and logistic regression on text
> -
>
> Key: SOLR-9252
> URL: https://issues.apache.org/jira/browse/SOLR-9252
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Joel Bernstein
> Attachments: SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, enron1.zip
>
>
> SOLR-9186 come up with a challenges that for each iterative we have to 
> rebuild the tf-idf vector for each documents. It is costly computation if we 
> represent doc by a lot of terms. Features selection can help reducing the 
> computation.
> Due to its computational efficiency and simple interpretation, information 
> gain is one of the most popular feature selection methods. It is used to 
> measure the dependence between features and labels and calculates the 
> information gain between the i-th feature and the class labels 
> (http://www.jiliang.xyz/publication/feature_selection_for_classification.pdf).
> I confirmed that by running logistics regressions on enron mail dataset (in 
> which each email is represented by top 100 terms that have highest 
> information gain) and got the accuracy by 92% and precision by 82%.
> This ticket will create two new streaming expression. Both of them use the 
> same *parallel iterative framework* as SOLR-8492.
> {code}
> featuresSelection(collection1, q="*:*",  field="tv_text", outcome="out_i", 
> positiveLabel=1, numTerms=100)
> {code}
> featuresSelection will emit top terms that have highest information gain 
> scores. It can be combined with new tlogit stream.
> {code}
> tlogit(collection1, q="*:*",
>  featuresSelection(collection1, 
>   q="*:*",  
>   field="tv_text", 
>   outcome="out_i", 
>   positiveLabel=1, 
>   numTerms=100),
>  field="tv_text",
>  outcome="out_i",
>  maxIterations=100)
> {code}
> In the iteration n, the text logistics regression will emit nth model, and 
> compute the error of (n-1)th model. Because the error will be wrong if we 
> compute the error dynamically in each iteration. 
> In each iteration tlogit will change learning rate based on error of previous 
> iteration. It will increase the learning rate by 5% if error is going down 
> and It will decrease the learning rate by 50% if error is going up.
> This will support use cases such as building models for spam detection, 
> sentiment analysis and threat detection. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8379) New admin UI, files don't always show in RHS of screen

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8379:
-

Ok, I tracked it down. It happens with .txt files which throws a Javascript 
exception and screen does not update.

> New admin UI, files don't always show in RHS of screen
> --
>
> Key: SOLR-8379
> URL: https://issues.apache.org/jira/browse/SOLR-8379
> Project: Solr
>  Issue Type: Improvement
>  Components: UI
>Affects Versions: 5.4, 6.0
>Reporter: Erick Erickson
>Priority: Minor
>
> In the new admin UI, clicking on the "files" link 
> (cloud>>tree>>configs>>some_config_set) and then randomly clicking on files 
> doesn't always show the text of the file. Sometimes it does, sometimes it is 
> just blank and sometimes it's the previous file.
> An awful lot of space is eaten up by the info on top like "aversion", "ctime" 
> and the like, is this useful? Or could it be shrunk?
> Related: If I select the collection then under that the "files" link this all 
> seems to work fine. But, I cannot see my managed schema. I want to in order 
> to see the fieldTypes I have available, or more accurately the analysis 
> chains associated with them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8379) New admin UI, .txt files don't show in RHS of Cloud/Tree screen

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch updated SOLR-8379:

Summary: New admin UI, .txt files don't show in RHS of Cloud/Tree screen  
(was: New admin UI, files don't always show in RHS of screen)

> New admin UI, .txt files don't show in RHS of Cloud/Tree screen
> ---
>
> Key: SOLR-8379
> URL: https://issues.apache.org/jira/browse/SOLR-8379
> Project: Solr
>  Issue Type: Improvement
>  Components: UI
>Affects Versions: 5.4, 6.0
>Reporter: Erick Erickson
>Priority: Minor
>
> In the new admin UI, clicking on the "files" link 
> (cloud>>tree>>configs>>some_config_set) and then randomly clicking on files 
> doesn't always show the text of the file. Sometimes it does, sometimes it is 
> just blank and sometimes it's the previous file.
> An awful lot of space is eaten up by the info on top like "aversion", "ctime" 
> and the like, is this useful? Or could it be shrunk?
> Related: If I select the collection then under that the "files" link this all 
> seems to work fine. But, I cannot see my managed schema. I want to in order 
> to see the fieldTypes I have available, or more accurately the analysis 
> chains associated with them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+127) - Build # 1293 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1293/
Java: 64bit/jdk-9-ea+127 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
document count mismatch.  control=465 sum(shards)=464 cloudClient=464

Stack Trace:
java.lang.AssertionError: document count mismatch.  control=465 sum(shards)=464 
cloudClient=464
at 
__randomizedtesting.SeedInfo.seed([2926189CCB107DB4:A172274665EC104C]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1323)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:228)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Comment Edited] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Pushkar Raste (JIRA)]

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

Pushkar Raste edited comment on SOLR-9310 at 7/28/16 2:09 AM:
--

[~noble.paul] -  Patch looks good. Can you please provide info about my 
question for {{PEER_SYNC}} vs {{REPLAY}} flag. 

are there any downsides of the way I was doing it?

Only problem I could think of your approach is we are requesting updates twice, 
which in my case is asking for tens of thousands of updates, which could be lot 
of chatter of the wire.


was (Author: praste):
[~noble.paul] -  Patch looks good. Can you please provide info about my 
question for {{PEER_SYNC}} vs {{REPLAY}} flag. 

are there any downsides of the way I was doing it?

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8645) New UI is not HTML Encoding XML

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8645:
--

GitHub user arafalov opened a pull request:

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

SOLR-8645: managed-schema is XML type

Cover the special case of no-extension known-name file. 
It was already done in the Files view, but missed in the Cloud/Tree one.

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

$ git pull https://github.com/arafalov/lucene-solr-contributions 
alex-SOLR-8645

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

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


commit 77ddaa25d9dabe25d0b36a145b603f94eb8889ab
Author: Alexandre Rafalovitch 
Date:   2016-07-28T01:41:06Z

SOLR-8645: managed-schema is XML type
Cover the special case of no-extension known-name




> New UI is not HTML Encoding XML
> ---
>
> Key: SOLR-8645
> URL: https://issues.apache.org/jira/browse/SOLR-8645
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 5.4.1
>Reporter: David Johnson
>Priority: Minor
>
> When viewing the Zookeeper configuration, the managed-schema file is 
> displayed without HTML encoding. This results in only the inner text of the 
> configuration elements being displayed, rather than the full XML structure.  
> This only applies to the New UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request #57: SOLR-8645: managed-schema is XML type

[arafalov]

GitHub user arafalov opened a pull request:

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

SOLR-8645: managed-schema is XML type

Cover the special case of no-extension known-name file. 
It was already done in the Files view, but missed in the Cloud/Tree one.

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

$ git pull https://github.com/arafalov/lucene-solr-contributions 
alex-SOLR-8645

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

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


commit 77ddaa25d9dabe25d0b36a145b603f94eb8889ab
Author: Alexandre Rafalovitch 
Date:   2016-07-28T01:41:06Z

SOLR-8645: managed-schema is XML type
Cover the special case of no-extension known-name




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (SOLR-8645) New UI is not HTML Encoding XML

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8645:
-

I see this (in master too). Actually, it seems that if you click on another XML 
file in that view first and then click on managed-schema, it works. So, there 
is a workaround for now, but also it is clear that the missing part is 
name->type mapping somehow.

> New UI is not HTML Encoding XML
> ---
>
> Key: SOLR-8645
> URL: https://issues.apache.org/jira/browse/SOLR-8645
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 5.4.1
>Reporter: David Johnson
>Priority: Minor
>
> When viewing the Zookeeper configuration, the managed-schema file is 
> displayed without HTML encoding. This results in only the inner text of the 
> configuration elements being displayed, rather than the full XML structure.  
> This only applies to the New UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Lance Norskog (JIRA)]

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

Lance Norskog commented on LUCENE-2899:
---

It's really cool to see someone with clout pick this up & modernize it.

Cheers,

Lance Norskog

> 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: Grant Ingersoll
>Priority: Minor
> Fix For: 4.9, 6.0
>
> 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, 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.3.4#6332)

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_92) - Build # 6009 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6009/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [InternalHttpClient]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [InternalHttpClient]
at __randomizedtesting.SeedInfo.seed([F0789ECE7F5D2663]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11465 lines...]
   [junit4] Suite: org.apache.solr.cloud.CdcrVersionReplicationTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.CdcrVersionReplicationTest_F0789ECE7F5D2663-001\init-core-data-001
   [junit4]   2> 1440654 INFO  
(SUITE-CdcrVersionReplicationTest-seed#[F0789ECE7F5D2663]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 1440654 INFO  
(SUITE-CdcrVersionReplicationTest-seed#[F0789ECE7F5D2663]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /_tmg/u
   [junit4]   2> 1440657 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[F0789ECE7F5D2663]) [ 
   ] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1440657 INFO  (Thread-2471) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1440657 INFO  (Thread-2471) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1440757 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[F0789ECE7F5D2663]) [ 
   ] o.a.s.c.ZkTestServer start zk server on port:50521
   [junit4]   2> 1440757 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[F0789ECE7F5D2663]) [ 
   ] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1440760 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[F0789ECE7F5D2663]) [ 
   ] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1440765 INFO  (zkCallback-9843-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@66bfc102 
name:ZooKeeperConnection Watcher:127.0.0.1:50521 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   

[JENKINS-MAVEN] Lucene-Solr-Maven-6.x #119: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-6.x/119/

No tests ran.

Build Log:
[...truncated 29023 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/build.xml:781: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/build.xml:322: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/build.xml:420: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/common-build.xml:2177:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/common-build.xml:1690:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/common-build.xml:566:
 Error deploying artifact 'org.apache.lucene:lucene-codecs:jar': Error 
deploying artifact: Failed to transfer file: 
https://repository.apache.org/content/repositories/snapshots/org/apache/lucene/lucene-codecs/6.2.0-SNAPSHOT/lucene-codecs-6.2.0-20160727.232505-31-javadoc.jar.
 Return code is: 502

Total time: 11 minutes 51 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1080 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1080/

8 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrReplicationDistributedZkTest

Error Message:
ObjectTracker found 48 object(s) that were not released!!! [InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 48 object(s) that were not 
released!!! [InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient]
at __randomizedtesting.SeedInfo.seed([D49A41D6CF147AB1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrReplicationDistributedZkTest

Error Message:

[jira] [Updated] (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 updated LUCENE-2899:
---
Attachment: LUCENE-2899.patch

Patch, only changes are fixes to the opennlp overview javadocs:
* refer to {{TypeAttribute}} instead of payloads
* remove mention of {{FilterPayloadTokenFilter}} and {{StripPayloadsFilter}}
* recommend {{TypeAsPayloadFilter}} and {{TypeAsSynonymFilter}} to make tags 
searchable

> 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: Grant Ingersoll
>Priority: Minor
> Fix For: 4.9, 6.0
>
> 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, 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.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9252) Feature selection and logistic regression on text

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-9252 at 7/27/16 9:46 PM:
---

Ok, here is my thinking with *train* versus *tlogit*

The *train* function would initially map directly to the TextLogitStream. We 
can document that *train* is a text logistic regression model trainer in the 
first release.

As we add more algorithms the *train* function will map to the *TrainStream*. 
The TrainStream won't have any implementations, it will simply be a facade for 
different training algorithms. The TrainStream will have a parameter called 
*algorithm* which it will use to select the stream implementation, such as 
TextLogitStream. The underlying implementation will handle the parameters, all 
the TrainStream will do is instantiate the alogrithm and run it.

Sample syntax:
{code}
train(collection, 
  features(...), 
  algorithm="tlogit", 
  q="*:*", )
{code}

We can use the same facade approach for the *classify* and *features* function. 

The documentation can provide documentation for calling *train* with different 
algorithms. 

I like this approach because it provides three very easy to understand 
functions: train, classify and features

It also stops the explosion of functions that would occur when we have multiple 
classify, train and features algorithms.


 









was (Author: joel.bernstein):
Ok, here is my thinking with *train* versus *tlogit*

The *train* function would initially map directly to the TextLogitStream. We 
can document that *train* is a text logistic regression model trainer in the 
first release.

As we add more algorithms the *train* function will map to the *TrainStream*. 
The TrainStream won't have any implementations, it will simply be a facade for 
different training algorithms. The TrainStream will have a parameter called 
*algorithm* which it will use to select the stream implementation, such as 
TextLogitStream. The underlying implementation will handle the parameters, all 
the TrainStream will do is instantiate the alogrithm and run it.

Sample syntax:
{code}
train(collection, 
  features(...), 
  algorithm="tlogit", 
  q="*:*", )
{code}

We can use the same facade approach for the *classify* and *features* function. 

The documentation can provide provide documentation for calling *train* with 
the different algorithms. 

I like this approach because it provides three very easy to understand 
functions: train, classify and features

It also stops the explosion of functions that would occur when we have multiple 
classify, train and features algorithms.


 








> Feature selection and logistic regression on text
> -
>
> Key: SOLR-9252
> URL: https://issues.apache.org/jira/browse/SOLR-9252
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Joel Bernstein
> Attachments: SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, enron1.zip
>
>
> SOLR-9186 come up with a challenges that for each iterative we have to 
> rebuild the tf-idf vector for each documents. It is costly computation if we 
> represent doc by a lot of terms. Features selection can help reducing the 
> computation.
> Due to its computational efficiency and simple interpretation, information 
> gain is one of the most popular feature selection methods. It is used to 
> measure the dependence between features and labels and calculates the 
> information gain between the i-th feature and the class labels 
> (http://www.jiliang.xyz/publication/feature_selection_for_classification.pdf).
> I confirmed that by running logistics regressions on enron mail dataset (in 
> which each email is represented by top 100 terms that have highest 
> information gain) and got the accuracy by 92% and precision by 82%.
> This ticket will create two new streaming expression. Both of them use the 
> same *parallel iterative framework* as SOLR-8492.
> {code}
> featuresSelection(collection1, q="*:*",  field="tv_text", outcome="out_i", 
> positiveLabel=1, numTerms=100)
> {code}
> featuresSelection will emit top terms that have highest information gain 
> scores. It can be combined with new tlogit stream.
> {code}
> tlogit(collection1, q="*:*",
>  featuresSelection(collection1, 
>   q="*:*",  
>   field="tv_text", 
>   outcome="out_i", 
>   positiveLabel=1, 
>   numTerms=100),
>  field="tv_text",
>  

[jira] [Comment Edited] (SOLR-9252) Feature selection and logistic regression on text

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-9252 at 7/27/16 9:45 PM:
---

Ok, here is my thinking with *train* versus *tlogit*

The *train* function would initially map directly to the TextLogitStream. We 
can document that *train* is a text logistic regression model trainer in the 
first release.

As we add more algorithms the *train* function will map to the *TrainStream*. 
The TrainStream won't have any implementations, it will simply be a facade for 
different training algorithms. The TrainStream will have a parameter called 
*algorithm* which it will use to select the stream implementation, such as 
TextLogitStream. The underlying implementation will handle the parameters, all 
the TrainStream will do is instantiate the alogrithm and run it.

Sample syntax:
{code}
train(collection, 
  features(...), 
  algorithm="tlogit", 
  q="*:*", )
{code}

We can use the same facade approach for the *classify* and *features* function. 

The documentation can provide provide documentation for calling *train* with 
the different algorithms. 

I like this approach because it provides three very easy to understand 
functions: train, classify and features

It also stops the explosion of functions that would occur when we have multiple 
classify, train and features algorithms.


 









was (Author: joel.bernstein):
Ok, here is my thinking with *train* versus *tlogit*

The *train* function will initially map directly to the TextLogitStream. We can 
document that *train* is a text logistic regression model trainer in the first 
release.

As we add more algorithms the *train* function will map to the *TrainStream*. 
The TrainStream won't have any implementations, it will simply be a facade for 
different training algorithms. The TrainStream will have a parameter called 
*algorithm* which it will use to select the stream implementation, such as 
TextLogitStream. The underlying implementation will handle the parameters, all 
the TrainStream will do is instantiate the alogrithm and run it.

Sample syntax:
{code}
train(collection, 
  features(...), 
  algorithm="tlogit", 
  q="*:*", )
{code}

We can use the same facade approach for the *classify* and *features* function. 

The documentation can provide provide documentation for calling *train* with 
the different algorithms. 

I like this approach because it provides three very easy to understand 
functions: train, classify and features

It also stops the explosion of functions that would occur when we have multiple 
classify, train and features algorithms.


 








> Feature selection and logistic regression on text
> -
>
> Key: SOLR-9252
> URL: https://issues.apache.org/jira/browse/SOLR-9252
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Joel Bernstein
> Attachments: SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, enron1.zip
>
>
> SOLR-9186 come up with a challenges that for each iterative we have to 
> rebuild the tf-idf vector for each documents. It is costly computation if we 
> represent doc by a lot of terms. Features selection can help reducing the 
> computation.
> Due to its computational efficiency and simple interpretation, information 
> gain is one of the most popular feature selection methods. It is used to 
> measure the dependence between features and labels and calculates the 
> information gain between the i-th feature and the class labels 
> (http://www.jiliang.xyz/publication/feature_selection_for_classification.pdf).
> I confirmed that by running logistics regressions on enron mail dataset (in 
> which each email is represented by top 100 terms that have highest 
> information gain) and got the accuracy by 92% and precision by 82%.
> This ticket will create two new streaming expression. Both of them use the 
> same *parallel iterative framework* as SOLR-8492.
> {code}
> featuresSelection(collection1, q="*:*",  field="tv_text", outcome="out_i", 
> positiveLabel=1, numTerms=100)
> {code}
> featuresSelection will emit top terms that have highest information gain 
> scores. It can be combined with new tlogit stream.
> {code}
> tlogit(collection1, q="*:*",
>  featuresSelection(collection1, 
>   q="*:*",  
>   field="tv_text", 
>   outcome="out_i", 
>   positiveLabel=1, 
>   numTerms=100),
>  field="tv_text",
>

[jira] [Comment Edited] (SOLR-9252) Feature selection and logistic regression on text

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-9252 at 7/27/16 9:44 PM:
---

Ok, here is my thinking with *train* versus *tlogit*

The *train* function will initially map directly to the TextLogitStream. We can 
document that *train* is a text logistic regression model trainer in the first 
release.

As we add more algorithms the *train* function will map to the *TrainStream*. 
The TrainStream won't have any implementations, it will simply be a facade for 
different training algorithms. The TrainStream will have a parameter called 
*algorithm* which it will use to select the stream implementation, such as 
TextLogitStream. The underlying implementation will handle the parameters, all 
the TrainStream will do is instantiate the alogrithm and run it.

Sample syntax:
{code}
train(collection, 
  features(...), 
  algorithm="tlogit", 
  q="*:*", )
{code}

We can use the same facade approach for the *classify* and *features* function. 

The documentation can provide provide documentation for calling *train* with 
the different algorithms. 

I like this approach because it provides three very easy to understand 
functions: train, classify and features

It also stops the explosion of functions that would occur when we have multiple 
classify, train and features algorithms.


 









was (Author: joel.bernstein):
Ok, here is my thinking with *train* versus *tlogit*

The *train* function will initially map directly to the TextLogitStream. We can 
document that *train* is a text logistic regression model trainer in the first 
release.

As we add more algorithms the *train* function will map to the *TrainStream*. 
The TrainStream won't have any implementations, it will simply be a facade for 
different training algorithms. The TrainStream will have a parameter called 
*algorithm* which it will use to select the stream implementation, such as 
TextLogitStream. The underlying implementation will handle the parameters, all 
the TrainStream will do is instantiate the alogrithm and run it.

Sample syntax:
{code}
train(collection, 
  features(...), 
  algorithm="tlogit", 
  q="*:*", )
{code}

We can use the same facade approach for the *classify* and *features* function. 

The documentation can provide provide documentation for calling *train* with 
the different algorithms. And what the default algorithms are.

I like this approach because it provides three very easy to understand 
functions: train, classify and features


 








> Feature selection and logistic regression on text
> -
>
> Key: SOLR-9252
> URL: https://issues.apache.org/jira/browse/SOLR-9252
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Joel Bernstein
> Attachments: SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, enron1.zip
>
>
> SOLR-9186 come up with a challenges that for each iterative we have to 
> rebuild the tf-idf vector for each documents. It is costly computation if we 
> represent doc by a lot of terms. Features selection can help reducing the 
> computation.
> Due to its computational efficiency and simple interpretation, information 
> gain is one of the most popular feature selection methods. It is used to 
> measure the dependence between features and labels and calculates the 
> information gain between the i-th feature and the class labels 
> (http://www.jiliang.xyz/publication/feature_selection_for_classification.pdf).
> I confirmed that by running logistics regressions on enron mail dataset (in 
> which each email is represented by top 100 terms that have highest 
> information gain) and got the accuracy by 92% and precision by 82%.
> This ticket will create two new streaming expression. Both of them use the 
> same *parallel iterative framework* as SOLR-8492.
> {code}
> featuresSelection(collection1, q="*:*",  field="tv_text", outcome="out_i", 
> positiveLabel=1, numTerms=100)
> {code}
> featuresSelection will emit top terms that have highest information gain 
> scores. It can be combined with new tlogit stream.
> {code}
> tlogit(collection1, q="*:*",
>  featuresSelection(collection1, 
>   q="*:*",  
>   field="tv_text", 
>   outcome="out_i", 
>   positiveLabel=1, 
>   numTerms=100),
>  field="tv_text",
>  outcome="out_i",
>  maxIterations=100)
> {code}
> In the iteration n, the 

[jira] [Comment Edited] (SOLR-9252) Feature selection and logistic regression on text

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-9252 at 7/27/16 9:42 PM:
---

Ok, here is my thinking with *train* versus *tlogit*

The *train* function will initially map directly to the TextLogitStream. We can 
document that *train* is a text logistic regression model trainer in the first 
release.

As we add more algorithms the *train* function will map to the *TrainStream*. 
The TrainStream won't have any implementations, it will simply be a facade for 
different training algorithms. The TrainStream will have a parameter called 
*algorithm* which it will use to select the stream implementation, such as 
TextLogitStream. The underlying implementation will handle the parameters, all 
the TrainStream will do is instantiate the alogrithm and run it.

Sample syntax:
{code}
train(collection, 
  features(...), 
  algorithm="tlogit", 
  q="*:*", )
{code}

We can use the same facade approach for the *classify* and *features* function. 

The documentation can provide provide documentation for calling *train* with 
the different algorithms. And what the default algorithms are.

I like this approach because it provides three very easy to understand 
functions: train, classify and features


 









was (Author: joel.bernstein):
Ok, here is my thinking with *train* versus *tlogit*

The *train* function will initially map directly to the TextLogitStream. We can 
document that *train* is a text logistic regression model trainer in the first 
release.

As we add more algorithms the *train* function will map to the *TrainStream*. 
The TrainStream won't have any implementations, it will simply be a facade for 
different training algorithms. The TrainStream will have a parameter called 
*algorithm* which it will use to select the stream implementation, such as 
TextLogitStream. The underlying implementation will handle the parameters, all 
the TrainStream will do is instantiate the alogrithm and run it.

Sample syntax:
{code}
train(collection, 
   features(...), 
   algorithm="tlogit", 
   q="*:*", )
{code}

We can use the same facade approach for the *classify* and *features* function. 

The documentation can provide provide documentation for calling *train* with 
the different algorithms. And what the default algorithms are.

I like this approach because it provides three very easy to understand 
functions: train, classify and features


 








> Feature selection and logistic regression on text
> -
>
> Key: SOLR-9252
> URL: https://issues.apache.org/jira/browse/SOLR-9252
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Joel Bernstein
> Attachments: SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, enron1.zip
>
>
> SOLR-9186 come up with a challenges that for each iterative we have to 
> rebuild the tf-idf vector for each documents. It is costly computation if we 
> represent doc by a lot of terms. Features selection can help reducing the 
> computation.
> Due to its computational efficiency and simple interpretation, information 
> gain is one of the most popular feature selection methods. It is used to 
> measure the dependence between features and labels and calculates the 
> information gain between the i-th feature and the class labels 
> (http://www.jiliang.xyz/publication/feature_selection_for_classification.pdf).
> I confirmed that by running logistics regressions on enron mail dataset (in 
> which each email is represented by top 100 terms that have highest 
> information gain) and got the accuracy by 92% and precision by 82%.
> This ticket will create two new streaming expression. Both of them use the 
> same *parallel iterative framework* as SOLR-8492.
> {code}
> featuresSelection(collection1, q="*:*",  field="tv_text", outcome="out_i", 
> positiveLabel=1, numTerms=100)
> {code}
> featuresSelection will emit top terms that have highest information gain 
> scores. It can be combined with new tlogit stream.
> {code}
> tlogit(collection1, q="*:*",
>  featuresSelection(collection1, 
>   q="*:*",  
>   field="tv_text", 
>   outcome="out_i", 
>   positiveLabel=1, 
>   numTerms=100),
>  field="tv_text",
>  outcome="out_i",
>  maxIterations=100)
> {code}
> In the iteration n, the text logistics regression will emit nth model, and 
> compute the error of (n-1)th 

[jira] [Comment Edited] (SOLR-9252) Feature selection and logistic regression on text

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-9252 at 7/27/16 9:42 PM:
---

Ok, here is my thinking with *train* versus *tlogit*

The *train* function will initially map directly to the TextLogitStream. We can 
document that *train* is a text logistic regression model trainer in the first 
release.

As we add more algorithms the *train* function will map to the *TrainStream*. 
The TrainStream won't have any implementations, it will simply be a facade for 
different training algorithms. The TrainStream will have a parameter called 
*algorithm* which it will use to select the stream implementation, such as 
TextLogitStream. The underlying implementation will handle the parameters, all 
the TrainStream will do is instantiate the alogrithm and run it.

Sample syntax:
{code}
train(collection, 
   features(...), 
   algorithm="tlogit", 
   q="*:*", )
{code}

We can use the same facade approach for the *classify* and *features* function. 

The documentation can provide provide documentation for calling *train* with 
the different algorithms. And what the default algorithms are.

I like this approach because it provides three very easy to understand 
functions: train, classify and features


 









was (Author: joel.bernstein):
Ok, here is my thinking with *train* versus *tlogit*

The *train* function will initially map directly to the TextLogitStream. We can 
document that *train* is a text logistic regression model trainer in the first 
release.

As we add more algorithms the *train* function will map to the *TrainStream*. 
The TrainStream won't have any implementations, it will simply be a facade for 
different training algorithms. The TrainStream will have a parameter called 
*algorithm* which it will use to select the stream implementation, such as 
TextLogitStream. The underlying implementation will handle the parameters, all 
the TrainStream will do is instantiate the alogrithm and run it.

Sample syntax:
{code}
train(collection, 
features(...), 
algorithm="tlogit", 
q="*:*", )
{code}

We can use the same facade approach for the *classify* and *features* function. 

The documentation can provide provide documentation for calling *train* with 
the different algorithms. And what the default algorithms are.

I like this approach because it provides three very easy to understand 
functions: train, classify and features


 








> Feature selection and logistic regression on text
> -
>
> Key: SOLR-9252
> URL: https://issues.apache.org/jira/browse/SOLR-9252
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Joel Bernstein
> Attachments: SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, enron1.zip
>
>
> SOLR-9186 come up with a challenges that for each iterative we have to 
> rebuild the tf-idf vector for each documents. It is costly computation if we 
> represent doc by a lot of terms. Features selection can help reducing the 
> computation.
> Due to its computational efficiency and simple interpretation, information 
> gain is one of the most popular feature selection methods. It is used to 
> measure the dependence between features and labels and calculates the 
> information gain between the i-th feature and the class labels 
> (http://www.jiliang.xyz/publication/feature_selection_for_classification.pdf).
> I confirmed that by running logistics regressions on enron mail dataset (in 
> which each email is represented by top 100 terms that have highest 
> information gain) and got the accuracy by 92% and precision by 82%.
> This ticket will create two new streaming expression. Both of them use the 
> same *parallel iterative framework* as SOLR-8492.
> {code}
> featuresSelection(collection1, q="*:*",  field="tv_text", outcome="out_i", 
> positiveLabel=1, numTerms=100)
> {code}
> featuresSelection will emit top terms that have highest information gain 
> scores. It can be combined with new tlogit stream.
> {code}
> tlogit(collection1, q="*:*",
>  featuresSelection(collection1, 
>   q="*:*",  
>   field="tv_text", 
>   outcome="out_i", 
>   positiveLabel=1, 
>   numTerms=100),
>  field="tv_text",
>  outcome="out_i",
>  maxIterations=100)
> {code}
> In the iteration n, the text logistics regression will emit nth model, and 
> compute the error of (n-1)th model. 

[jira] [Commented] (SOLR-9252) Feature selection and logistic regression on text

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9252:
--

Ok, here is my thinking with *train* versus *tlogit*

The *train* function will initially map directly to the TextLogitStream. We can 
document that *train* is a text logistic regression model trainer in the first 
release.

As we add more algorithms the *train* function will map to the *TrainStream*. 
The TrainStream won't have any implementations, it will simply be a facade for 
different training algorithms. The TrainStream will have a parameter called 
*algorithm* which it will use to select the stream implementation, such as 
TextLogitStream. The underlying implementation will handle the parameters, all 
the TrainStream will do is instantiate the alogrithm and run it.

Sample syntax:
{code}
train(collection, 
features(...), 
algorithm="tlogit", 
q="*:*", )
{code}

We can use the same facade approach for the *classify* and *features* function. 

The documentation can provide provide documentation for calling *train* with 
the different algorithms. And what the default algorithms are.

I like this approach because it provides three very easy to understand 
functions: train, classify and features


 








> Feature selection and logistic regression on text
> -
>
> Key: SOLR-9252
> URL: https://issues.apache.org/jira/browse/SOLR-9252
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Joel Bernstein
> Attachments: SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, enron1.zip
>
>
> SOLR-9186 come up with a challenges that for each iterative we have to 
> rebuild the tf-idf vector for each documents. It is costly computation if we 
> represent doc by a lot of terms. Features selection can help reducing the 
> computation.
> Due to its computational efficiency and simple interpretation, information 
> gain is one of the most popular feature selection methods. It is used to 
> measure the dependence between features and labels and calculates the 
> information gain between the i-th feature and the class labels 
> (http://www.jiliang.xyz/publication/feature_selection_for_classification.pdf).
> I confirmed that by running logistics regressions on enron mail dataset (in 
> which each email is represented by top 100 terms that have highest 
> information gain) and got the accuracy by 92% and precision by 82%.
> This ticket will create two new streaming expression. Both of them use the 
> same *parallel iterative framework* as SOLR-8492.
> {code}
> featuresSelection(collection1, q="*:*",  field="tv_text", outcome="out_i", 
> positiveLabel=1, numTerms=100)
> {code}
> featuresSelection will emit top terms that have highest information gain 
> scores. It can be combined with new tlogit stream.
> {code}
> tlogit(collection1, q="*:*",
>  featuresSelection(collection1, 
>   q="*:*",  
>   field="tv_text", 
>   outcome="out_i", 
>   positiveLabel=1, 
>   numTerms=100),
>  field="tv_text",
>  outcome="out_i",
>  maxIterations=100)
> {code}
> In the iteration n, the text logistics regression will emit nth model, and 
> compute the error of (n-1)th model. Because the error will be wrong if we 
> compute the error dynamically in each iteration. 
> In each iteration tlogit will change learning rate based on error of previous 
> iteration. It will increase the learning rate by 5% if error is going down 
> and It will decrease the learning rate by 50% if error is going up.
> This will support use cases such as building models for spam detection, 
> sentiment analysis and threat detection. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-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 updated LUCENE-2899:
---
Attachment: LUCENE-2899.patch

Attaching another WIP patch with more progress:

* Switched {{OpenNLPFilter}} to use {{TypeAttribute}} instead of 
{{PayloadAttribute}} to hold annotations from part-of-speech tagging, chunking 
and NER tagging.
* Added a new {{TypeAsSynonymFilter}} to the analyzers-common module that  adds 
a token at the same position as a (presumably previously annotated) token, with 
the value of the {{TypeAttribute}} copied into its {{CharTermAttribute}}.  See 
[~sbower]'s comment above for potential uses.
* Removed the now unnecessary {{FilterPayloadsFilter}} and 
{{StripPayloadFilter}} that were present in previous iterations of the patch.
* Added {{KeywordAttribute}} awareness to {{OpenNLPLemmatizationFilter}}, so 
that lemmatization won't be performed on tokens with {{isKeyword()==true}}.
* Fixed the new payload-aware 
{{BaseTokenStreamTestCase.assertTokenStreamContents()}} to use 
{{BytesRef.equals()}} instead of directly comparing {{byte}} arrays and not 
referencing offset
* Added {{TypeAttribute}} awareness to {{CannedTokenStream}}.

> 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: Grant Ingersoll
>Priority: Minor
> Fix For: 4.9, 6.0
>
> Attachments: LUCENE-2899-6.1.0.patch, LUCENE-2899-RJN.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.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Pushkar Raste (JIRA)]

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

Pushkar Raste edited comment on SOLR-9310 at 7/27/16 9:40 PM:
--

[~noble.paul] -  Patch looks good. Can you please provide info about my 
question for {{PEER_SYNC}} vs {{REPLAY}} flag. 

are there any downsides of the way I was doing it?


was (Author: praste):
[~noble.paul] -  Patch looks good. Can you please provide info about my 
question for {{PEER_SYNC}} vs {{REPLAY}} flag. 

are there any downsides of the way. I was doing it?

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Pushkar Raste (JIRA)]

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

Pushkar Raste commented on SOLR-9310:
-

[~noble.paul] -  Patch looks good. Can you please provide info about my 
question for {{PEER_SYNC}} vs {{REPLAY}} flag. 

are there any downsides of the way. I was doing it?

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+127) - Build # 17385 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17385/
Java: 32bit/jdk-9-ea+127 -client -XX:+UseConcMarkSweepGC

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

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:43780/s/k/c8n_1x3_lf_shard1_replica1]

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:43780/s/k/c8n_1x3_lf_shard1_replica1]
at 
__randomizedtesting.SeedInfo.seed([E218921F8BFA6E1A:6A4CADC5250603E2]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:178)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:57)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

Re: [jira] [Commented] (SOLR-9279) Add greater than, less than, etc in Solr function queries

[Doug Turnbull]

Great!

+1
On Wed, Jul 27, 2016 at 3:26 PM David Smiley (JIRA)  wrote:

>
> [
> https://issues.apache.org/jira/browse/SOLR-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15396205#comment-15396205
> ]
>
> David Smiley commented on SOLR-9279:
> 
>
> Sure -- trivial enough.  Unless there are further suggestions on this
> issue, I'll commit it with that change later this week.  I'll update Lucene
> & Solr's CHANGES.txt since both get something here.
>
> > Add greater than, less than, etc in Solr function queries
> > -
> >
> > Key: SOLR-9279
> > URL: https://issues.apache.org/jira/browse/SOLR-9279
> > Project: Solr
> >  Issue Type: New Feature
> >  Security Level: Public(Default Security Level. Issues are Public)
> >  Components: search
> >Reporter: Doug Turnbull
> > Fix For: master (7.0)
> >
> > Attachments: SOLR-9279.patch
> >
> >
> > If you use the "if" function query, you'll often expect to be able to
> use greater than/less than functions. For example, you might want to boost
> books written in the past 7 years. Unfortunately, there's no "greater than"
> function query that will return non-zero when the lhs > rhs. Instead to get
> this, you need to create really awkward function queries like I do here (
> http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/
> ):
> > if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> > The pull request attached to this Jira adds the following function
> queries
> > (https://github.com/apache/lucene-solr/pull/49)
> > -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> > -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> > -gte
> > -lte
> > -eq
> > So instead of
> > if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> > one could now write
> > if(lt(ms(mydatefield),315569259747,0.8,1)
> > (if mydatefield < 315569259747 then 0.8 else 1)
> > A bit more readable and less puzzling
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-9320) A REPLACENODE command to decommission an existing node with another new node

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-9320:


I am having issues applying this patch against master. 
I tried to take a look at this without applying the patch and the patch does 
add complexity, as Noble pointed out.

> A REPLACENODE command to decommission an existing node with another new node
> 
>
> Key: SOLR-9320
> URL: https://issues.apache.org/jira/browse/SOLR-9320
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DELETENODE.jpeg, REPLACENODE_After.jpeg, 
> REPLACENODE_Before.jpeg, REPLACENODE_call_response.jpeg, SOLR-9320.patch
>
>
> The command should accept a source node and target node. recreate the 
> replicas in source node in the target and do a DLETENODE of source node



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9279) Add greater than, less than, etc in Solr function queries

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9279:


Sure -- trivial enough.  Unless there are further suggestions on this issue, 
I'll commit it with that change later this week.  I'll update Lucene & Solr's 
CHANGES.txt since both get something here.

> Add greater than, less than, etc in Solr function queries
> -
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Doug Turnbull
> Fix For: master (7.0)
>
> Attachments: SOLR-9279.patch
>
>
> If you use the "if" function query, you'll often expect to be able to use 
> greater than/less than functions. For example, you might want to boost books 
> written in the past 7 years. Unfortunately, there's no "greater than" 
> function query that will return non-zero when the lhs > rhs. Instead to get 
> this, you need to create really awkward function queries like I do here 
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of 
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9349) Schema API should never delete fields used elsewhere in the schema

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9349:
--

[~elyograg], do you have evidence that this is a current problem?  AFAIK the 
schema API already implements what you think it should implement.

> Schema API should never delete fields used elsewhere in the schema
> --
>
> Key: SOLR-9349
> URL: https://issues.apache.org/jira/browse/SOLR-9349
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>
> The Schema API should refuse to delete a field if it can detect that the 
> deletion would cause the schema to fail to load.
> This includes the field assigned to uniqueKey, fields used as copyField 
> sources, and fields used as copyField destinations.  There may be other 
> detectable problems that haven't been listed here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9320) A REPLACENODE command to decommission an existing node with another new node

[Nitin Sharma (JIRA)]

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

Nitin Sharma commented on SOLR-9320:


This has the patch for both REPLACENODE and DELETENODE inside it. I can reduce 
the num files again and re-upload if you like. 

> A REPLACENODE command to decommission an existing node with another new node
> 
>
> Key: SOLR-9320
> URL: https://issues.apache.org/jira/browse/SOLR-9320
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DELETENODE.jpeg, REPLACENODE_After.jpeg, 
> REPLACENODE_Before.jpeg, REPLACENODE_call_response.jpeg, SOLR-9320.patch
>
>
> The command should accept a source node and target node. recreate the 
> replicas in source node in the target and do a DLETENODE of source node



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9349) Schema API should never delete fields used elsewhere in the schema

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9349:
--

So looking at {{ManagedIndexSchema.deleteFields()}} I see that copyField source 
and dest are covered, but uniqueKey is not checked.  There's a chicken and egg 
problem here though, in that (un)setting the uniqueKey is not yet covered by 
the Schema API - see SOLR-7242.

> Schema API should never delete fields used elsewhere in the schema
> --
>
> Key: SOLR-9349
> URL: https://issues.apache.org/jira/browse/SOLR-9349
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>
> The Schema API should refuse to delete a field if it can detect that the 
> deletion would cause the schema to fail to load.
> This includes the field assigned to uniqueKey, fields used as copyField 
> sources, and fields used as copyField destinations.  There may be other 
> detectable problems that haven't been listed here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9320) A REPLACENODE command to decommission an existing node with another new node

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9320:
--

If I'm not wrong you just need to add one method. This is a trivial 
functionality

> A REPLACENODE command to decommission an existing node with another new node
> 
>
> Key: SOLR-9320
> URL: https://issues.apache.org/jira/browse/SOLR-9320
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DELETENODE.jpeg, REPLACENODE_After.jpeg, 
> REPLACENODE_Before.jpeg, REPLACENODE_call_response.jpeg, SOLR-9320.patch
>
>
> The command should accept a source node and target node. recreate the 
> replicas in source node in the target and do a DLETENODE of source node



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9320) A REPLACENODE command to decommission an existing node with another new node

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9320:
--

I really didn't mean that the code was complex to understand. I meant adding so 
many files for such a simple functionality is not worth it. We generally follow 
a pattern for multiple commands. 

> A REPLACENODE command to decommission an existing node with another new node
> 
>
> Key: SOLR-9320
> URL: https://issues.apache.org/jira/browse/SOLR-9320
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DELETENODE.jpeg, REPLACENODE_After.jpeg, 
> REPLACENODE_Before.jpeg, REPLACENODE_call_response.jpeg, SOLR-9320.patch
>
>
> The command should accept a source node and target node. recreate the 
> replicas in source node in the target and do a DLETENODE of source node



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9349) Schema API should never delete fields used elsewhere in the schema

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9349:


Manually editing the schema will still allow the user to shoot themselves in 
the foot.  We might need better error messages for those problems, but that's 
an entirely different issue.


> Schema API should never delete fields used elsewhere in the schema
> --
>
> Key: SOLR-9349
> URL: https://issues.apache.org/jira/browse/SOLR-9349
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>
> The Schema API should refuse to delete a field if it can detect that the 
> deletion would cause the schema to fail to load.
> This includes the field assigned to uniqueKey, fields used as copyField 
> sources, and fields used as copyField destinations.  There may be other 
> detectable problems that haven't been listed here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7397) Inefficient FVhighlighting when set many HighlightedField.

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7397:
--

Sorry I'm not clear what specifically you propose.  

FYI, perhaps related: the Lucene default term vector implementation/codec will 
load term vectors for all fields, even if you are actually only interested in 
fewer.  It's easy to accidentally re-decode all term vectors when code asks for 
just one.  I don't know if the FVH has this problem or not.  I know the default 
highlighter can benefit from term vectors and it does not suffer from this 
potential trap.

> Inefficient FVhighlighting when set many HighlightedField.
> --
>
> Key: LUCENE-7397
> URL: https://issues.apache.org/jira/browse/LUCENE-7397
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
> Environment: CentOS release 6.4 (Final)
> quad core 1.87
> 8gb memory
> tested Elasticsearch - 1.5 with lucene 4.10.4 
> But i see mirrored Master version in github 
> https://github.com/apache/lucene-solr
>Reporter: donghyun Kim
>Priority: Minor
>
> when highlighting, search result 
> org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.java
> getBestFragment method ~ FieldTermStack.java read whole doc's termvector 
> every highlighted field.
> It causes slow query when many highlight field



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9320) A REPLACENODE command to decommission an existing node with another new node

[Nitin Sharma (JIRA)]

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

Nitin Sharma commented on SOLR-9320:


[~noble.paul] Can you explain about the complex part? The code does what was 
mentioned in the spec. It identifies all the cores on the node to be replaced 
and recreates them on the destination node. After that it calls "DELETENODE" on 
the source node. Which part of this complex? The multithreaded part?

> A REPLACENODE command to decommission an existing node with another new node
> 
>
> Key: SOLR-9320
> URL: https://issues.apache.org/jira/browse/SOLR-9320
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DELETENODE.jpeg, REPLACENODE_After.jpeg, 
> REPLACENODE_Before.jpeg, REPLACENODE_call_response.jpeg, SOLR-9320.patch
>
>
> The command should accept a source node and target node. recreate the 
> replicas in source node in the target and do a DLETENODE of source node



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-7397) Inefficient FVhighlighting when set many HighlightedField.

[David Smiley (JIRA)]

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

David Smiley updated LUCENE-7397:
-
Component/s: (was: core/search)
 modules/highlighter

> Inefficient FVhighlighting when set many HighlightedField.
> --
>
> Key: LUCENE-7397
> URL: https://issues.apache.org/jira/browse/LUCENE-7397
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
> Environment: CentOS release 6.4 (Final)
> quad core 1.87
> 8gb memory
> tested Elasticsearch - 1.5 with lucene 4.10.4 
> But i see mirrored Master version in github 
> https://github.com/apache/lucene-solr
>Reporter: donghyun Kim
>Priority: Minor
>
> when highlighting, search result 
> org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.java
> getBestFragment method ~ FieldTermStack.java read whole doc's termvector 
> every highlighted field.
> It causes slow query when many highlight field



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9349) Schema API should never delete fields used elsewhere in the schema

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9349:


There are some other problem situations that would be very difficult to detect 
-- such as deleting a field that is used for "df" or "qf" in a request handler 
definition.  That particular problem doesn't prevent a core from starting, but 
it does break queries.


> Schema API should never delete fields used elsewhere in the schema
> --
>
> Key: SOLR-9349
> URL: https://issues.apache.org/jira/browse/SOLR-9349
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>
> The Schema API should refuse to delete a field if it can detect that the 
> deletion would cause the schema to fail to load.
> This includes the field assigned to uniqueKey, fields used as copyField 
> sources, and fields used as copyField destinations.  There may be other 
> detectable problems that haven't been listed here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9349) Schema API should never delete fields used elsewhere in the schema

[Shawn Heisey (JIRA)]

Shawn Heisey created SOLR-9349:
--

 Summary: Schema API should never delete fields used elsewhere in 
the schema
 Key: SOLR-9349
 URL: https://issues.apache.org/jira/browse/SOLR-9349
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Schema and Analysis
Affects Versions: 6.1
Reporter: Shawn Heisey


The Schema API should refuse to delete a field if it can detect that the 
deletion would cause the schema to fail to load.

This includes the field assigned to uniqueKey, fields used as copyField 
sources, and fields used as copyField destinations.  There may be other 
detectable problems that haven't been listed here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9279) Add greater than, less than, etc in Solr function queries

[Doug Turnbull (JIRA)]

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

Doug Turnbull commented on SOLR-9279:
-

Looks great [~dsmiley]! Definitely a big improvement. Appreciate your 
attention, I've learned a lot through this issue.

What do you think about adding an objectValue override as suggested by 
[~hossman]?

{code:java}
 @Override
  public Object objectVal(int doc) {
return exists(doc) ? boolVal(doc) : null;
  }
{code}

> Add greater than, less than, etc in Solr function queries
> -
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Doug Turnbull
> Fix For: master (7.0)
>
> Attachments: SOLR-9279.patch
>
>
> If you use the "if" function query, you'll often expect to be able to use 
> greater than/less than functions. For example, you might want to boost books 
> written in the past 7 years. Unfortunately, there's no "greater than" 
> function query that will return non-zero when the lhs > rhs. Instead to get 
> this, you need to create really awkward function queries like I do here 
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of 
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9320) A REPLACENODE command to decommission an existing node with another new node

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9320:
--

REPLACENODE is just like any other command that we already have. This patch 
seems to be too complex for a very simple functionality like that. Please refer 
implementations of other commands.

> A REPLACENODE command to decommission an existing node with another new node
> 
>
> Key: SOLR-9320
> URL: https://issues.apache.org/jira/browse/SOLR-9320
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DELETENODE.jpeg, REPLACENODE_After.jpeg, 
> REPLACENODE_Before.jpeg, REPLACENODE_call_response.jpeg, SOLR-9320.patch
>
>
> The command should accept a source node and target node. recreate the 
> replicas in source node in the target and do a DLETENODE of source node



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-9346) Some test cases are not closing ZkStateReader

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-9346.
-
Resolution: Fixed

> Some test cases are not closing ZkStateReader
> -
>
> Key: SOLR-9346
> URL: https://issues.apache.org/jira/browse/SOLR-9346
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9346.patch
>
>
> Before the CollectionStateWatchers API was added, calling 
> ZkStateReader.close() wasn't always necessary, but now it is.  This is 
> leaking threads and causing intermittent failures (for example, in 
> ZkStateWriterTest)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9346) Some test cases are not closing ZkStateReader

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9346: Always close ZkStateReader


> Some test cases are not closing ZkStateReader
> -
>
> Key: SOLR-9346
> URL: https://issues.apache.org/jira/browse/SOLR-9346
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9346.patch
>
>
> Before the CollectionStateWatchers API was added, calling 
> ZkStateReader.close() wasn't always necessary, but now it is.  This is 
> leaking threads and causing intermittent failures (for example, in 
> ZkStateWriterTest)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9346) Some test cases are not closing ZkStateReader

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9346: Always close ZkStateReader


> Some test cases are not closing ZkStateReader
> -
>
> Key: SOLR-9346
> URL: https://issues.apache.org/jira/browse/SOLR-9346
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9346.patch
>
>
> Before the CollectionStateWatchers API was added, calling 
> ZkStateReader.close() wasn't always necessary, but now it is.  This is 
> leaking threads and causing intermittent failures (for example, in 
> ZkStateWriterTest)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9348) CollapseQParser doesn't expose params to reference from max & min functions

[David Smiley (JIRA)]

David Smiley created SOLR-9348:
--

 Summary: CollapseQParser doesn't expose params to reference from 
max & min functions
 Key: SOLR-9348
 URL: https://issues.apache.org/jira/browse/SOLR-9348
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: David Smiley
Priority: Minor


The "collapse" (CollapseQParserPlugin) has a {{max}} and {{min}} local-param to 
collapse by the min or max value of the provided function query.  
Unfortunately, when the FunctionQParser is invoked, the local-params of the 
CollapseQParser invocation nor the params of the request are passed through.  
In _some_ circumstances, it might even make {{query()}} impractical or 
impossible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7161) TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery assertion error

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7161:


That job's history is gone; here's the info from the email sent to the dev list:

{noformat}
  [junit4] Suite: org.apache.lucene.queries.mlt.TestMoreLikeThis
  [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestMoreLikeThis 
-Dtests.method=testMultiFieldShouldReturnPerFieldBooleanQuery 
-Dtests.seed=116FB7FCD72BFF28 -Dtests.slow=true -Dtests.locale=th 
-Dtests.timezone=Africa/Ouagadougou -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
  [junit4] FAILURE 0.65s J1 | 
TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery <<<
  [junit4]> Throwable #1: java.lang.AssertionError
  [junit4]> at 
__randomizedtesting.SeedInfo.seed([116FB7FCD72BFF28:75DCEF3A6AC579D3]:0)
  [junit4]> at 
org.apache.lucene.queries.mlt.TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery(TestMoreLikeThis.java:319)
  [junit4]> at java.lang.Thread.run(Thread.java:745)
  [junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): 
{weDontSell=PostingsFormat(name=Memory doPackFST= true), 
weSell=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
 text=PostingsFormat(name=Memory doPackFST= true), type=FSTOrd50}, 
docValues:{}, maxPointsInLeafNode=20, maxMBSortInHeap=5.65984835937346, 
sim=RandomSimilarity(queryNorm=false,coord=no): {weDontSell=DFR I(F)BZ(0.3), 
weSell=IB SPL-LZ(0.3), text=DFR I(ne)B3(800.0), type=DFR I(F)LZ(0.3)}, 
locale=th, timezone=Africa/Ouagadougou
  [junit4]   2> NOTE: SunOS 5.11 amd64/Oracle Corporation 1.8.0_92 
(64-bit)/cpus=3,threads=1,free=35281856,total=67108864
  [junit4]   2> NOTE: All tests run in this JVM: [TestMoreLikeThis]
  [junit4] Completed [1/20 (1!)] on J1 in 2.67s, 6 tests, 1 failure <<< 
FAILURES!
{noformat}

> TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery assertion 
> error
> ---
>
> Key: LUCENE-7161
> URL: https://issues.apache.org/jira/browse/LUCENE-7161
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Tommaso Teofili
> Fix For: master (7.0), 6.2
>
>
> I just hit this unrelated but reproducible on master 
> #cc75be53f9b3b86ec59cb93896c4fd5a9a5926b2 while tweaking earth's radius:
> {noformat}
>[junit4] Suite: org.apache.lucene.queries.mlt.TestMoreLikeThis
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestMoreLikeThis 
> -Dtests.method=testMultiFieldShouldReturnPerFieldBooleanQuery 
> -Dtests.seed=794526110651C8E6 -Dtests.locale=es-HN 
> -Dtests.timezone=Brazil/West -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.25s | 
> TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([794526110651C8E6:1DF67ED7BBBF4E1D]:0)
>[junit4]>  at 
> org.apache.lucene.queries.mlt.TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery(TestMoreLikeThis.java:320)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: codec=CheapBastard, 
> sim=ClassicSimilarity, locale=es-HN, timezone=Brazil/West
>[junit4]   2> NOTE: Linux 3.13.0-71-generic amd64/Oracle Corporation 
> 1.8.0_60 (64-bit)/cpus=8,threads=1,free=409748864,total=504889344
>[junit4]   2> NOTE: All tests run in this JVM: [TestMoreLikeThis]
>[junit4] Completed [1/1 (1!)] in 0.45s, 1 test, 1 failure <<< FAILURES!
>[junit4] 
>[junit4] 
>[junit4] Tests with failures [seed: 794526110651C8E6]:
>[junit4]   - 
> org.apache.lucene.queries.mlt.TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery
> {noformat}
> Likely related to LUCENE-6954?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7161) TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery assertion error

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7161:


Yet another failure, from 
[https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/549/]:

{noformat}
  [smoker][junit4] Suite: org.apache.lucene.queries.mlt.TestMoreLikeThis
  [smoker][junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestMoreLikeThis 
-Dtests.method=testMultiFieldShouldReturnPerFieldBooleanQuery 
-Dtests.seed=3FA5C26ECE58C917 -Dtests.multiplier=2 -Dtests.locale=es-PA 
-Dtests.timezone=US/Central -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
  [smoker][junit4] FAILURE 0.46s J0 | 
TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery <<<
  [smoker][junit4]> Throwable #1: java.lang.AssertionError
  [smoker][junit4]> at 
__randomizedtesting.SeedInfo.seed([3FA5C26ECE58C917:5B169AA873B64FEC]:0)
  [smoker][junit4]> at 
org.apache.lucene.queries.mlt.TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery(TestMoreLikeThis.java:319)
  [smoker][junit4]> at java.lang.Thread.run(Thread.java:745)
  [smoker][junit4]   2> NOTE: leaving temporary files on disk at: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.0.0/build/queries/test/J0/temp/lucene.queries.mlt.TestMoreLikeThis_3FA5C26ECE58C917-001
  [smoker][junit4]   2> NOTE: test params are: codec=Lucene62, 
sim=ClassicSimilarity, locale=es-PA, timezone=US/Central
  [smoker][junit4]   2> NOTE: Linux 3.13.0-85-generic amd64/Oracle 
Corporation 1.8.0_74 (64-bit)/cpus=4,threads=1,free=269139656,total=342360064
  [smoker][junit4]   2> NOTE: All tests run in this JVM: [TermsQueryTest, 
TestFunctionRangeQuery, TestCustomScoreQuery, TestFunctionQuerySort, 
TestMoreLikeThis]
  [smoker][junit4] Completed [16/20 (1!)] on J0 in 0.92s, 6 tests, 1 
failure <<< FAILURES!
{noformat}

> TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery assertion 
> error
> ---
>
> Key: LUCENE-7161
> URL: https://issues.apache.org/jira/browse/LUCENE-7161
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Tommaso Teofili
> Fix For: master (7.0), 6.2
>
>
> I just hit this unrelated but reproducible on master 
> #cc75be53f9b3b86ec59cb93896c4fd5a9a5926b2 while tweaking earth's radius:
> {noformat}
>[junit4] Suite: org.apache.lucene.queries.mlt.TestMoreLikeThis
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestMoreLikeThis 
> -Dtests.method=testMultiFieldShouldReturnPerFieldBooleanQuery 
> -Dtests.seed=794526110651C8E6 -Dtests.locale=es-HN 
> -Dtests.timezone=Brazil/West -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.25s | 
> TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([794526110651C8E6:1DF67ED7BBBF4E1D]:0)
>[junit4]>  at 
> org.apache.lucene.queries.mlt.TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery(TestMoreLikeThis.java:320)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: codec=CheapBastard, 
> sim=ClassicSimilarity, locale=es-HN, timezone=Brazil/West
>[junit4]   2> NOTE: Linux 3.13.0-71-generic amd64/Oracle Corporation 
> 1.8.0_60 (64-bit)/cpus=8,threads=1,free=409748864,total=504889344
>[junit4]   2> NOTE: All tests run in this JVM: [TestMoreLikeThis]
>[junit4] Completed [1/1 (1!)] in 0.45s, 1 test, 1 failure <<< FAILURES!
>[junit4] 
>[junit4] 
>[junit4] Tests with failures [seed: 794526110651C8E6]:
>[junit4]   - 
> org.apache.lucene.queries.mlt.TestMoreLikeThis.testMultiFieldShouldReturnPerFieldBooleanQuery
> {noformat}
> Likely related to LUCENE-6954?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 1289 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1289/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
ObjectTracker found 8 object(s) that were not released!!! 
[MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, 
TransactionLog, TransactionLog]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 8 object(s) that were not 
released!!! [MDCAwareThreadPoolExecutor, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, 
MockDirectoryWrapper, TransactionLog, TransactionLog]
at __randomizedtesting.SeedInfo.seed([E7862C652B57F9F7]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:258)
at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11418 lines...]
   [junit4] Suite: org.apache.solr.schema.TestManagedSchemaAPI
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J2/temp/solr.schema.TestManagedSchemaAPI_E7862C652B57F9F7-001/init-core-data-001
   [junit4]   2> 1063916 WARN  
(SUITE-TestManagedSchemaAPI-seed#[E7862C652B57F9F7]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=6 numCloses=6
   [junit4]   2> 1063918 INFO  
(SUITE-TestManagedSchemaAPI-seed#[E7862C652B57F9F7]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 1063919 INFO  
(SUITE-TestManagedSchemaAPI-seed#[E7862C652B57F9F7]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1063919 INFO  (Thread-1491) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1063919 INFO  (Thread-1491) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1064019 INFO  
(SUITE-TestManagedSchemaAPI-seed#[E7862C652B57F9F7]-worker) [] 
o.a.s.c.ZkTestServer start zk server on port:35700
   [junit4]   2> 1064020 INFO  
(SUITE-TestManagedSchemaAPI-seed#[E7862C652B57F9F7]-worker) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1064020 INFO  
(SUITE-TestManagedSchemaAPI-seed#[E7862C652B57F9F7]-worker) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1064022 INFO  (zkCallback-25606-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 

[jira] [Updated] (LUCENE-7396) Speed up flush of 1-dimension points

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-7396:
-
Attachment: LUCENE-7396.patch

I looked into the slow down with Mike. The radix sort I was using in the 1D 
case has a fallback to quicksort when the range gets more narrow, which was 
pretty slow since it would call ByteBlockPool.readBytes for every single byte, 
it should be better now. I suspect I did not hit the problem with 
IndexAndSearchOpenStreetMaps1D because most of the time was spent on the first 
levels of recursion.

The 2D case also got improved by using a radix select when recursively building 
the bkd tree instead of quickselect. The tie breaking on doc ids got improved 
by only looking at relevant bytes since we can know the number of required bits 
up-front thanks to maxDoc. And IW does not pre-budget ords anymore.

I got the following IW logs when running IndexTaxis and 
IndexAndSearchOpenStreetMaps:

{noformat}
master IndexAndSearchOpenStreetMaps, rambuffer=128MB
IW 0 [2016-07-27T15:38:21.308Z; Thread-0]: 17525 msec to write points
IW 0 [2016-07-27T15:38:44.657Z; Thread-0]: 16746 msec to write points
IW 0 [2016-07-27T15:39:08.278Z; Thread-0]: 16982 msec to write points
IW 0 [2016-07-27T15:39:32.613Z; Thread-0]: 17568 msec to write points
IW 0 [2016-07-27T15:39:56.056Z; Thread-0]: 16684 msec to write points
IW 0 [2016-07-27T15:40:06.646Z; main]: 7324 msec to write points

master IndexTaxis, first 4 flushes
IW 0 [2016-07-27T15:42:10.401Z; Thread-0]: 34422 msec to write points
IW 0 [2016-07-27T15:43:15.561Z; Thread-0]: 32306 msec to write points
IW 0 [2016-07-27T15:44:20.702Z; Thread-0]: 31753 msec to write points
IW 0 [2016-07-27T15:45:24.920Z; Thread-0]: 32340 msec to write points

patch IndexAndSearchOpenStreetMaps, ramBuffer=128MB
IW 0 [2016-07-27T15:55:49.959Z; Thread-0]: 10581 msec to write points
IW 0 [2016-07-27T15:56:08.098Z; Thread-0]: 10306 msec to write points
IW 0 [2016-07-27T15:56:25.445Z; Thread-0]: 10226 msec to write points
IW 0 [2016-07-27T15:56:42.513Z; Thread-0]: 10308 msec to write points
IW 0 [2016-07-27T15:56:59.898Z; Thread-0]: 10162 msec to write points
IW 0 [2016-07-27T15:57:08.497Z; main]: 4593 msec to write points

patch IndexTaxis, first 4 flushes
IW 0 [2016-07-27T15:47:10.906Z; Thread-0]: 25673 msec to write points
IW 0 [2016-07-27T15:48:06.356Z; Thread-0]: 23615 msec to write points
IW 0 [2016-07-27T15:49:03.327Z; Thread-0]: 23915 msec to write points
IW 0 [2016-07-27T15:49:59.424Z; Thread-0]: 23482 msec to write points
{noformat}

> Speed up flush of 1-dimension points
> 
>
> Key: LUCENE-7396
> URL: https://issues.apache.org/jira/browse/LUCENE-7396
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7396.patch, LUCENE-7396.patch, LUCENE-7396.patch
>
>
> 1D points already have an optimized merge implementation which works when 
> points come in order. So maybe we could make IndexWriter's PointValuesWriter 
> sort before feeding the PointsFormat and somehow propagate the information to 
> the PointsFormat?
> The benefit is that flushing could directly stream points to disk with little 
> memory usage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9347) Solr post tool - ignore file name extension when -type is provided

[nirav patel (JIRA)]

nirav patel created SOLR-9347:
-

 Summary: Solr post tool - ignore file name extension when -type is 
provided
 Key: SOLR-9347
 URL: https://issues.apache.org/jira/browse/SOLR-9347
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.1
Reporter: nirav patel


I found that post tool is not loading files from directory if files have no 
extension even if you specify "-params "separator=%09" -type text/tsv 
-filetypes tsv" in arguments. I think if any of above parameter is used then 
there is no need to Enter auto mode. 
Also there is no -verbose or -debug option that indicate potential problem.

./bin/post -c mycol1  -params "separator=%09" -type text/tsv -filetypes tsv  
/dev/datascience/pod1/population/baseline/
/usr/java/jdk1.8.0_102//bin/java -classpath 
/home/xactly/solr-6.1.0/dist/solr-core-6.1.0.jar -Dauto=yes -Dc=bonusOrder 
-Ddata=files -Drecursive=yes org.apache.solr.util.SimplePostTool 
/mapr/insights/datascience/rulec/prdx/bonusOrderType/baseline/
SimplePostTool version 5.0.0
Posting files to [base] url http://localhost:8983/solr/mycol1/update...
Entering auto mode. File endings considered are 
xml,json,jsonl,csv,pdf,doc,docx,ppt,pptx,xls,xlsx,odt,odp,ods,ott,otp,ots,rtf,htm,html,txt,log
Entering recursive mode, max depth=999, delay=0s
Indexing directory /dev/datascience/pod1/population/baseline/ (0 files, depth=0)
0 files indexed.
COMMITting Solr index changes to http://localhost:8983/solr/mycol1/update...
Time spent: 0:00:00.056



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9279) Add greater than, less than, etc in Solr function queries

[David Smiley (JIRA)]

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

David Smiley updated SOLR-9279:
---
Attachment: SOLR-9279.patch

Your last patch was pretty good Doug.  I spent some time last night and this 
morning cleaning it up a tad (fixed ant precommit issues) and then I went a bit 
further.  I don't really like "SafeNumericComparisonValueSource" in Lucene so I 
moved it to Solr naming it SolrComparisonValueSource.  I also changed it to not 
do primitive to object conversion, and in so doing changed the api a bit to 
make the implementations do their job via a lambda.

What do you think?

> Add greater than, less than, etc in Solr function queries
> -
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Doug Turnbull
> Fix For: master (7.0)
>
> Attachments: SOLR-9279.patch
>
>
> If you use the "if" function query, you'll often expect to be able to use 
> greater than/less than functions. For example, you might want to boost books 
> written in the past 7 years. Unfortunately, there's no "greater than" 
> function query that will return non-zero when the lhs > rhs. Instead to get 
> this, you need to create really awkward function queries like I do here 
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of 
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9346) Some test cases are not closing ZkStateReader

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-9346:

Attachment: SOLR-9346.patch

Patch.  Running tests now.

> Some test cases are not closing ZkStateReader
> -
>
> Key: SOLR-9346
> URL: https://issues.apache.org/jira/browse/SOLR-9346
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9346.patch
>
>
> Before the CollectionStateWatchers API was added, calling 
> ZkStateReader.close() wasn't always necessary, but now it is.  This is 
> leaking threads and causing intermittent failures (for example, in 
> ZkStateWriterTest)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 17383 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17383/
Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:44849/solr/testSolrCloudCollection_shard1_replica2

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
occured when talking to server at: 
http://127.0.0.1:44849/solr/testSolrCloudCollection_shard1_replica2
at 
__randomizedtesting.SeedInfo.seed([BF1C92EE26FC0E56:82C43CC21E125026]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Pushkar Raste (JIRA)]

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

Pushkar Raste commented on SOLR-9310:
-

Thanks [~rideordie...@gmail.com], I will take a look at it tonight and run my 
origin test that exposed the issue and will let you know if it works as 
expected. 

Does changing logic in the {[DistributedUpdateProcessor}} has any downside to 
it? I am wondering why {{REPLAY}} flag is treated differently than {{PEER_SYNC}}

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 40563 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/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.01 sec (11.3 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 29.9 MB in 0.03 sec (1145.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 64.3 MB in 0.06 sec (1151.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 74.9 MB in 0.06 sec (1171.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6020 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6020 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.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/jenkins-slave/tools/hudson.model.JDK/latest1.8" 
PATH="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8/bin:$PATH" 
JAVACMD="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/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-7.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-7.0.0/build
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: 
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-7.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.6 in 
public
   [smoker] [ivy:cachepath] :: resolution report :: resolve 159ms :: artifacts 
dl 2ms
   [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] 
   [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-7.0.0/top-level-ivy-settings.xml
   [smoker] 
   [smoker] -clover.load:
   [smoker] 
   [smoker] -clover.classpath:
   [smoker] 
   [smoker] -clover.setup:
   [smoker] 
   [smoker] clover:
   [smoker] 
   [smoker] -check-git-state:
   [smoker] 
   [smoker] -git-cleanroot:
   [smoker] 
   [smoker] 

[jira] [Commented] (SOLR-8645) New UI is not HTML Encoding XML

[David Johnson (JIRA)]

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

David Johnson commented on SOLR-8645:
-

[~arafalov] The files actually view correctly under Collections->Files, at 
least they do as of SOLR 6.0.1.  They still do not view correctly under the 
cloud file viewer (Cloud->Tree->Configs).  This does give me a pretty good 
avenue for copying a solution to the issue, however.

> New UI is not HTML Encoding XML
> ---
>
> Key: SOLR-8645
> URL: https://issues.apache.org/jira/browse/SOLR-8645
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 5.4.1
>Reporter: David Johnson
>Priority: Minor
>
> When viewing the Zookeeper configuration, the managed-schema file is 
> displayed without HTML encoding. This results in only the inner text of the 
> configuration elements being displayed, rather than the full XML structure.  
> This only applies to the New UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6638) Create an off-heap implementation of Solr caches

[Alexander Block (JIRA)]

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

Alexander Block commented on SOLR-6638:
---

Did anyone try to use MapDB for an off-heap cache implementation?

> Create an off-heap implementation of Solr caches
> 
>
> Key: SOLR-6638
> URL: https://issues.apache.org/jira/browse/SOLR-6638
> Project: Solr
>  Issue Type: New Feature
>Reporter: Noble Paul
>
> There are various implementations of off-heap implementations of cache. One 
> such is using sun.misc.Unsafe .The cache implementations are pluggable in 
> Solr anyway



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9147) avoid expensive byte[] resize in EmbeddedSolrServer

[Chris F (JIRA)]

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

Chris F commented on SOLR-9147:
---

I think you can use a .gitattributes file to specify the desired line endings 
per file extension. See 
https://help.github.com/articles/dealing-with-line-endings/#per-repository-settings

> avoid expensive byte[] resize in EmbeddedSolrServer
> ---
>
> Key: SOLR-9147
> URL: https://issues.apache.org/jira/browse/SOLR-9147
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9147.patch, SOLR-9147.patch
>
>
> This issue makes modest step toward EmbeddedSolrServer efficiency.
> It replaces {{java.io.ByteArrayOutputStream}} which has quite expensive 
> resizes with incrementally growing BAOS from commons-io 2.5.  
> h4. Note
> There is no expectation for performance gain in case of 
> StreamingResponseCallback.  
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 17382 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17382/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestTolerantUpdateProcessorCloud

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [TransactionLog]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [TransactionLog]
at __randomizedtesting.SeedInfo.seed([85618D6B59586FD6]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.client.solrj.TestLBHttpSolrClient.testReliability

Error Message:
GC overhead limit exceeded

Stack Trace:
java.lang.OutOfMemoryError: GC overhead limit exceeded
at 
__randomizedtesting.SeedInfo.seed([842220B23389B19D:45EAFDF492EF6034]:0)
at java.util.Arrays.copyOfRange(Arrays.java:3664)
at java.lang.String.(String.java:207)
at java.lang.String.toUpperCase(String.java:2810)
at javax.crypto.Cipher$Transform.matches(Cipher.java:422)
at javax.crypto.Cipher$Transform.supports(Cipher.java:409)
at javax.crypto.Cipher$Transform.supportsPadding(Cipher.java:398)
at javax.crypto.Cipher$Transform.supportsModePadding(Cipher.java:387)
at javax.crypto.Cipher.getInstance(Cipher.java:523)
at sun.security.ssl.JsseJce.getCipher(JsseJce.java:229)
at sun.security.ssl.CipherBox.(CipherBox.java:179)
at sun.security.ssl.CipherBox.newCipherBox(CipherBox.java:263)
at 
sun.security.ssl.CipherSuite$BulkCipher.newCipher(CipherSuite.java:505)
at sun.security.ssl.Handshaker.newReadCipher(Handshaker.java:765)
at 
sun.security.ssl.SSLSocketImpl.changeReadCiphers(SSLSocketImpl.java:2107)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1156)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
at 

[jira] [Updated] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9310:
-
Attachment: SOLR-9310.patch

sorry , wrong file

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9310:
-
Attachment: (was: SOLR-9310.patch)

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Pushkar Raste (JIRA)]

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

Pushkar Raste commented on SOLR-9310:
-

Looks like you uploaded wrong patch. It doesn't look any different than one I 
attached.

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9310:
-
Attachment: SOLR-9310.patch

Another approach. Compute the fingerprint with the latest version in the 
current node and compare it with the same version in the remote node

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 1287 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1287/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseSerialGC

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:33550/aqa/x/forceleader_test_collection_shard1_replica1]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:33550/aqa/x/forceleader_test_collection_shard1_replica1]
at 
__randomizedtesting.SeedInfo.seed([F083F3B8492D27DE:1614C77870AFDEBF]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:774)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.assertSendDocFails(ForceLeaderTest.java:315)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[JENKINS] Lucene-Solr-Tests-6.x - Build # 343 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/343/

1 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'CY val' for path 'params/c' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{ "a":"A 
val", "b":"B val", "wt":"json", "useParams":""},   "context":{ 
"webapp":"", "path":"/dump1", "httpMethod":"GET"}},  from server:  
https://127.0.0.1:53096/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'params/c' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{
"a":"A val",
"b":"B val",
"wt":"json",
"useParams":""},
  "context":{
"webapp":"",
"path":"/dump1",
"httpMethod":"GET"}},  from server:  https://127.0.0.1:53096/collection1
at 
__randomizedtesting.SeedInfo.seed([6AFB6F294C9ABFA2:E2AF50F3E266D25A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:481)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:171)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Created] (SOLR-9346) Some test cases are not closing ZkStateReader

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-9346:
---

 Summary: Some test cases are not closing ZkStateReader
 Key: SOLR-9346
 URL: https://issues.apache.org/jira/browse/SOLR-9346
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Alan Woodward
Assignee: Alan Woodward


Before the CollectionStateWatchers API was added, calling ZkStateReader.close() 
wasn't always necessary, but now it is.  This is leaking threads and causing 
intermittent failures (for example, in ZkStateWriterTest)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 127 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/127/

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

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:38909/c8n_1x3_lf_shard1_replica2]

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:38909/c8n_1x3_lf_shard1_replica2]
at 
__randomizedtesting.SeedInfo.seed([10ABF5368D693666:98FFCAEC23955B9E]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:592)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:578)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:174)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/305/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  'X val' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"/domh/sz", "path":"/test1", 
"httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":null},  from 
server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val' for path 'x' 
full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"/domh/sz",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":null},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([19CA0A4C4A3AF1EC:C187271BBDE7544C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:481)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[jira] [Commented] (SOLR-8596) Web UI doesn't correctly generate queries which include local parameters

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8596:
--

Github user liuhongyi0101 commented on the issue:

https://github.com/apache/lucene-solr/pull/56
  
8 hours ago,good


> Web UI doesn't correctly generate queries which include local parameters
> 
>
> Key: SOLR-8596
> URL: https://issues.apache.org/jira/browse/SOLR-8596
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 5.4
> Environment: Windows 8.1 Pro x64
>Reporter: Ismael Teijeiro Flórez
>Priority: Minor
>  Labels: local-parameters
>
> When configuring the "Raw Query Parameters" field for a query with a value 
> like the following, the generated query is incorrect:
> {{stats=true=\{!min=true 20max=true\}MYFIELD}}
> The generated query in this case: 
> {noformat}
> http://localhost:8983/solr/mycollection/select?indent=on=*:*=0=\{!min=true=json
> {noformat}
> As you can see, the following fragment is incorrect: {{stats.field=\{!min}}.
> This is the obtained response:
> {noformat}
> {
>   "responseHeader":{
> "status":400,
> "QTime":0,
> "params":{
>   "indent":"on",
>   "stats.field":"{!min",
>   "stats":"true",
>   "q":"*:*",
>   "_":"1453742574279",
>   "wt":"json",
>   "rows":"0"}},
>   "error":{
> "msg":"Unable to parse stats.field: {!min due to: Expected identifier at 
> pos 5 str='{!min'",
> "code":400}}
> {noformat}
> If the following URL is pasted directly in the browser, the query works as 
> expected:
> {noformat}
> http://localhost:8983/solr/mycollection/select?indent=on=*:*=0={!min=true
>  max=true}MYFIELD=true=json
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr issue #56: SOLR-8596: Split only on first equal sign

[liuhongyi0101]

Github user liuhongyi0101 commented on the issue:

https://github.com/apache/lucene-solr/pull/56
  
8 hours ago,good


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 17380 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17380/
Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseParallelGC

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestTolerantUpdateProcessorCloud

Error Message:
GC overhead limit exceeded

Stack Trace:
java.lang.OutOfMemoryError: GC overhead limit exceeded


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestTolerantUpdateProcessorCloud

Error Message:
3 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud: 1) Thread[id=16169, 
name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestTolerantUpdateProcessorCloud] at 
java.lang.Thread.sleep(Native Method) at 
org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.lang.Thread.run(Thread.java:745)2) Thread[id=16168, 
name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestTolerantUpdateProcessorCloud] at 
java.lang.Thread.sleep(Native Method) at 
org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.lang.Thread.run(Thread.java:745)3) Thread[id=16166, 
name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestTolerantUpdateProcessorCloud] at 
java.lang.Thread.sleep(Native Method) at 
org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 3 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestTolerantUpdateProcessorCloud: 
   1) Thread[id=16169, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestTolerantUpdateProcessorCloud]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.lang.Thread.run(Thread.java:745)
   2) Thread[id=16168, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestTolerantUpdateProcessorCloud]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.lang.Thread.run(Thread.java:745)
   3) Thread[id=16166, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestTolerantUpdateProcessorCloud]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([1198DF62CFCD8FF]:0)


FAILED:  
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testAddsMixedWithDeletesViaShard1LeaderClient

Error Message:
Captured an uncaught exception in thread: Thread[id=16167, name=Connection 
evictor, state=RUNNABLE, group=TGRP-TestTolerantUpdateProcessorCloud]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=16167, name=Connection evictor, state=RUNNABLE, 
group=TGRP-TestTolerantUpdateProcessorCloud]
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded


FAILED:  
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousDeletesViaCloudClient

Error Message:
IOException occured when talking to server at: 
https://127.0.0.1:34550/solr/test_col_shard1_replica2

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
occured when talking to server at: 
https://127.0.0.1:34550/solr/test_col_shard1_replica2
at 
__randomizedtesting.SeedInfo.seed([1198DF62CFCD8FF:79F4064B5A5F070A]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousDeletes(TestTolerantUpdateProcessorCloud.java:316)
at 
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousDeletesViaCloudClient(TestTolerantUpdateProcessorCloud.java:285)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 

[jira] [Commented] (SOLR-9315) SchemaSimilarityFactory should delegate queryNorm and coord to the default similarity

[ASF subversion and git services (JIRA)]

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

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

Commit 22d24969f5b148a78684482592c63e6f976fae6c in lucene-solr's branch 
refs/heads/branch_6x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=22d2496 ]

LUCENE-7395, SOLR-9315: Fix PerFieldSimilarityWrapper to also delegate query 
norm and coordination factor using a default similarity added as ctor param


> SchemaSimilarityFactory should delegate queryNorm and coord to the default 
> similarity
> -
>
> Key: SOLR-9315
> URL: https://issues.apache.org/jira/browse/SOLR-9315
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: SOLR-9315.patch
>
>
> This is a follow-up to the discussion with [~upayavira] on LUCENE-6590: 
> SchemaSimilarityFactory can easily build similarities that apply the idf 
> twice.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LUCENE-7395) Query Norm and coordination factor not calculated when PerFieldSimilarityWrapper is used

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved LUCENE-7395.
---
Resolution: Fixed

> Query Norm and coordination factor not calculated when 
> PerFieldSimilarityWrapper is used 
> -
>
> Key: LUCENE-7395
> URL: https://issues.apache.org/jira/browse/LUCENE-7395
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.3.1, 5.4.1
>Reporter: Sascha Markus
>Assignee: Uwe Schindler
> Fix For: 6.2
>
> Attachments: LUCENE-7395.patch
>
>
> If any kind of similarity is defined and therefore the 
> SchemaSimilarityFactory is defined as global similarity the queryNorm is 
> always 1.0
> The PerFieldSimilarityWrapper delegates some of the methods to the desired 
> Similarity but misses to delegate public float queryNorm(float 
> valueForNormalization)
> Instead the IndexReader calls this method on the base class Similarity.
> The result is that all scores are much higher.
> I created a custom similarity which extends ClassicSimilarity.
> To have the calculation fixed I did a local "hotfix"  which always uses the 
> default similarity. Also wrong for some cases but fine in my scenario.
>   @Override
>   public float queryNorm(float valueForNormalization) {
> return get("").queryNorm(valueForNormalization); // use default 
> similarity to calculate
>   }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7395) Query Norm and coordination factor not calculated when PerFieldSimilarityWrapper is used

[ASF subversion and git services (JIRA)]

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

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

Commit 22d24969f5b148a78684482592c63e6f976fae6c in lucene-solr's branch 
refs/heads/branch_6x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=22d2496 ]

LUCENE-7395, SOLR-9315: Fix PerFieldSimilarityWrapper to also delegate query 
norm and coordination factor using a default similarity added as ctor param


> Query Norm and coordination factor not calculated when 
> PerFieldSimilarityWrapper is used 
> -
>
> Key: LUCENE-7395
> URL: https://issues.apache.org/jira/browse/LUCENE-7395
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.3.1, 5.4.1
>Reporter: Sascha Markus
>Assignee: Uwe Schindler
> Fix For: 6.2
>
> Attachments: LUCENE-7395.patch
>
>
> If any kind of similarity is defined and therefore the 
> SchemaSimilarityFactory is defined as global similarity the queryNorm is 
> always 1.0
> The PerFieldSimilarityWrapper delegates some of the methods to the desired 
> Similarity but misses to delegate public float queryNorm(float 
> valueForNormalization)
> Instead the IndexReader calls this method on the base class Similarity.
> The result is that all scores are much higher.
> I created a custom similarity which extends ClassicSimilarity.
> To have the calculation fixed I did a local "hotfix"  which always uses the 
> default similarity. Also wrong for some cases but fine in my scenario.
>   @Override
>   public float queryNorm(float valueForNormalization) {
> return get("").queryNorm(valueForNormalization); // use default 
> similarity to calculate
>   }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+127) - Build # 1285 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1285/
Java: 32bit/jdk-9-ea+127 -client -XX:+UseParallelGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.overseer.ZkStateWriterTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.overseer.ZkStateWriterTest: 1) Thread[id=2825, 
name=watches-539-thread-1, state=TIMED_WAITING, group=TGRP-ZkStateWriterTest]   
  at jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:230)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base@9-ea/SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base@9-ea/SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(java.base@9-ea/SynchronousQueue.java:937)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(java.base@9-ea/ThreadPoolExecutor.java:1082)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1143)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
 at java.lang.Thread.run(java.base@9-ea/Thread.java:843)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.overseer.ZkStateWriterTest: 
   1) Thread[id=2825, name=watches-539-thread-1, state=TIMED_WAITING, 
group=TGRP-ZkStateWriterTest]
at jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:230)
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base@9-ea/SynchronousQueue.java:461)
at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base@9-ea/SynchronousQueue.java:362)
at 
java.util.concurrent.SynchronousQueue.poll(java.base@9-ea/SynchronousQueue.java:937)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(java.base@9-ea/ThreadPoolExecutor.java:1082)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1143)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
at __randomizedtesting.SeedInfo.seed([CC00B78135B21353]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.overseer.ZkStateWriterTest

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=2825, name=watches-539-thread-1, state=TIMED_WAITING, 
group=TGRP-ZkStateWriterTest] at 
jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:230)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base@9-ea/SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base@9-ea/SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(java.base@9-ea/SynchronousQueue.java:937)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(java.base@9-ea/ThreadPoolExecutor.java:1082)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1143)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
 at java.lang.Thread.run(java.base@9-ea/Thread.java:843)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=2825, name=watches-539-thread-1, state=TIMED_WAITING, 
group=TGRP-ZkStateWriterTest]
at jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:230)
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base@9-ea/SynchronousQueue.java:461)
at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base@9-ea/SynchronousQueue.java:362)
at 
java.util.concurrent.SynchronousQueue.poll(java.base@9-ea/SynchronousQueue.java:937)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(java.base@9-ea/ThreadPoolExecutor.java:1082)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1143)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
at __randomizedtesting.SeedInfo.seed([CC00B78135B21353]:0)




Build Log:
[...truncated 11137 lines...]
   [junit4] Suite: org.apache.solr.cloud.overseer.ZkStateWriterTest
   [junit4]   2> Creating 

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3436 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3436/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'first' for path 
'response/params/x/_appends_/add' full output: {   "responseHeader":{ 
"status":0, "QTime":0},   "response":{ "znodeVersion":3, "params":{ 
  "x":{ "a":"A val", "b":"B val", "":{"v":0}},  
 "y":{ "p":"P val", "q":"Q val", "":{"v":2},  from 
server:  http://127.0.0.1:62670/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'first' for path 
'response/params/x/_appends_/add' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":3,
"params":{
  "x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
  "y":{
"p":"P val",
"q":"Q val",
"":{"v":2},  from server:  http://127.0.0.1:62670/collection1
at 
__randomizedtesting.SeedInfo.seed([68993D601DB04565:E0CD02BAB34C289D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:481)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:230)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at