[jira] [Updated] (SOLR-8146) Preferred SolrCloud node for SolrJ query/read

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou updated SOLR-8146:
-
Description: 
This is a simple proposal to allow more flexibility about which node SolrJ 
queries first.
This is mainly to avoid unnecessary traffic in the network.

For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 
separate racks: rack1 and rack2.

On each rack, we have a set of SolrCloud VMs as well as a couple of client VMs 
querying solr using SolrJ.

All solr nodes are identical and have the same number of collections.

What we would like to achieve is:
- clients on rack1 will by preference query only SolrCloud nodes on rack1, and 
- clients on rack2 will by preference query only SolrCloud nodes on rack2.
- Cross-rack read will happen if and only if one of the racks has no available 
Solr node to serve a request.

In other words, we want read operations to be local to a rack whenever possible.

Note that write/update/delete/admin operations should not be affected.

Initially, I thought it may be good to have Solr nodes tagged with rackID 
(snitch?) for matching the hosts.

Note that this feature may have many usages such as SOLR-5501

Note that in our use case, we have a cross DC deployment. So, replace 
rack1/rack2 by DC1/DC2

Any comment would be very appreciated.

Thanks.


  was:

This is a simple proposal to allow more flexibility about which node SolrJ 
queries first.
This is mainly to avoid unnecessary traffic in the network.

For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 
separate racks: rack1 and rack2.

On each rack, we have a set of SolrCloud VMs as well as a couple of client VMs 
querying solr using SolrJ.

All solr nodes are identical and have the same number of collections.

What we would like to achieve is:
- clients on rack1 will by preference query only SolrCloud nodes on rack1, and 
- clients on rack2 will by preference query only SolrCloud nodes on rack2.
- Cross-rack read will happen if and only if one of the racks has no available 
Solr node to serve a request.

In other words, we want read operations to be local to a rack whenever possible.

Note that write operations should not be affected.

Attached is a patch which is a work in progress.
Initially, I thought it may be good to have Solr nodes tagged with rackID 
(snitch?) for matching the hosts.

Note that this feature may have many usages such as SOLR-5501
 
Any comment would be very appreciated.

Thanks.



> Preferred SolrCloud node for SolrJ query/read
> -
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> This is a simple proposal to allow more flexibility about which node SolrJ 
> queries first.
> This is mainly to avoid unnecessary traffic in the network.
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 
> separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Initially, I thought it may be good to have Solr nodes tagged with rackID 
> (snitch?) for matching the hosts.
> Note that this feature may have many usages such as SOLR-5501
> Note that in our use case, we have a cross DC deployment. So, replace 
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> Thanks.



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

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

[jira] [Updated] (SOLR-8146) Preferred SolrCloud node for SolrJ query/read

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou updated SOLR-8146:
-
Attachment: SOLR-8146.patch

Updated with more tests.
Any comment or feedback would be most appreciated

> Preferred SolrCloud node for SolrJ query/read
> -
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> This is a simple proposal to allow more flexibility about which node SolrJ 
> queries first.
> This is mainly to avoid unnecessary traffic in the network.
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 
> separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write operations should not be affected.
> Attached is a patch which is a work in progress.
> Initially, I thought it may be good to have Solr nodes tagged with rackID 
> (snitch?) for matching the hosts.
> Note that this feature may have many usages such as SOLR-5501
>  
> Any comment would be very appreciated.
> Thanks.



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

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

[jira] [Commented] (LUCENE-6874) WhitespaceTokenizer should tokenize on NBSP

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6874:
---

I would be fine to remove WhitespaceTokenizer in Lucene trunk. In that case I 
would also like to move the abstract CharTokenizer class out of 
oal.analysis.util to oal.analysis.core. This is not a big deal, but the util 
package is not fine for a first class citizen.

I also have another idea about this issue; I would prefer to not have the large 
java code with jflex involved. Wouldn't it be possible to save the isWhitespace 
data of Unicode in a compressible Lucene bitset and save it to disk as resource 
file? We could then load the bitset (like deleted documents) from a resource 
file and wrap a simple {{CharTokenizer.fromSeparatorCharPredicate(c -> 
compressedBitset.get(c))}} on top? The bitset could be generated from Unicode 
data on "ant regenerate".

> WhitespaceTokenizer should tokenize on NBSP
> ---
>
> Key: LUCENE-6874
> URL: https://issues.apache.org/jira/browse/LUCENE-6874
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: David Smiley
>Priority: Minor
> Attachments: LUCENE-6874-jflex.patch, LUCENE-6874.patch, 
> LUCENE_6874_jflex.patch
>
>
> WhitespaceTokenizer uses [Character.isWhitespace 
> |http://docs.oracle.com/javase/8/docs/api/java/lang/Character.html#isWhitespace-int-]
>  to decide what is whitespace.  Here's a pertinent excerpt:
> bq. It is a Unicode space character (SPACE_SEPARATOR, LINE_SEPARATOR, or 
> PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0', 
> '\u2007', '\u202F')
> Perhaps Character.isWhitespace should have been called 
> isLineBreakableWhitespace?
> I think WhitespaceTokenizer should tokenize on this.  I am aware it's easy to 
> work around but why leave this trap in by default?



--
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-6304) Transforming and Indexing custom JSON data

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-6304:
--

yes it could work w/ dynamic fields if your field names match the dynamic field 
pattern. 

eg:

{code}
f=first_s:/firstName
{code}

> Transforming and Indexing custom JSON data
> --
>
> Key: SOLR-6304
> URL: https://issues.apache.org/jira/browse/SOLR-6304
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 4.10, Trunk
>
> Attachments: SOLR-6304.patch, SOLR-6304.patch
>
>
> example
> {noformat}
> curl 
> localhost:8983/update/json/docs?split=/batters/batter&f=recipeId:/id&f=recipeType:/type&f=id:/batters/batter/id&f=type:/batters/batter/type
>  -d '
> {
>   "id": "0001",
>   "type": "donut",
>   "name": "Cake",
>   "ppu": 0.55,
>   "batters": {
>   "batter":
>   [
>   { "id": "1001", "type": 
> "Regular" },
>   { "id": "1002", "type": 
> "Chocolate" },
>   { "id": "1003", "type": 
> "Blueberry" },
>   { "id": "1004", "type": 
> "Devil's Food" }
>   ]
>   }
> }'
> {noformat}
> should produce the following output docs
> {noformat}
> { "recipeId":"001", "recipeType":"donut", "id":"1001", "type":"Regular" }
> { "recipeId":"001", "recipeType":"donut", "id":"1002", "type":"Chocolate" }
> { "recipeId":"001", "recipeType":"donut", "id":"1003", "type":"Blueberry" }
> { "recipeId":"001", "recipeType":"donut", "id":"1004", "type":"Devil's food" }
> {noformat}
> the split param is the element in the tree where it should be split into 
> multiple docs. The 'f' are field name mappings



--
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-5.x-Linux (32bit/jdk1.9.0-ea-b90) - Build # 14563 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14563/
Java: 32bit/jdk1.9.0-ea-b90 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.test

Error Message:
There should be 3 documents because there should be two id=1 docs due to 
overwrite=false expected:<3> but was:<1>

Stack Trace:
java.lang.AssertionError: There should be 3 documents because there should be 
two id=1 docs due to overwrite=false expected:<3> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([1319076A73EAACDD:9B4D38B0DD16C125]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testOverwriteOption(CloudSolrClientTest.java:174)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:120)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailur

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b90) - Build # 14852 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14852/
Java: 64bit/jdk1.9.0-ea-b90 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=2951, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)2) Thread[id=2955, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)3) Thread[id=2953, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)4) Thread[id=2954, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)5) Thread[id=2952, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=2951, name=apacheds, state=WAITING, 
group=TGRP-SaslZkACLProviderTest]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:516)
at java.util.TimerThread.mainLoop(Timer.java:526)
at java.util.TimerThread.run(Timer.java:505)
   2) Thread[id=2955, name=ou=system.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at sun.misc.Unsafe.park(Native Method)
at 

[jira] [Commented] (LUCENE-6874) WhitespaceTokenizer should tokenize on NBSP

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6874:
--

Just for clarification, Adrien, are you suggesting that 
WhitespaceTokenizerFactory stays, but WhitespaceTokenizer get removed (because 
it's easy to define one)?  I'm +1 to that.

> WhitespaceTokenizer should tokenize on NBSP
> ---
>
> Key: LUCENE-6874
> URL: https://issues.apache.org/jira/browse/LUCENE-6874
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: David Smiley
>Priority: Minor
> Attachments: LUCENE-6874-jflex.patch, LUCENE-6874.patch, 
> LUCENE_6874_jflex.patch
>
>
> WhitespaceTokenizer uses [Character.isWhitespace 
> |http://docs.oracle.com/javase/8/docs/api/java/lang/Character.html#isWhitespace-int-]
>  to decide what is whitespace.  Here's a pertinent excerpt:
> bq. It is a Unicode space character (SPACE_SEPARATOR, LINE_SEPARATOR, or 
> PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0', 
> '\u2007', '\u202F')
> Perhaps Character.isWhitespace should have been called 
> isLineBreakableWhitespace?
> I think WhitespaceTokenizer should tokenize on this.  I am aware it's easy to 
> work around but why leave this trap in by default?



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

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

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_66) - Build # 5387 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5387/
Java: 64bit/jdk1.8.0_66 -XX:+UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
ERROR: SolrIndexSearcher opens=51 closes=50

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50
at __randomizedtesting.SeedInfo.seed([7A6C7D7430B44AB3]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:468)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:234)
at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:829)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=2670, name=searcherExecutor-1506-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=2670, name=searcherExecutor-1506-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([7A6C7D7430B44AB3]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=2670, name=searche

[jira] [Commented] (SOLR-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Adrien Grand (JIRA)]

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

Adrien Grand commented on SOLR-8251:


bq. Couldn't this also be handled by the BooleanQuery.rewrite optimization 
we're talking about?

Indeed it could. I opened LUCENE-6889 as a follow-up.

bq. In any case: I still think, Lucene's FilteredQuery should rewrite like it 
did before. Maybe this would solve some problems like this (although it should 
still work fast).

Works for me.

> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*&fq=+categoryIdsPath:1001&fl=id&start=0&rows=2&debug=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



--
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-5.x-Linux (64bit/jdk1.9.0-ea-b90) - Build # 14560 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14560/
Java: 64bit/jdk1.9.0-ea-b90 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:35041/qx_","node_name":"127.0.0.1:35041_qx_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={   "replicationFactor":"3",   
"shards":{"shard1":{   "range":"8000-7fff",   "state":"active", 
  "replicas":{ "core_node1":{   "state":"down",   
"base_url":"http://127.0.0.1:60847/qx_";,   
"core":"c8n_1x3_lf_shard1_replica3",   
"node_name":"127.0.0.1:60847_qx_"}, "core_node2":{   
"core":"c8n_1x3_lf_shard1_replica2",   
"base_url":"http://127.0.0.1:47519/qx_";,   
"node_name":"127.0.0.1:47519_qx_",   "state":"down"}, 
"core_node3":{   "core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:35041/qx_";,   
"node_name":"127.0.0.1:35041_qx_",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:35041/qx_","node_name":"127.0.0.1:35041_qx_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "state":"down",
  "base_url":"http://127.0.0.1:60847/qx_";,
  "core":"c8n_1x3_lf_shard1_replica3",
  "node_name":"127.0.0.1:60847_qx_"},
"core_node2":{
  "core":"c8n_1x3_lf_shard1_replica2",
  "base_url":"http://127.0.0.1:47519/qx_";,
  "node_name":"127.0.0.1:47519_qx_",
  "state":"down"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:35041/qx_";,
  "node_name":"127.0.0.1:35041_qx_",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([750C531EBAC1910C:FD586CC4143DFCF4]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:166)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(Thread

[jira] [Created] (LUCENE-6889) BooleanQuery.rewrite could easily optimize some simple cases

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6889:


 Summary: BooleanQuery.rewrite could easily optimize some simple 
cases
 Key: LUCENE-6889
 URL: https://issues.apache.org/jira/browse/LUCENE-6889
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor


Follow-up of SOLR-8251: APIs and user interfaces sometimes encourage to write 
BooleanQuery instances that are not optimal, for instance a typical case that 
happens often with Solr/Elasticsearch is to send a request that has a 
MatchAllDocsQuery as a query and some filter, which could be executed more 
efficiently by directly wrapping the filter into a ConstantScoreQuery.

Here are some ideas of rewrite operations that BooleanQuery could perform:
 - remove FILTER clauses when they are also a MUST clause
 - rewrite queries of the form "+*:* #filter" to a ConstantScoreQuery(filter)
 - rewrite to a MatchNoDocsQuery when a clause that is a MUST or FILTER clause 
is also a MUST_NOT clause



--
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-6276) Add matchCost() api to TwoPhaseDocIdSetIterator

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6276:
--

bq. ConjunctionDISI matchCost(): give the lower matchCosts a higher weight

We could use the likelyness of a match, which should be given by 
Scorer.asTwoPhaseApproximation().approximation().cost()/Scorer.cost() even 
though I suspect that most implementations have no way to figure it out (eg. 
numeric doc values ranges). But I think we should defer, it's fine to assume 
worst case like the patch does today.

bq. TwoPhaseIterator: Return value of matchCost(): long instead of float?

I would be ok with both, but given that matchCost is documented as "an expected 
cost in number of simple operations", maybe a long makes more sense? It also 
has the benefit of avoiding issues with ±0, Nans, infinities, etc.

bq. Performance test based on Wikipedia to estimate guessed values.

I think this change is very hard to benchmark... I'm personally fine with 
moving on here without performance benchmarks.

For other ones that I did not reply to, I suggest that we defer them: I don't 
think they should hold this change.

> Add matchCost() api to TwoPhaseDocIdSetIterator
> ---
>
> Key: LUCENE-6276
> URL: https://issues.apache.org/jira/browse/LUCENE-6276
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-6276-ExactPhraseOnly.patch, 
> LUCENE-6276-NoSpans.patch, LUCENE-6276-NoSpans2.patch, LUCENE-6276.patch, 
> LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch, 
> LUCENE-6276.patch, LUCENE-6276.patch
>
>
> We could add a method like TwoPhaseDISI.matchCost() defined as something like 
> estimate of nanoseconds or similar. 
> ConjunctionScorer could use this method to sort its 'twoPhaseIterators' array 
> so that cheaper ones are called first. Today it has no idea if one scorer is 
> a simple phrase scorer on a short field vs another that might do some geo 
> calculation or more expensive stuff.
> PhraseScorers could implement this based on index statistics (e.g. 
> totalTermFreq/maxDoc)



--
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-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8251:
-

In any case: I still think, Lucene's FilteredQuery should rewrite like it did 
before. Maybe this would solve some problems like this (although it should 
still work fast).


> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*&fq=+categoryIdsPath:1001&fl=id&start=0&rows=2&debug=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



--
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-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8251:


bq. Regarding the produced scores, the reason it works this way is that it made 
more sense to me to return 0 as a score when there are no scoring clauses 
(hence no sources of scores).

Couldn't this also be handled by the BooleanQuery.rewrite optimization we're 
talking about?

Off the top of my head: if the only "scoring" clause is a MatchAllDocs, but 
there are other non-MUST_NOT clauses so it can safely be removed, remove it and 
return a ConstantScoreQuery wrapping the new (smaller) BQ?


> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*&fq=+categoryIdsPath:1001&fl=id&start=0&rows=2&debug=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



--
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-6874) WhitespaceTokenizer should tokenize on NBSP

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6874:
--

I tend to like Uwe's idea. I have often wondered what the actual use-cases of 
WhitespaceTokenizer were but did not suggest to remove it as the cost of 
maintenance was very low given its simplicity. However now that there is some 
controversy arising and given how simple it is to create character-based 
tokenizers in trunk {{Tokenizer tok = 
CharTokenizer.fromSeparatorCharPredicate(Character::isWhitespace);}}, maybe we 
should just remove this tokenizer and let users define it themselves with the 
more flexible {{CharTokenizer.fromSeparatorCharPredicate}}?

> WhitespaceTokenizer should tokenize on NBSP
> ---
>
> Key: LUCENE-6874
> URL: https://issues.apache.org/jira/browse/LUCENE-6874
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: David Smiley
>Priority: Minor
> Attachments: LUCENE-6874-jflex.patch, LUCENE-6874.patch, 
> LUCENE_6874_jflex.patch
>
>
> WhitespaceTokenizer uses [Character.isWhitespace 
> |http://docs.oracle.com/javase/8/docs/api/java/lang/Character.html#isWhitespace-int-]
>  to decide what is whitespace.  Here's a pertinent excerpt:
> bq. It is a Unicode space character (SPACE_SEPARATOR, LINE_SEPARATOR, or 
> PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0', 
> '\u2007', '\u202F')
> Perhaps Character.isWhitespace should have been called 
> isLineBreakableWhitespace?
> I think WhitespaceTokenizer should tokenize on this.  I am aware it's easy to 
> work around but why leave this trap in by default?



--
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-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8251:
-

bq. Regarding the produced scores, the reason it works this way is that it made 
more sense to me to return 0 as a score when there are no scoring clauses 
(hence no sources of scores).

It was just meant as warning... I know why you need to return 0 as score for 
filters - otherwise BQ would sum them up and fck up other scores... In my case 
the problem was a geo query with some distance-related scoring applied 
afterwards!

> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*&fq=+categoryIdsPath:1001&fl=id&start=0&rows=2&debug=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



--
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-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Adrien Grand (JIRA)]

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

Adrien Grand commented on SOLR-8251:


I just saw the edit: don't worry Uwe, I didn't feel accused. On the contrary 
I'm happy to be pinged about follow-ups of these things I've been working on 
and to discuss them.

Regarding the produced scores, the reason it works this way is that it made 
more sense to me to return 0 as a score when there are no scoring clauses 
(hence no sources of scores).

> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*&fq=+categoryIdsPath:1001&fl=id&start=0&rows=2&debug=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



--
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-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8251:
-

Of course, I like the idea more, too :-) I just hit the trap of scores getting 
0. Of yource this is just cosmetics, but it confused me!

> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*&fq=+categoryIdsPath:1001&fl=id&start=0&rows=2&debug=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



--
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-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Adrien Grand (JIRA)]

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

Adrien Grand commented on SOLR-8251:


bq. Maybe we should open a regression in Lucene core: Although FilteredQuery is 
deprecated, I still think the rewrite of FilteredQuery(MatchAllDocs,Filter) -> 
CSQ was perfectly fine. Not sure why Adrien Grand removed it in 5.x...

FilteredQuery was deprecated in favour of BooleanQuery so I wanted to make 
FilteredQuery rewrite to the equivalent BooleanQuery to make things as close as 
they will be in 6.0. The rewrite to a CSQ was fine indeed but instead of adding 
back this optimization to FilteredQuery, I like Hoss' idea to add it to 
BooleanQuery better as it would solve two issues at once given that 
FilteredQuery already rewrites to a BooleanQuery?

> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*&fq=+categoryIdsPath:1001&fl=id&start=0&rows=2&debug=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



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

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

[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 1012 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/1012/

All tests passed

Build Log:
[...truncated 4723 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/build/backward-codecs/test/temp/junit4-J2-20151109_224734_067.syserr
   [junit4] >>> JVM J2: stderr (verbatim) 
   [junit4] WARN: Unhandled exception in event serialization. -> 
java.security.PrivilegedActionException: java.io.IOException: No space left on 
device
   [junit4] at java.security.AccessController.doPrivileged(Native Method)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer.flushQueue(Serializer.java:96)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer.serialize(Serializer.java:81)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.slave.RunListenerEmitter.testAssumptionFailure(RunListenerEmitter.java:68)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.slave.NoExceptionRunListenerDecorator.testAssumptionFailure(NoExceptionRunListenerDecorator.java:63)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.slave.BeforeAfterRunListenerDecorator.testAssumptionFailure(BeforeAfterRunListenerDecorator.java:69)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.slave.OrderedRunNotifier$5.notifyListener(OrderedRunNotifier.java:146)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.slave.OrderedRunNotifier$SafeNotifier.run(OrderedRunNotifier.java:63)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.slave.OrderedRunNotifier.fireTestAssumptionFailed(OrderedRunNotifier.java:148)
   [junit4] at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$SubNotifier.fireTestAssumptionFailed(ThreadLeakControl.java:175)
   [junit4] at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:879)
   [junit4] at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
   [junit4] at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
   [junit4] at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
   [junit4] at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
   [junit4] at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4] at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
   [junit4] at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
   [junit4] at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
   [junit4] at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4] at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4] at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4] at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
   [junit4] at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
   [junit4] at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
   [junit4] at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
   [junit4] at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4] at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
   [junit4] at java.lang.Thread.run(Thread.java:745)
   [junit4] Caused by: java.io.IOException: No space left on device
   [junit4] at java.io.FileOutputStream.writeBytes(Native Method)
   [junit4] at java.io.FileOutputStream.write(FileOutputStream.java:345)
   [junit4] at 
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
   [junit4] at 
java.io.BufferedOutputStream.write(BufferedOutputStream.java:121)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.slave.EventsOutputStream.write(EventsOutputStream.java:28)
   [junit4] at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
   [junit4] at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282)
   [junit4] at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
   [junit4] at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:135)
   [junit4] at java.io.OutputStreamWriter.write(OutputStreamWriter.java:220)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.gson.stream.JsonWriter.string(JsonWriter.java:565)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.gson.stream.JsonW

[jira] [Comment Edited] (SOLR-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8251 at 11/9/15 11:02 PM:
---

Maybe we should open a regression in Lucene core: Although FilteredQuery is 
deprecated, I still think the rewrite of FilteredQuery(MatchAllDocs,Filter) -> 
CSQ was perfectly fine. Not sure why [~jpountz] removed it in 5.x...

Edit: I did not wat to specifically accuse Adrien :-) I just skimmed through 
the changes of FilteredQuery and found out that the "optimization" was removed.

In general there is a difference also in scoring: The matchAllDocsQuery 
produced a constant score of 1 (perfectly fine). Now if you remove the 
MatchAllDocsQuery from the BQ, you produce a similar strange thing: You get a 
query that has a score of 0 I hit the same issue when I rewrote my queries 
in Elasticsearch and I just removed the MatchAllDocsQuery... Suddenly those 
queries consisting solely of filters got a score of 0


was (Author: thetaphi):
Maybe we should open a regression in Lucene core: Although FilteredQuery is 
deprecated, I still think the rewrite of FilteredQuery(MatchAllDocs,Filter) -> 
CSQ was perfectly fine. Not sure why [~jpountz] removed it in 5.x...

> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*&fq=+categoryIdsPath:1001&fl=id&start=0&rows=2&debug=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



--
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-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8251:
-

Maybe we should open a regression in Lucene core: Although FilteredQuery is 
deprecated, I still think the rewrite of FilteredQuery(MatchAllDocs,Filter) -> 
CSQ was perfectly fine. Not sure why [~jpountz] removed it in 5.x...

> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*&fq=+categoryIdsPath:1001&fl=id&start=0&rows=2&debug=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



--
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-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8251:


bq. This is exactly th reason why I made it like that in 4.0 when I rewrote 
FilteredQuery... So basically the common case was very common.

Yeah ... even if it turns out there is some other underlying cause for the 
regression noted here, I wonder if it would make sense to optimize 
BooleanQuery.rewrite (or maybe BooleanQuery.Builder?) to special case removing 
MatchAllDocs when there are other MUST/SHOULD/FILTER clauses?

> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*&fq=+categoryIdsPath:1001&fl=id&start=0&rows=2&debug=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



--
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-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8251:
-

bq. This isn't as weird as it may seem when discussed abstractly ... 
practically speaking it can be common for people to build up a 
faceting/navigation system based on adding fqs to a "base query" as the user 
drills down. If the user starts their navigation with a search then they have a 
non-trivial "q" for their base query – but if the user didn't start with some 
explicit search, they may just be drilling down from a starting view of "all 
documents"

Hey Hoss, this was not meant as "stupid" - more its stüpid for Lucene to 
execute like that. This is exactly th reason why I made it like that in 4.0 
when I rewrote FilteredQuery... So basically the common case was very common.

> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*&fq=+categoryIdsPath:1001&fl=id&start=0&rows=2&debug=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



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

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

[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 177 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/177/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAliasTest.test

Error Message:
Shards in the state does not match what we set:1 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:1 vs 3
at 
__randomizedtesting.SeedInfo.seed([812C69F1C41816D5:978562B6AE47B2D]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:961)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAvroTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([812C69F1C41816D5:978562B6AE47B2D]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
   

[jira] [Commented] (SOLR-8260) Use NIO2 APIs in core discovery

[ASF subversion and git services (JIRA)]

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

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

Commit 1713564 from [~romseygeek] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1713564 ]

SOLR-8260: Remove morphlines test setup with wrongly configured core discovery 
roots

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4
>
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



--
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-8260) Use NIO2 APIs in core discovery

[ASF subversion and git services (JIRA)]

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

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

Commit 1713563 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1713563 ]

SOLR-8260: Remove morphlines test setup with wrongly configured core discovery 
roots

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4
>
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



--
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-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8251:


bq. The mailing-list discussion referenced above can be found here ...

specifically: 
https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201511.mbox/%3CCAAJUMYrO32eXRiUvULJxRdNe0p9xmXyH5RawVAcDNZHh%2BffoZw%40mail.gmail.com%3E

bq. Of course executing a MatchAllDocsQuery just to Filter the results is 
stupid. As Filters are now plain Queries in 5.x, why not execute all Filters in 
Solr as a plain query? MatchAllDocsQuery is only useful for pure negative 
queries.

This isn't as weird as it may seem when discussed abstractly ... practically 
speaking it can be common for people to build up a faceting/navigation system 
based on adding fqs to a "base query" as the user drills down.  If the user 
starts their navigation with a search then they have a non-trivial "q" for 
their base query -- but if the user didn't start with some explicit search, 
they may just be drilling down from a starting view of "all documents"

something like dismax/edismax with a {{q.alt=*:*}} is even designed around this 
usage pattern.



Perhaps the "if (null==filter) \{ wrap main + filter in a BooleanQuery \}" 
logic yonik mentioned LUCENE-6583 putting in SolrIndexSearcher should be 
tweaked to include a similar optimization to what use to be in FilteredQuery ? 
(ie: "if (null==main) \{ don't wrap, just use main=filter \}")
https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201511.mbox/%3CCAB_8Yd8ForGSSXRC=hq+i6mkxhy5xy1kehvh1iml4pdx_ey...@mail.gmail.com%3E

> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*&fq=+categoryIdsPath:1001&fl=id&start=0&rows=2&debug=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



--
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-6874) WhitespaceTokenizer should tokenize on NBSP

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6874:
---

Yeah remove it! LUCENE-6879 is enough to quickly define your own 
WhitespaceTokenizer with ICU, if you want.

> WhitespaceTokenizer should tokenize on NBSP
> ---
>
> Key: LUCENE-6874
> URL: https://issues.apache.org/jira/browse/LUCENE-6874
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: David Smiley
>Priority: Minor
> Attachments: LUCENE-6874-jflex.patch, LUCENE-6874.patch, 
> LUCENE_6874_jflex.patch
>
>
> WhitespaceTokenizer uses [Character.isWhitespace 
> |http://docs.oracle.com/javase/8/docs/api/java/lang/Character.html#isWhitespace-int-]
>  to decide what is whitespace.  Here's a pertinent excerpt:
> bq. It is a Unicode space character (SPACE_SEPARATOR, LINE_SEPARATOR, or 
> PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0', 
> '\u2007', '\u202F')
> Perhaps Character.isWhitespace should have been called 
> isLineBreakableWhitespace?
> I think WhitespaceTokenizer should tokenize on this.  I am aware it's easy to 
> work around but why leave this trap in by default?



--
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-5.x-Linux (64bit/jdk1.9.0-ea-b90) - Build # 14559 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14559/
Java: 64bit/jdk1.9.0-ea-b90 -XX:+UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAliasTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([D6E811A4CC3D50C9:5EBC2E7E62C13D31]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:961)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:747)


FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([D6E811A4CC3D50C9:5EBC2E7E62C13D31]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)

[jira] [Resolved] (SOLR-8261) Change the wrapped per-field default in SchemaSimilarityFactory to BM25 (conditional on luceneMatchVersion for backcompat)

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-8261.

Resolution: Fixed

I couldn't find anything else that seemed necessary to update for this change, 
other then fixing the test to use a Version.\* constant instead of a magic 
string.

> Change the wrapped per-field default in SchemaSimilarityFactory to BM25 
> (conditional on luceneMatchVersion for backcompat)
> --
>
> Key: SOLR-8261
> URL: https://issues.apache.org/jira/browse/SOLR-8261
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: Trunk
>
> Attachments: SOLR-8261.patch
>
>
> As outlined in parent issue...
> * use ClassicSimilarity as per-field default when luceneMatchVersion < 6.0
> * use BM25Similarity as per-field default when luceneMatchVersion < 6.0



--
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-8261) Change the wrapped per-field default in SchemaSimilarityFactory to BM25 (conditional on luceneMatchVersion for backcompat)

[ASF subversion and git services (JIRA)]

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

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

Commit 1713557 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1713557 ]

SOLR-8261: Change SchemaSimilarityFactory default to BM25Similarity

> Change the wrapped per-field default in SchemaSimilarityFactory to BM25 
> (conditional on luceneMatchVersion for backcompat)
> --
>
> Key: SOLR-8261
> URL: https://issues.apache.org/jira/browse/SOLR-8261
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: Trunk
>
> Attachments: SOLR-8261.patch
>
>
> As outlined in parent issue...
> * use ClassicSimilarity as per-field default when luceneMatchVersion < 6.0
> * use BM25Similarity as per-field default when luceneMatchVersion < 6.0



--
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-6276) Add matchCost() api to TwoPhaseDocIdSetIterator

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-6276:
--

I went over the patch and the earlier posts to get an overview of open points, 
TODO's, etc.
There are quite a lot of them, so we'll need to prioritize and/or move/defer to 
other issues.

lucene core:

ConjunctionDISI matchCost(): give the lower matchCosts a higher weight

PhraseQuery:
TERM_POSNS_SEEK_OPS_PER_DOC = 128, guess
PHRASE_TO_SPAN_TERM_POSITIONS_COST = 4, guess

TwoPhaseIterator: Return value of matchCost(): long instead of float?

RandomAccessWeight matchCost(): 10, use cost of matchingDocs.get()

ReqExclScorer matchCost(): also use cost of exclApproximation.advance()

SpanTermQuery: termPositionsCost is copy of PhraseQuery termPositionsCost

SpanOrQuery: add cost of balancing priority queues for positions?


facet module (defer to other issue):

DoubleRange matchCost(): 100, use cost of range.accept()
LongRange matchCost(): 100, use cost of range.accept()


join module (defer to other issue ?):

GlobalOrdinals(WithScore)Query matchCost(): 100, use cost of values.getOrd() 
and foundOrds.get()
GlobalOrdinals(WithScore)Query 2nd matchCost(): 100, use cost of 
values.getOrd() and foundOrds.get()


queries module (defer to other issue):

ValueSourceScorer matchCost(): 100, use cost of 
ValueSourceScorer.this.matches()ValueSourceScorer matchCost(): 100, use cost of 


spatial module (defer to other issue)::

CompositeVerifyQuery matchCost(): 100, use cost of predFuncValues.boolVal()
IntersectsRPTVerifyQuery matchCost(): 100, use cost of exactIterator.advance() 
and predFuncValues.boolVal()

test-framework module:

RandomApproximationQuery randomMatchCost: between 0 and 200: ok?

solr core:

Filter matchCost(): 10, use cost of bits.get() ?


At this issue:

Performance test based on Wikipedia to estimate guessed values.

tests for matchCost() ?

Check result of ConjunctionSpans.asTwoPhaseIterator: more similar to 
TwoPhaseConjunctionDISI ?


For other issues:

At LUCENE-6871 remove copy of SpanTermQuery.termPositionsCost(). 

SpanOrQuery is getting too big, split off DisjunctionSpans.

cost() implementation of conjunctions and disjunctions could improve: add use 
of indepence assumption.
The result of cost() is used here for weighting, so it should be good as 
possible.

> Add matchCost() api to TwoPhaseDocIdSetIterator
> ---
>
> Key: LUCENE-6276
> URL: https://issues.apache.org/jira/browse/LUCENE-6276
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-6276-ExactPhraseOnly.patch, 
> LUCENE-6276-NoSpans.patch, LUCENE-6276-NoSpans2.patch, LUCENE-6276.patch, 
> LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch, 
> LUCENE-6276.patch, LUCENE-6276.patch
>
>
> We could add a method like TwoPhaseDISI.matchCost() defined as something like 
> estimate of nanoseconds or similar. 
> ConjunctionScorer could use this method to sort its 'twoPhaseIterators' array 
> so that cheaper ones are called first. Today it has no idea if one scorer is 
> a simple phrase scorer on a short field vs another that might do some geo 
> calculation or more expensive stuff.
> PhraseScorers could implement this based on index statistics (e.g. 
> totalTermFreq/maxDoc)



--
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-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[ASF subversion and git services (JIRA)]

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

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

Commit 1713547 from [~joel.bernstein] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1713547 ]

SOLR-8262: Comment out /stream handler from sample solrconfig.xml's for 
security reasons

> Comment out /stream handler from sample solrconfig.xml's for security reasons
> -
>
> Key: SOLR-8262
> URL: https://issues.apache.org/jira/browse/SOLR-8262
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> Solr has apache commons-collections in it's classpath. 
> *This makes it vulnerable to this security issue 
> https://issues.apache.org/jira/browse/COLLECTIONS-580. 
> *The /stream handler uses Java serialization for RPC since Solr 5.1. 
> These two combined leave a security hole in Solr that allows arbitrary code 
> to be executed on the server.
> This ticket will comment out the /stream handler from the sample 
> solrconfig.xml's and add a warning to explain the vulnerability.



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

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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_66) - Build # 14849 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14849/
Java: 32bit/jdk1.8.0_66 -server -XX:+UseSerialGC

3 tests failed.
FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAliasTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([1B48264AB25F270A:931C19901CA34AF2]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:961)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAvroTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([1B48264AB25F270A:931C19901CA34AF2]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
at 
org

[jira] [Commented] (SOLR-8264) Date boosting losing to constant value in min function when date value is null

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8264:


This sounds like the correct behavior since Lucene/Solr 5.0 fixed bugs in 
several value sources.

As noted in the 5.0 upgrade instructions...

{noformat}
* Bugs fixed in several ValueSource functions may result in different behavior 
in 
  situations where some documents do not have values for fields wrapped in 
other value 
  sources.  Users who want to preserve the previous behavior may need to wrap 
fields
  in the "def()" function. Example: changing "fl=sum(fieldA,fieldB)" to 
  "fl=sum(def(fieldA,0.0),def(fieldB,0.0))".  See LUCENE-5961 for more details.
{noformat}

bq. And so the following boost works even though date_s doesn't exist for the 
particular record:

...that's because when not wrapped in a function like min or max, recip 
(wrapping ms) gives you a "fake" value based on the implicit assumption that a 
missing value should be treated a certain way ... but the "exists/missing" 
metadata is propagated up, and min/max know to choose "real" values when 
available.

Wrapping your "ms" in a "def()" call with a default of "0" should give you what 
you're looking for.

> Date boosting losing to constant value in min function when date value is null
> --
>
> Key: SOLR-8264
> URL: https://issues.apache.org/jira/browse/SOLR-8264
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Charles Draper
>Priority: Minor
>
> I am following https://wiki.apache.org/solr/FunctionQuery#Date_Boosting for 
> date boosting. This works great except when the date field is non-existent 
> and I attempt to set a maximum value. As I understand it, a non-existent date 
> field will default to the start of the epoch for functions. And so the 
> following boost works even though date_s doesn't exist for the particular 
> record:
> {code}
> recip(ms(NOW/YEAR,date_s),3.16e-11,1,1)
> 0.021798734 = 
> 1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0)
> {code}
> However, when I try to apply a min function, the constant value is always 
> selected whether it is greater or less than the recip calculation: 
> {code}
> min(1,recip(ms(NOW/YEAR,date_s),3.16e-11,1,1))
> 1.0 = 
> min(const(1),1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0))
> {code}
> I am currently getting around the issue by supplying a default value for the 
> field in my schema.xml.



--
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-7915) Provide pluggable Velocity context tool facility

[Erik Hatcher (JIRA)]

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

Erik Hatcher edited comment on SOLR-7915 at 11/9/15 9:19 PM:
-

I just tested this, thanks for asking [~arafalov] (on a clean branch_5x 
checkout) - 

{code}
bin/solr create -c files -d example/files
bin/post -c files ~/Documents/TestDocs
curl http://localhost:8983/solr/files/config -H 'Content-type:application/json' 
-d '{
  "add-queryresponsewriter":{
"name":"celeritas",
"class":"solr.VelocityResponseWriter",
"params.resource.loader.enabled": "true",
"tools":{
  "just_a_string":"java.lang.String"
}
  }
}'
{code}

It modifies configoverlay.json with:
{code}
{"queryResponseWriter":{"celeritas":{
  "name":"celeritas",
  "class":"solr.VelocityResponseWriter",
  "params.resource.loader.enabled":"true",
  "tools":{"just_a_string":"java.lang.String"
{code}

And that behaves as expected leveraging the new tool, 
http://localhost:8983/solr/files/select?q=*:*&wt=celeritas&v.template=foo&v.template.foo=$response.results.numFound:%20(and%20btw:%20just_a_string.class%20=%20$just_a_string.class)
 responds with:

{code}
328: (and btw: just_a_string.class = class java.lang.String)
{code}

The example really is a glorified version of outputting, through a Velocity 
template (provided in the request, and enabled by params resource loader), 
$just_a_string.class, showing that the tool $just_a_string was created and 
methods can be called on it.


was (Author: ehatcher):
I just tested this, thanks for asking [~arafalov] (on a clean branch_5x 
checkout) - 

{code}
bin/solr create -c files -d example/files
bin/post -c files ~/Documents/TestDocs
curl http://localhost:8983/solr/files/config -H 'Content-type:application/json' 
-d '{
  "add-queryresponsewriter":{
"name":"celeritas",
"class":"solr.VelocityResponseWriter",
"params.resource.loader.enabled": "true",
"tools":{
  "just_a_string":"java.lang.String"
}
  }
}'
{code}

It modifies configoverlay.json with:
{code}
{"queryResponseWriter":{"celeritas":{
  "name":"celeritas",
  "class":"solr.VelocityResponseWriter",
  "params.resource.loader.enabled":"true",
  "tools":{"just_a_string":"java.lang.String"
{code}

And that behaves as expected leveraging the new tool, 
http://localhost:8983/solr/files/select?q=*:*&wt=celeritas&v.template=foo&v.template.foo=$response.results.numFound:%20(and%20btw:%20just_a_string.class%20=%20$just_a_string.class)
 responds with:

{code}
328: (and btw: just_a_string.class = class java.lang.String)
{code}


> Provide pluggable Velocity context tool facility
> 
>
> Key: SOLR-7915
> URL: https://issues.apache.org/jira/browse/SOLR-7915
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Velocity
>Affects Versions: 5.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7915.patch
>
>
> Currently the "tools" placed in the VelocityResponseWriter's context are 
> hard-coded.  It can be very handy to be able to plug in 3rd party or custom 
> tools (just any ol' Java object a "tool" can be).
> Here's a list of the currently hard-coded tools: 
> https://github.com/apache/lucene-solr/blob/trunk/solr/contrib/velocity/src/java/org/apache/solr/response/VelocityResponseWriter.java#L189-L199
> 
> The implementation committed allows custom tools to be registered as part of 
> the VelocityResponseWriter definition in solrconfig.xml like this:
> {code}
>  class="solr.VelocityResponseWriter">
>   
> com.example.solr.velocity.MyTool
> 
>   
> 
> {code}



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

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

[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 2804 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2804/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.lucene.TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([E63050CDCB505F80:61B1ED60CF702584]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.lucene.TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler(TestMergeSchedulerExternal.java:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 1155 lines...]
   [junit4] Suite: org.apache.lucene.TestMergeSchedulerExternal
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestMergeSchedulerExternal 
-Dtests.method=testSubclassConcurrentMergeScheduler 
-Dtests.seed=E63050CDCB505F80 -Dtests.slow=true -Dtests.locale=fi 
-Dtests.timezone=Asia/Sakhalin -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.50s J1 | 
TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler <<<
   [junit4]> Throwable #1: java.lang.AssertionError
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([E

[jira] [Commented] (SOLR-7915) Provide pluggable Velocity context tool facility

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-7915:


I just tested this, thanks for asking [~arafalov] (on a clean branch_5x 
checkout) - 

{code}
bin/solr create -c files -d example/files
bin/post -c files ~/Documents/TestDocs
curl http://localhost:8983/solr/files/config -H 'Content-type:application/json' 
-d '{
  "add-queryresponsewriter":{
"name":"celeritas",
"class":"solr.VelocityResponseWriter",
"params.resource.loader.enabled": "true",
"tools":{
  "just_a_string":"java.lang.String"
}
  }
}'
{code}

It modifies configoverlay.json with:
{code}
{"queryResponseWriter":{"celeritas":{
  "name":"celeritas",
  "class":"solr.VelocityResponseWriter",
  "params.resource.loader.enabled":"true",
  "tools":{"just_a_string":"java.lang.String"
{code}

And that behaves as expected leveraging the new tool, 
http://localhost:8983/solr/files/select?q=*:*&wt=celeritas&v.template=foo&v.template.foo=$response.results.numFound:%20(and%20btw:%20just_a_string.class%20=%20$just_a_string.class)
 responds with:

{code}
328: (and btw: just_a_string.class = class java.lang.String)
{code}


> Provide pluggable Velocity context tool facility
> 
>
> Key: SOLR-7915
> URL: https://issues.apache.org/jira/browse/SOLR-7915
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Velocity
>Affects Versions: 5.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7915.patch
>
>
> Currently the "tools" placed in the VelocityResponseWriter's context are 
> hard-coded.  It can be very handy to be able to plug in 3rd party or custom 
> tools (just any ol' Java object a "tool" can be).
> Here's a list of the currently hard-coded tools: 
> https://github.com/apache/lucene-solr/blob/trunk/solr/contrib/velocity/src/java/org/apache/solr/response/VelocityResponseWriter.java#L189-L199
> 
> The implementation committed allows custom tools to be registered as part of 
> the VelocityResponseWriter definition in solrconfig.xml like this:
> {code}
>  class="solr.VelocityResponseWriter">
>   
> com.example.solr.velocity.MyTool
> 
>   
> 
> {code}



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

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

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2856 - Failure!

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAliasTest.test

Error Message:
Shards in the state does not match what we set:4 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:4 vs 3
at 
__randomizedtesting.SeedInfo.seed([C9B6AA7DEBFD66E3:41E295A745010B1B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:961)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAvroTest.test

Error Message:
Shards in the state does not match what we set:4 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:4 vs 3
at 
__randomizedtesting.SeedInfo.seed([C9B6AA7DEBFD66E3:41E295A745010B1B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
   

[jira] [Commented] (SOLR-8260) Use NIO2 APIs in core discovery

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8260:


bq. We should on working to disallow java.io.File throughout Solr!

I thought this had already been added to the forbidden apis config in the build 
system, but it seems that was only for Lucene.  I'm guessing that if we move it 
from the lucene config to the base config, Solr will pick it up as well.

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4
>
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



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

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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 601 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/601/

1 tests failed.
FAILED:  org.apache.solr.cloud.OverseerTest.testOverseerStatsReset

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

Stack Trace:
java.lang.AssertionError: expected:<0> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([79AB6D6C1EBA782:ACCE51EA5431048C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.OverseerTest.testOverseerStatsReset(OverseerTest.java:741)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 9967 lines...]
   [junit4] Suite: org.apache.solr.cloud.OverseerTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/sol

[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_66) - Build # 14558 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14558/
Java: 64bit/jdk1.8.0_66 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAliasTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([639D03C49CDD782B:EBC93C1E322115D3]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:961)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([639D03C49CDD782B:EBC93C1E322115D3]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)

[jira] [Commented] (SOLR-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[ASF subversion and git services (JIRA)]

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

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

Commit 1713530 from [~joel.bernstein] in branch 'dev/trunk'
[ https://svn.apache.org/r1713530 ]

SOLR-8262: Comment out /stream handler from sample solrconfig.xml's for 
security reasons

> Comment out /stream handler from sample solrconfig.xml's for security reasons
> -
>
> Key: SOLR-8262
> URL: https://issues.apache.org/jira/browse/SOLR-8262
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> Solr has apache commons-collections in it's classpath. 
> *This makes it vulnerable to this security issue 
> https://issues.apache.org/jira/browse/COLLECTIONS-580. 
> *The /stream handler uses Java serialization for RPC since Solr 5.1. 
> These two combined leave a security hole in Solr that allows arbitrary code 
> to be executed on the server.
> This ticket will comment out the /stream handler from the sample 
> solrconfig.xml's and add a warning to explain the vulnerability.



--
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-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8262 at 11/9/15 8:09 PM:
---

The next step is to remove Java serialization from the Streaming API entirely.

The Streaming API will use only the Streaming Expression language for RPC going 
forward.


was (Author: joel.bernstein):
The next step in this is to remove Java serialization from the Streaming API 
entirely.

The Streaming API will use only the Streaming Expression language for RPC going 
forward.

> Comment out /stream handler from sample solrconfig.xml's for security reasons
> -
>
> Key: SOLR-8262
> URL: https://issues.apache.org/jira/browse/SOLR-8262
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> Solr has apache commons-collections in it's classpath. 
> *This makes it vulnerable to this security issue 
> https://issues.apache.org/jira/browse/COLLECTIONS-580. 
> *The /stream handler uses Java serialization for RPC since Solr 5.1. 
> These two combined leave a security hole in Solr that allows arbitrary code 
> to be executed on the server.
> This ticket will comment out the /stream handler from the sample 
> solrconfig.xml's and add a warning to explain the vulnerability.



--
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-8266) Remove Java Serialization from the Streaming API

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-8266:


 Summary: Remove Java Serialization from the Streaming API
 Key: SOLR-8266
 URL: https://issues.apache.org/jira/browse/SOLR-8266
 Project: Solr
  Issue Type: Improvement
Reporter: Joel Bernstein


This is being done mainly for security reasons but it's also architecturally 
the right thing to do.

Going forward only Streaming Expressions will be used to serialize Streaming 
API Objects. 



--
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-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8262:
--

The next step in this is to remove Java serialization from the Streaming API 
entirely.

The Streaming API will use only the Streaming Expression language for RPC going 
forward.

> Comment out /stream handler from sample solrconfig.xml's for security reasons
> -
>
> Key: SOLR-8262
> URL: https://issues.apache.org/jira/browse/SOLR-8262
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> Solr has apache commons-collections in it's classpath. 
> *This makes it vulnerable to this security issue 
> https://issues.apache.org/jira/browse/COLLECTIONS-580. 
> *The /stream handler uses Java serialization for RPC since Solr 5.1. 
> These two combined leave a security hole in Solr that allows arbitrary code 
> to be executed on the server.
> This ticket will comment out the /stream handler from the sample 
> solrconfig.xml's and add a warning to explain the vulnerability.



--
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-8263) Tlog replication could interfere with the replay of buffered updates

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-8263:


Assignee: Erick Erickson

> Tlog replication could interfere with the replay of buffered updates
> 
>
> Key: SOLR-8263
> URL: https://issues.apache.org/jira/browse/SOLR-8263
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Renaud Delbru
>Assignee: Erick Erickson
>
> The current implementation of the tlog replication might interfere with the 
> replay of the buffered updates. The current tlog replication works as follow:
> 1) Fetch the the tlog files from the master
> 2) reset the update log before switching the tlog directory
> 3) switch the tlog directory and re-initialise the update log with the new 
> directory.
> Currently there is no logic to keep "buffered updates" while resetting and 
> reinitializing the update log.



--
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-8265) tweak election related trace (ElectionContext.java)

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8265:
---

Good points, hadn't considered {{MDCLoggingContext}} here, will check if that 
covers things.

> tweak election related trace (ElectionContext.java)
> ---
>
> Key: SOLR-8265
> URL: https://issues.apache.org/jira/browse/SOLR-8265
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8265.patch
>
>
> Tweak some trace to make it easier to identify (especially in a multi-shard 
> JVM) what the core or shard concerned is.



--
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-6406) ConcurrentUpdateSolrServer hang in blockUntilFinished.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-6406:
---

Strange. I got over 300 runs without an out of sync with it originally. I have 
not tried on recent trunk or recent changes though.

> ConcurrentUpdateSolrServer hang in blockUntilFinished.
> --
>
> Key: SOLR-6406
> URL: https://issues.apache.org/jira/browse/SOLR-6406
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Yonik Seeley
> Fix For: 5.4, Trunk
>
> Attachments: CPU Sampling.png, SOLR-6406.patch, SOLR-6406.patch, 
> SOLR-6406.patch
>
>
> Not sure what is causing this, but SOLR-6136 may have taken us a step back 
> here. I see this problem occasionally pop up in ChaosMonkeyNothingIsSafeTest 
> now - test fails because of a thread leak, thread leak is due to a 
> ConcurrentUpdateSolrServer hang in blockUntilFinished. Only started popping 
> up recently.



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

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

[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_66) - Build # 5256 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5256/
Java: 64bit/jdk1.8.0_66 -XX:-UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.test

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([D810BFCBBBAAA9A7:504480111556C45F]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.allTests(CloudSolrClientTest.java:272)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapte

[jira] [Updated] (LUCENE-6679) Filter's Weight.explain returns an explanation with isMatch==true even on documents that don't match

[Terry Smith (JIRA)]

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

Terry Smith updated LUCENE-6679:

Attachment: LUCENE-6679.patch

Here is an updated patch against trunk that adds hit and miss explain checks to 
AssertingLeafCollector and hooks it up with the surrounding classes.

I've also introduced a new annotation called SuppressExplainChecks that I've 
applied to the following tests that would fail without.

  * TestSortRandom
  * TestLazyProxSkipping
  * TestDrillSideways
  * TestRangeFacetCounts
  * TestJoinUtil
  * TestFieldCacheSortRandom
  * TestCustomScoreQuery
  * TestCustomScoreQueryExplanations
  * TestFunctionQueryExplanations
  * TestForTooMuchCloning
  * TestTermAutomationQuery

Once you are happy with this patch, I'd like to get it on trunk so the jenkins 
servers can shake out any more failures and we can create tickets for any 
uncovered bugs.



> Filter's Weight.explain returns an explanation with isMatch==true even on 
> documents that don't match
> 
>
> Key: LUCENE-6679
> URL: https://issues.apache.org/jira/browse/LUCENE-6679
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
> Attachments: LUCENE-6679.patch, LUCENE-6679.patch
>
>
> This was reported by Trejkaz on the java-user list: 
> http://search-lucene.com/m/l6pAi19h4Y3DclgB1&subj=Re+What+on+earth+is+FilteredQuery+explain+doing+



--
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-8265) tweak election related trace (ElectionContext.java)

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8265:
---

Yeah, I think we are trying to take these out of logging. We already have this 
in MDC and it just adds redundant info.

Some logging might be missing MDC injection or something, but in that case, 
that is probably what should be fixed.

> tweak election related trace (ElectionContext.java)
> ---
>
> Key: SOLR-8265
> URL: https://issues.apache.org/jira/browse/SOLR-8265
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8265.patch
>
>
> Tweak some trace to make it easier to identify (especially in a multi-shard 
> JVM) what the core or shard concerned is.



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

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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_66) - Build # 14848 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14848/
Java: 32bit/jdk1.8.0_66 -client -XX:+UseG1GC

3 tests failed.
FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAliasTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([2EC0722843D9B008:A6944DF2ED25DDF0]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:961)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAvroTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([2EC0722843D9B008:A6944DF2ED25DDF0]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
at 
org.apa

[jira] [Commented] (SOLR-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8262:
-

+1 please disable this like the remote input streaming apis (stream.body, 
stream.url & Co.)

> Comment out /stream handler from sample solrconfig.xml's for security reasons
> -
>
> Key: SOLR-8262
> URL: https://issues.apache.org/jira/browse/SOLR-8262
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> Solr has apache commons-collections in it's classpath. 
> *This makes it vulnerable to this security issue 
> https://issues.apache.org/jira/browse/COLLECTIONS-580. 
> *The /stream handler uses Java serialization for RPC since Solr 5.1. 
> These two combined leave a security hole in Solr that allows arbitrary code 
> to be executed on the server.
> This ticket will comment out the /stream handler from the sample 
> solrconfig.xml's and add a warning to explain the vulnerability.



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

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

Re: Next release...

[Susheel Kumar]

CDCR will help many of the folks who are currently trying other
alternatives. Would love to see coming this out sooner and providing
feedback.

On Mon, Nov 9, 2015 at 1:16 PM, Upayavira  wrote:

> I would love to see a 5.4 release. All the tasks I had planned for the
> admin UI are done, so, barring any unforseen and as yet unreported bugs,
> it is ready to go.
>
> How much time commitment does it typically take to make a release? I'd
> consider volunteering, but may not have sufficient time to carry it all
> the way.
>
> Upayavira
>
> On Mon, Nov 9, 2015, at 04:10 PM, Erick Erickson wrote:
> > Adrien:
> >
> > I can certainly wait for a while to commit CDCR to 5.4, there's no
> > huge need to rush 5.4 out the door, particularly not just to
> > accommodate me! After all, let's just say it's been a while that we've
> > been working on this, a bit more time isn't critical
> >
> > I don't want to wait a month though, so if someone is already thinking
> > of branching for 5.4 anyway so I asked to I can plan around it.
> >
> > Erick
> >
> > On Mon, Nov 9, 2015 at 8:00 AM, Adrien Grand  wrote:
> > > Le lun. 9 nov. 2015 à 16:32, Erick Erickson 
> a
> > > écrit :
> > >>
> > >> What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
> > >> is about ready to rock-n-roll. It's a lot of code, and I don't want to
> > >> push it into 5x just before we cut the next release. So if 5.4 is
> > >> imminent I'd like to know for my planning.
> > >
> > >
> > > I think that we should release Lucene 5.4 soon indeed! Maybe we could
> create
> > > a 5.4 branch today already so that you can commit the CDCR changes.
> This
> > > will also help make sure that the 5.4 branch only gets bug fixes as of
> today
> > > and then we have one week to make sure things are stable and we can
> start
> > > the release process next week?
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Updated] (SOLR-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8262:
-
Description: 
Solr has apache commons-collections in it's classpath. 

*This makes it vulnerable to this security issue 
https://issues.apache.org/jira/browse/COLLECTIONS-580. 
*The /stream handler uses Java serialization for RPC since Solr 5.1. 

These two combined leave a security hole in Solr that allows arbitrary code to 
be executed on the server.

This ticket will comment out the /stream handler from the sample 
solrconfig.xml's and add a warning to explain the vulnerability.

  was:
The /stream handler uses Java serialization for RPC. This presents a security 
risk because it allows anyone with access to the Solr ip/port to send arbitrary 
serialized objects to Solr.

This should not be on by default.

This ticket will comment out the /stream handler from the sample 
solrconfig.xml's and add a warning stating that this feature relies on Java 
serialization for RPC.


> Comment out /stream handler from sample solrconfig.xml's for security reasons
> -
>
> Key: SOLR-8262
> URL: https://issues.apache.org/jira/browse/SOLR-8262
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> Solr has apache commons-collections in it's classpath. 
> *This makes it vulnerable to this security issue 
> https://issues.apache.org/jira/browse/COLLECTIONS-580. 
> *The /stream handler uses Java serialization for RPC since Solr 5.1. 
> These two combined leave a security hole in Solr that allows arbitrary code 
> to be executed on the server.
> This ticket will comment out the /stream handler from the sample 
> solrconfig.xml's and add a warning to explain the vulnerability.



--
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-8265) tweak election related trace (ElectionContext.java)

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8265:


Can we better leverage the MDC here for such logging as node name, replica 
name, core name etc.?

> tweak election related trace (ElectionContext.java)
> ---
>
> Key: SOLR-8265
> URL: https://issues.apache.org/jira/browse/SOLR-8265
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8265.patch
>
>
> Tweak some trace to make it easier to identify (especially in a multi-shard 
> JVM) what the core or shard concerned is.



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

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

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_66) - Build # 5386 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5386/
Java: 64bit/jdk1.8.0_66 -XX:+UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
ERROR: SolrIndexSearcher opens=51 closes=50

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50
at __randomizedtesting.SeedInfo.seed([682B6DB98C986A08]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:468)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:234)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:829)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=12948, name=searcherExecutor-6031-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=12948, name=searcherExecutor-6031-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([682B6DB98C986A08]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=12948, nam

[jira] [Updated] (SOLR-8265) tweak election related trace (ElectionContext.java)

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-8265:
--
Attachment: SOLR-8265.patch

attaching proposed patch against trunk

> tweak election related trace (ElectionContext.java)
> ---
>
> Key: SOLR-8265
> URL: https://issues.apache.org/jira/browse/SOLR-8265
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8265.patch
>
>
> Tweak some trace to make it easier to identify (especially in a multi-shard 
> JVM) what the core or shard concerned is.



--
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-8265) tweak election related trace (ElectionContext.java)

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-8265:
-

 Summary: tweak election related trace (ElectionContext.java)
 Key: SOLR-8265
 URL: https://issues.apache.org/jira/browse/SOLR-8265
 Project: Solr
  Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor


Tweak some trace to make it easier to identify (especially in a multi-shard 
JVM) what the core or shard concerned is.




--
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-6874) WhitespaceTokenizer should tokenize on NBSP

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6874:
--

Sorry, I really disagree with you on this.  I don't think this 
WhitespaceTokenizerFactory is hard to maintain at all.  It's true that it's 
harder only because it was a trivial factory before but so what?  Most 
importantly, I think it's a better user experience -- nobody should care what 
the specific Java Tokenizer implementation class will be coming out of the 
factory -- it's a tokenizer on whitespace using whatever definition/rule of 
whitespace they configured.  That could hypothetically be implemented using one 
Java Tokenizer implementing class or multiple but that's an implementation 
detail.

bq. Why is the ICUWhitespace being added?

I'll remove that in a new patch; I wasn't sure what to do but it's redundant so 
no need for it.



> WhitespaceTokenizer should tokenize on NBSP
> ---
>
> Key: LUCENE-6874
> URL: https://issues.apache.org/jira/browse/LUCENE-6874
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: David Smiley
>Priority: Minor
> Attachments: LUCENE-6874-jflex.patch, LUCENE-6874.patch, 
> LUCENE_6874_jflex.patch
>
>
> WhitespaceTokenizer uses [Character.isWhitespace 
> |http://docs.oracle.com/javase/8/docs/api/java/lang/Character.html#isWhitespace-int-]
>  to decide what is whitespace.  Here's a pertinent excerpt:
> bq. It is a Unicode space character (SPACE_SEPARATOR, LINE_SEPARATOR, or 
> PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0', 
> '\u2007', '\u202F')
> Perhaps Character.isWhitespace should have been called 
> isLineBreakableWhitespace?
> I think WhitespaceTokenizer should tokenize on this.  I am aware it's easy to 
> work around but why leave this trap in by default?



--
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-8260) Use NIO2 APIs in core discovery

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-8260:
-

bq. We should on working to disallow java.io.File throughout Solr!

That would be great, but I think it might take a while!

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4
>
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



--
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-8255) MiniSolrCloudCluster doesn't use a thread-safe list for its jetties

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8255:

Fix Version/s: 5.4

> MiniSolrCloudCluster doesn't use a thread-safe list for its jetties
> ---
>
> Key: SOLR-8255
> URL: https://issues.apache.org/jira/browse/SOLR-8255
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4
>
>
> MiniSolrCloudCluster uses a LinkedList<> to hold its jetties.  However, 
> multi-threaded startup can break this because the list isn't thread safe.  We 
> should use CopyOnWriteArrayList instead.
> See for example 
> http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14819/, which starts 
> up 5 nodes but then only has 4 entries in its jetty list, causing assertion 
> errors and thread leaks.



--
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-8260) Use NIO2 APIs in core discovery

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8260:

Fix Version/s: 5.4

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4
>
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



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

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

Re: Next release...

[Upayavira]

I would love to see a 5.4 release. All the tasks I had planned for the
admin UI are done, so, barring any unforseen and as yet unreported bugs,
it is ready to go.

How much time commitment does it typically take to make a release? I'd
consider volunteering, but may not have sufficient time to carry it all
the way.

Upayavira

On Mon, Nov 9, 2015, at 04:10 PM, Erick Erickson wrote:
> Adrien:
> 
> I can certainly wait for a while to commit CDCR to 5.4, there's no
> huge need to rush 5.4 out the door, particularly not just to
> accommodate me! After all, let's just say it's been a while that we've
> been working on this, a bit more time isn't critical
> 
> I don't want to wait a month though, so if someone is already thinking
> of branching for 5.4 anyway so I asked to I can plan around it.
> 
> Erick
> 
> On Mon, Nov 9, 2015 at 8:00 AM, Adrien Grand  wrote:
> > Le lun. 9 nov. 2015 à 16:32, Erick Erickson  a
> > écrit :
> >>
> >> What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
> >> is about ready to rock-n-roll. It's a lot of code, and I don't want to
> >> push it into 5x just before we cut the next release. So if 5.4 is
> >> imminent I'd like to know for my planning.
> >
> >
> > I think that we should release Lucene 5.4 soon indeed! Maybe we could create
> > a 5.4 branch today already so that you can commit the CDCR changes. This
> > will also help make sure that the 5.4 branch only gets bug fixes as of today
> > and then we have one week to make sure things are stable and we can start
> > the release process next week?
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

[jira] [Updated] (SOLR-8254) HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8254:

Fix Version/s: 5.4

> HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up
> -
>
> Key: SOLR-8254
> URL: https://issues.apache.org/jira/browse/SOLR-8254
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4
>
>
> See http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5254/



--
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-8253) AbstractDistribZkTestBase can fail to shutdown its ZkServer

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8253:

Fix Version/s: 5.4

> AbstractDistribZkTestBase can fail to shutdown its ZkServer
> ---
>
> Key: SOLR-8253
> URL: https://issues.apache.org/jira/browse/SOLR-8253
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
> Fix For: 5.4
>
>
> If there's an error shutting down the jetty servers, then zkServer.shutdown() 
> won't get called.  This ends up hiding actual errors from test failures with 
> thread-leak messages.



--
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-5409) core.properties file is not removed.

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-5409.
-
   Resolution: Fixed
 Assignee: Alan Woodward
Fix Version/s: (was: 4.9)
   5.4

Fixed by SOLR-8260

> core.properties file is not removed.
> 
>
> Key: SOLR-5409
> URL: https://issues.apache.org/jira/browse/SOLR-5409
> Project: Solr
>  Issue Type: Bug
>Reporter: Doug Ericson
>Assignee: Alan Woodward
> Fix For: 5.4, Trunk
>
>
> The core.properties file is renamed to core.properties.unloaded when a core 
> is unloaded. However if the core is reloaded a new core.properties file is 
> created. This can put a core in a state where it cannot be re-loaded without 
> removing the core.properties file.
> Steps to reproduce using the web admin UI:
> # Create a core
> # Unload the core
> # Create the core again
> # Unload the core
> # Create the core again
> Expected Results:
> The core should be created after the last step.
> Observed Results:
> The last step fails because core.properties already exists and has not been 
> renamed to core.properties.unloaded since that file already exists. This puts 
> the core in a between state of being unloaded but unable to be re-loaded.



--
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-8260) Use NIO2 APIs in core discovery

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8260:
-

Thanks Alan! I like this very much. We should on working to disallow 
java.io.File throughout Solr! :-)

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



--
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-8264) Date boosting losing to constant value in min function when date value is null

[Charles Draper (JIRA)]

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

Charles Draper updated SOLR-8264:
-
Description: 
I am following https://wiki.apache.org/solr/FunctionQuery#Date_Boosting for 
date boosting. This works great except when the date field is non-existent and 
I attempt to set a maximum value. As I understand it, a non-existent date field 
will default to the start of the epoch for functions. And so the following 
boost works even though date_s doesn't exist for the particular record:

{code}
recip(ms(NOW/YEAR,date_s),3.16e-11,1,1)

0.021798734 = 
1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0)
{code}

However, when I try to apply a min function, the constant value is always 
selected whether it is greater or less than the recip calculation: 

{code}
min(1,recip(ms(NOW/YEAR,date_s),3.16e-11,1,1))

1.0 = 
min(const(1),1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0))
{code}

I am currently getting around the issue by supplying a default value for the 
field in my schema.xml.

  was:
I am following https://wiki.apache.org/solr/FunctionQuery#Date_Boosting for 
date boosting. This works great except when the date field is non-existent and 
I attempt to set a maximum value. As I understand it, a non-existent date field 
will default to the start of the epoch for functions. And so the following 
boost works even though date_s doesn't exist for the particular record:

{code}
recip(ms(NOW/YEAR,date_s),3.16e-11,1,1)
0.021798734 = 
1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0)
{code}

However, when I try to apply a min function, the constant value is always 
selected whether it is greater or less than the recip calculation: 

{code}
min(1,recip(ms(NOW/YEAR,date_s),3.16e-11,1,1))
1.0 = 
min(const(1),1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0))
{code}

I am currently getting around the issue by supplying a default value for the 
field in my schema.xml.


> Date boosting losing to constant value in min function when date value is null
> --
>
> Key: SOLR-8264
> URL: https://issues.apache.org/jira/browse/SOLR-8264
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Charles Draper
>Priority: Minor
>
> I am following https://wiki.apache.org/solr/FunctionQuery#Date_Boosting for 
> date boosting. This works great except when the date field is non-existent 
> and I attempt to set a maximum value. As I understand it, a non-existent date 
> field will default to the start of the epoch for functions. And so the 
> following boost works even though date_s doesn't exist for the particular 
> record:
> {code}
> recip(ms(NOW/YEAR,date_s),3.16e-11,1,1)
> 0.021798734 = 
> 1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0)
> {code}
> However, when I try to apply a min function, the constant value is always 
> selected whether it is greater or less than the recip calculation: 
> {code}
> min(1,recip(ms(NOW/YEAR,date_s),3.16e-11,1,1))
> 1.0 = 
> min(const(1),1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0))
> {code}
> I am currently getting around the issue by supplying a default value for the 
> field in my schema.xml.



--
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-8260) Use NIO2 APIs in core discovery

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-8260.
-
Resolution: Fixed

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



--
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-8264) Date boosting losing to constant value in min function when date value is null

[Charles Draper (JIRA)]

Charles Draper created SOLR-8264:


 Summary: Date boosting losing to constant value in min function 
when date value is null
 Key: SOLR-8264
 URL: https://issues.apache.org/jira/browse/SOLR-8264
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3
Reporter: Charles Draper
Priority: Minor


I am following https://wiki.apache.org/solr/FunctionQuery#Date_Boosting for 
date boosting. This works great except when the date field is non-existent and 
I attempt to set a maximum value. As I understand it, a non-existent date field 
will default to the start of the epoch for functions. And so the following 
boost works even though date_s doesn't exist for the particular record:

{code}
recip(ms(NOW/YEAR,date_s),3.16e-11,1,1)
0.021798734 = 
1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0)
{code}

However, when I try to apply a min function, the constant value is always 
selected whether it is greater or less than the recip calculation: 

{code}
min(1,recip(ms(NOW/YEAR,date_s),3.16e-11,1,1))
1.0 = 
min(const(1),1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0))
{code}

I am currently getting around the issue by supplying a default value for the 
field in my schema.xml.



--
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-8263) Tlog replication could interfere with the replay of buffered updates

[Renaud Delbru (JIRA)]

Renaud Delbru created SOLR-8263:
---

 Summary: Tlog replication could interfere with the replay of 
buffered updates
 Key: SOLR-8263
 URL: https://issues.apache.org/jira/browse/SOLR-8263
 Project: Solr
  Issue Type: Sub-task
Reporter: Renaud Delbru


The current implementation of the tlog replication might interfere with the 
replay of the buffered updates. The current tlog replication works as follow:
1) Fetch the the tlog files from the master
2) reset the update log before switching the tlog directory
3) switch the tlog directory and re-initialise the update log with the new 
directory.
Currently there is no logic to keep "buffered updates" while resetting and 
reinitializing the update log.



--
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-8260) Use NIO2 APIs in core discovery

[ASF subversion and git services (JIRA)]

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

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

Commit 1713498 from [~romseygeek] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1713498 ]

SOLR-8260: Use nio2 API in core discovery

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



--
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-8261) Change the wrapped per-field default in SchemaSimilarityFactory to BM25 (conditional on luceneMatchVersion for backcompat)

[Hoss Man (JIRA)]

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

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

Quick patch extracted from my older patch in SOLR-8057 ...

* SchemaSimilarityFactory udpated to use BM25 if luceneMatchVersion >= 6
* cloned TestPerFieldSimilarity as TestPerFieldSimilarityClassic
** TestPerFieldSimilarityClassic set's older luceneMatchVersion
** TestPerFieldSimilarity updated to account for new BM25 defaults

...tests & precommit currently pass, but I want to re-review more closely in 
isolation and think about any other tests that should be added before 
committing.



> Change the wrapped per-field default in SchemaSimilarityFactory to BM25 
> (conditional on luceneMatchVersion for backcompat)
> --
>
> Key: SOLR-8261
> URL: https://issues.apache.org/jira/browse/SOLR-8261
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: Trunk
>
> Attachments: SOLR-8261.patch
>
>
> As outlined in parent issue...
> * use ClassicSimilarity as per-field default when luceneMatchVersion < 6.0
> * use BM25Similarity as per-field default when luceneMatchVersion < 6.0



--
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-8260) Use NIO2 APIs in core discovery

[ASF subversion and git services (JIRA)]

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

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

Commit 1713490 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1713490 ]

SOLR-8260: Use nio2 API in core discovery

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



--
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-8249) OverseerTest failures

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8249:
--

I've been running the following, over 5000 iterations each for patched and 
unpatched trunk, and only had one failure on unpatched - I'll include the log 
below.  Here's the cmdline I'm using:

{noformat}
(for a in {1..1000} ; do ant test -Dtestcase=OverseerTest 
-Dtests.method=testOverseerStatsReset -Dtests.dups=10 -Dtests.jvms=10 ; done) 
2>&1 | tee ../../test.output
{noformat}

Here's the failure from unpatched trunk:

{noformat}
   [junit4] Suite: org.apache.solr.cloud.OverseerTest
   [junit4]   2> Creating dataDir: 
/home/sarowe/svn/lucene/dev/trunk/solr/build/solr-core/test/J3/temp/solr.cloud.OverseerTest_D0EFDBDB7BF104A-001/init-core-data-001
   [junit4]   2> 0INFO  (SUITE-OverseerTest-seed#[D0EFDBDB7BF104A]-worker) 
[] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true)
   [junit4]   2> 69   INFO  (SUITE-OverseerTest-seed#[D0EFDBDB7BF104A]-worker) 
[] o.a.s.SolrTestCaseJ4 initCore
   [junit4]   2> 72   INFO  (SUITE-OverseerTest-seed#[D0EFDBDB7BF104A]-worker) 
[] o.a.s.SolrTestCaseJ4 initCore end
   [junit4]   2> 83   INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.SolrTestCaseJ4 ###Starting testOverseerStatsReset
   [junit4]   2> 92   INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 105  INFO  (Thread-1) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 106  INFO  (Thread-1) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 194  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.ZkTestServer start zk server on port:36981
   [junit4]   2> 213  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 245  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 384  INFO  (zkCallback-1-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@121063b4 
name:ZooKeeperConnection Watcher:127.0.0.1:36981 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 385  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 386  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 414  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 415  WARN  (NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0) [] 
o.a.z.s.NIOServerCnxn caught end of stream exception
   [junit4]   2> EndOfStreamException: Unable to read additional data from 
client sessionid 0x150ed0c2d8d, likely client has closed socket
   [junit4]   2>at 
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228)
   [junit4]   2>at 
org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
   [junit4]   2>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> 454  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 457  INFO  (zkCallback-2-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@4c1e7367 
name:ZooKeeperConnection Watcher:127.0.0.1:36981 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 457  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 457  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 458  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 467  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 468  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 470  INFO  (zkCallback-3-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@

[jira] [Created] (SOLR-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-8262:


 Summary: Comment out /stream handler from sample solrconfig.xml's 
for security reasons
 Key: SOLR-8262
 URL: https://issues.apache.org/jira/browse/SOLR-8262
 Project: Solr
  Issue Type: Bug
Reporter: Joel Bernstein


The /stream handler uses Java serialization for RPC. This presents a security 
risk because it allows anyone with access to the Solr ip/port to send arbitrary 
serialized objects to Solr.

This should not be on by default.

This ticket will comment out the /stream handler from the sample 
solrconfig.xml's and add a warning stating that this feature relies on Java 
serialization for RPC.



--
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-8261) Change the wrapped per-field default in SchemaSimilarityFactory to BM25 (conditional on luceneMatchVersion for backcompat)

[Hoss Man (JIRA)]

Hoss Man created SOLR-8261:
--

 Summary: Change the wrapped per-field default in 
SchemaSimilarityFactory to BM25 (conditional on luceneMatchVersion for 
backcompat)
 Key: SOLR-8261
 URL: https://issues.apache.org/jira/browse/SOLR-8261
 Project: Solr
  Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: Trunk


As outlined in parent issue...

* use ClassicSimilarity as per-field default when luceneMatchVersion < 6.0
* use BM25Similarity as per-field default when luceneMatchVersion < 6.0





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

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

[JENKINS] Lucene-Solr-5.x-Solaris (multiarch/jdk1.7.0) - Build # 176 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/176/
Java: multiarch/jdk1.7.0 -d32 -client -XX:+UseSerialGC

3 tests failed.
FAILED:  
org.apache.solr.cloud.AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:51396 within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:51396 within 3 ms
at 
__randomizedtesting.SeedInfo.seed([93B6D69FB1B9C1F4:C9B7B3739F834C2D]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:181)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:110)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:97)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.printLayout(AbstractDistribZkTestBase.java:280)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.distribTearDown(AbstractFullDistribZkTestBase.java:1475)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.concurrent.TimeoutException: Could not connect to 
ZooKeeper 127.0.0.1:51396 within 3 ms
at 
org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:208)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:173)
... 37 more


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

[jira] [Commented] (SOLR-7915) Provide pluggable Velocity context tool facility

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-7915:


paramsets are for search handlers, so doesn't relate to this.  But definitely 
the REST API should be able to handle this.  I've not tested that, but it is 
legitimate response writer configuration capabilities being used here.  

> Provide pluggable Velocity context tool facility
> 
>
> Key: SOLR-7915
> URL: https://issues.apache.org/jira/browse/SOLR-7915
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Velocity
>Affects Versions: 5.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7915.patch
>
>
> Currently the "tools" placed in the VelocityResponseWriter's context are 
> hard-coded.  It can be very handy to be able to plug in 3rd party or custom 
> tools (just any ol' Java object a "tool" can be).
> Here's a list of the currently hard-coded tools: 
> https://github.com/apache/lucene-solr/blob/trunk/solr/contrib/velocity/src/java/org/apache/solr/response/VelocityResponseWriter.java#L189-L199
> 
> The implementation committed allows custom tools to be registered as part of 
> the VelocityResponseWriter definition in solrconfig.xml like this:
> {code}
>  class="solr.VelocityResponseWriter">
>   
> com.example.solr.velocity.MyTool
> 
>   
> 
> {code}



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

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

[jira] [Updated] (SOLR-8260) Use NIO2 APIs in core discovery

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8260:

Attachment: SOLR-8260.patch

Patch.  Tests pass, running precommit now.

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



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

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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 600 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/600/

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

Error Message:
[/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_5A1D3AAAECC2027-001/solr-instance-028/./collection1/data,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_5A1D3AAAECC2027-001/solr-instance-028/./collection1/data/index.20151109075210523,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_5A1D3AAAECC2027-001/solr-instance-028/./collection1/data/index.20151109075210628]
 expected:<2> but was:<3>

Stack Trace:
java.lang.AssertionError: 
[/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_5A1D3AAAECC2027-001/solr-instance-028/./collection1/data,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_5A1D3AAAECC2027-001/solr-instance-028/./collection1/data/index.20151109075210523,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_5A1D3AAAECC2027-001/solr-instance-028/./collection1/data/index.20151109075210628]
 expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([5A1D3AAAECC2027:F2D23DF268248FC1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:813)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1243)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowin

[jira] [Created] (SOLR-8260) Use NIO2 APIs in core discovery

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-8260:
---

 Summary: Use NIO2 APIs in core discovery
 Key: SOLR-8260
 URL: https://issues.apache.org/jira/browse/SOLR-8260
 Project: Solr
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward


CorePropertiesLocator currently does all its file system interaction using 
java.io.File and friends, which have all sorts of drawbacks with regard to 
error handling and reporting.  We've been on java 7 for a while now, so we 
should use the nio2 Path APIs instead.



--
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-7915) Provide pluggable Velocity context tool facility

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7915:
-

Will this also be configurable through the other ways we do it? paramsets, 
REST, etc? Not sure if  ** would cause issues. [~noble.paul]?

> Provide pluggable Velocity context tool facility
> 
>
> Key: SOLR-7915
> URL: https://issues.apache.org/jira/browse/SOLR-7915
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Velocity
>Affects Versions: 5.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7915.patch
>
>
> Currently the "tools" placed in the VelocityResponseWriter's context are 
> hard-coded.  It can be very handy to be able to plug in 3rd party or custom 
> tools (just any ol' Java object a "tool" can be).
> Here's a list of the currently hard-coded tools: 
> https://github.com/apache/lucene-solr/blob/trunk/solr/contrib/velocity/src/java/org/apache/solr/response/VelocityResponseWriter.java#L189-L199
> 
> The implementation committed allows custom tools to be registered as part of 
> the VelocityResponseWriter definition in solrconfig.xml like this:
> {code}
>  class="solr.VelocityResponseWriter">
>   
> com.example.solr.velocity.MyTool
> 
>   
> 
> {code}



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

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

[jira] [Commented] (SOLR-7219) Access filter cache from lucene query syntax

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7219:
-

Could we add this to the Changes file or somewhere else as an example then. It 
is both super cool and completely non-intuitive. 

> Access filter cache from lucene query syntax
> 
>
> Key: SOLR-7219
> URL: https://issues.apache.org/jira/browse/SOLR-7219
> Project: Solr
>  Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 5.4
>
> Attachments: SOLR-7219.patch
>
>
> A filter query retrieves a set of documents matching a query from the filter 
> cache. Since scores are not cached, all documents that match the filter 
> produce the same score. Cached filters will be extremely fast when they are 
> used again in another query.
> Filter Query Example:
> {code}
> description:HDTV OR filter(+promotion:tv +promotion_date:[NOW/DAY-7DAYS TO 
> NOW/DAY+1DAY])
> {code}
> The power of the filter() syntax is that it may be used anywhere within a 
> lucene/solr query syntax. Normal fq support is limited to top-level 
> conjunctions. 



--
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-7219) Access filter cache from lucene query syntax

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-7219:


bq. Does this allow to OR the filter queries efficiently?

Yep,
fq=filter(foo) filter(bar) filter(baz)

Although we could prob do it more efficiently in the future.  The current 
solution will use lucene's disjunction scorer, but we can get more efficient 
than that if we know we are dealing with DocSets.

> Access filter cache from lucene query syntax
> 
>
> Key: SOLR-7219
> URL: https://issues.apache.org/jira/browse/SOLR-7219
> Project: Solr
>  Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 5.4
>
> Attachments: SOLR-7219.patch
>
>
> A filter query retrieves a set of documents matching a query from the filter 
> cache. Since scores are not cached, all documents that match the filter 
> produce the same score. Cached filters will be extremely fast when they are 
> used again in another query.
> Filter Query Example:
> {code}
> description:HDTV OR filter(+promotion:tv +promotion_date:[NOW/DAY-7DAYS TO 
> NOW/DAY+1DAY])
> {code}
> The power of the filter() syntax is that it may be used anywhere within a 
> lucene/solr query syntax. Normal fq support is limited to top-level 
> conjunctions. 



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

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

[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 176 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/176/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.security.TestAuthorizationFramework.authorizationFrameworkTest

Error Message:
There are still nodes recoverying - waited for 10 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 10 
seconds
at 
__randomizedtesting.SeedInfo.seed([30A6C9E7769FB0A6:7E05BC346744A1B6]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:836)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1393)
at 
org.apache.solr.security.TestAuthorizationFramework.authorizationFrameworkTest(TestAuthorizationFramework.java:60)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.ev

[jira] [Commented] (SOLR-7219) Access filter cache from lucene query syntax

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7219:
-

Does this allow to OR the filter queries efficiently? That was always the 
limitation of **fq** that you could only effectively AND them.

If it does, we should document that rather prominently to make people happy.

> Access filter cache from lucene query syntax
> 
>
> Key: SOLR-7219
> URL: https://issues.apache.org/jira/browse/SOLR-7219
> Project: Solr
>  Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 5.4
>
> Attachments: SOLR-7219.patch
>
>
> A filter query retrieves a set of documents matching a query from the filter 
> cache. Since scores are not cached, all documents that match the filter 
> produce the same score. Cached filters will be extremely fast when they are 
> used again in another query.
> Filter Query Example:
> {code}
> description:HDTV OR filter(+promotion:tv +promotion_date:[NOW/DAY-7DAYS TO 
> NOW/DAY+1DAY])
> {code}
> The power of the filter() syntax is that it may be used anywhere within a 
> lucene/solr query syntax. Normal fq support is limited to top-level 
> conjunctions. 



--
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-8254) HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-8254.
-
Resolution: Fixed
  Assignee: Alan Woodward

> HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up
> -
>
> Key: SOLR-8254
> URL: https://issues.apache.org/jira/browse/SOLR-8254
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>
> See http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5254/



--
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-8254) HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up

[ASF subversion and git services (JIRA)]

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

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

Commit 1713471 from [~romseygeek] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1713471 ]

SOLR-8254: HttpSolrCore.getCoreByCollection() can throw NPE

> HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up
> -
>
> Key: SOLR-8254
> URL: https://issues.apache.org/jira/browse/SOLR-8254
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>
> See http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5254/



--
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-8254) HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up

[ASF subversion and git services (JIRA)]

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

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

Commit 1713468 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1713468 ]

SOLR-8254: HttpSolrCore.getCoreByCollection() can throw NPE

> HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up
> -
>
> Key: SOLR-8254
> URL: https://issues.apache.org/jira/browse/SOLR-8254
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>
> See http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5254/



--
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-8254) HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-8254:
-

bq. I don't know, we do not tend to put a lot of SolrCloud specific methods on 
CoreContainer.

Fair enough, I'll leave it where it is.

bq. Can static analysis of code help here uncover such bugs?

Almost certainly - IntelliJ showed me the error immediately when I looked at 
the code.  I have a feeling that this has come up before, but getting the whole 
codebase to pass will be a pretty big job.

> HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up
> -
>
> Key: SOLR-8254
> URL: https://issues.apache.org/jira/browse/SOLR-8254
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>
> See http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5254/



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

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

Re: Next release...

[Erick Erickson]

Adrien:

I can certainly wait for a while to commit CDCR to 5.4, there's no
huge need to rush 5.4 out the door, particularly not just to
accommodate me! After all, let's just say it's been a while that we've
been working on this, a bit more time isn't critical

I don't want to wait a month though, so if someone is already thinking
of branching for 5.4 anyway so I asked to I can plan around it.

Erick

On Mon, Nov 9, 2015 at 8:00 AM, Adrien Grand  wrote:
> Le lun. 9 nov. 2015 à 16:32, Erick Erickson  a
> écrit :
>>
>> What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
>> is about ready to rock-n-roll. It's a lot of code, and I don't want to
>> push it into 5x just before we cut the next release. So if 5.4 is
>> imminent I'd like to know for my planning.
>
>
> I think that we should release Lucene 5.4 soon indeed! Maybe we could create
> a 5.4 branch today already so that you can commit the CDCR changes. This
> will also help make sure that the 5.4 branch only gets bug fixes as of today
> and then we have one week to make sure things are stable and we can start
> the release process next week?

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

[jira] [Updated] (SOLR-6406) ConcurrentUpdateSolrServer hang in blockUntilFinished.

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-6406:
---
Fix Version/s: (was: 5.0)
   5.4

> ConcurrentUpdateSolrServer hang in blockUntilFinished.
> --
>
> Key: SOLR-6406
> URL: https://issues.apache.org/jira/browse/SOLR-6406
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Yonik Seeley
> Fix For: 5.4, Trunk
>
> Attachments: CPU Sampling.png, SOLR-6406.patch, SOLR-6406.patch, 
> SOLR-6406.patch
>
>
> Not sure what is causing this, but SOLR-6136 may have taken us a step back 
> here. I see this problem occasionally pop up in ChaosMonkeyNothingIsSafeTest 
> now - test fails because of a thread leak, thread leak is due to a 
> ConcurrentUpdateSolrServer hang in blockUntilFinished. Only started popping 
> up recently.



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

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

Re: Next release...

[Adrien Grand]

Le lun. 9 nov. 2015 à 16:32, Erick Erickson  a
écrit :

> What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
> is about ready to rock-n-roll. It's a lot of code, and I don't want to
> push it into 5x just before we cut the next release. So if 5.4 is
> imminent I'd like to know for my planning.
>

I think that we should release Lucene 5.4 soon indeed! Maybe we could
create a 5.4 branch today already so that you can commit the CDCR changes.
This will also help make sure that the 5.4 branch only gets bug fixes as of
today and then we have one week to make sure things are stable and we can
start the release process next week?

Re: Next release...

[Jack Krupansky]

Bummer... the prospect of Credence Clearwater Revival having a new release
had me going there.

-- Jack Krupansky

On Mon, Nov 9, 2015 at 10:35 AM, Erick Erickson 
wrote:

> Make that CDCR
>
> On Mon, Nov 9, 2015 at 7:32 AM, Erick Erickson 
> wrote:
> > What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
> > is about ready to rock-n-roll. It's a lot of code, and I don't want to
> > push it into 5x just before we cut the next release. So if 5.4 is
> > imminent I'd like to know for my planning.
> >
> > Thanks!
> > Erick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Updated] (SOLR-8259) Add getCoreContainer() method to JettySolrRunner

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8259:

Summary: Add getCoreContainer() method to JettySolrRunner  (was: Add 
getCoreContainer() method to SolrJettyRunner)

> Add getCoreContainer() method to JettySolrRunner
> 
>
> Key: SOLR-8259
> URL: https://issues.apache.org/jira/browse/SOLR-8259
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8259.patch
>
>
> We have this all over our tests:
> {code}
> CoreContainer cores = ((SolrDispatchFilter) 
> jetty.getDispatchFilter().getFilter()).getCores();
> {code}
> We should add a sugar method explicitly for doing 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-8259) Add getCoreContainer() method to SolrJettyRunner

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8259:

Attachment: SOLR-8259.patch

Patch removing JettySolrRunner.getDispatchFilter() and adding 
.getCoreContainer() and .getSolrDispatchFilter() methods.  In 5.x I'll just 
deprecate .getDispatchFilter().

> Add getCoreContainer() method to SolrJettyRunner
> 
>
> Key: SOLR-8259
> URL: https://issues.apache.org/jira/browse/SOLR-8259
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8259.patch
>
>
> We have this all over our tests:
> {code}
> CoreContainer cores = ((SolrDispatchFilter) 
> jetty.getDispatchFilter().getFilter()).getCores();
> {code}
> We should add a sugar method explicitly for doing 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