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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([DDE3C79E4BB3A3BC:34B97CA6D52A3314]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:765)
at 
org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir(TestArbitraryIndexDir.java:128)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:365)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=*[count(//doc)=1]
xml response was: 

02


request was:q=id:2=standard=0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:758)
... 40 more




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

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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=77233, name=collection3, 
state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=77233, name=collection3, state=RUNNABLE, 
group=TGRP-HdfsCollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:37034/_l/j: Could not find collection : 
awholynewstresscollection_collection3_1
at __randomizedtesting.SeedInfo.seed([33D546A4102F2C79]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1099)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:895)


FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=108998, name=collection0, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=108998, name=collection0, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:46708/lv_/kb: collection already exists: 
awholynewstresscollection_collection0_0
at __randomizedtesting.SeedInfo.seed([33D546A4102F2C79]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1099)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1574)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1595)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:888)




Build Log:
[...truncated 11377 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/solr/build/solr-core/test/J1/temp/solr.cloud.CollectionsAPIDistributedZkTest_33D546A4102F2C79-001/init-core-data-001
   [junit4]   2> 1650624 INFO  
(SUITE-CollectionsAPIDistributedZkTest-seed#[33D546A4102F2C79]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false)
   [junit4]   2> 1650625 INFO  
(SUITE-CollectionsAPIDistributedZkTest-seed#[33D546A4102F2C79]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /lv_/kb
   [junit4]   2> 1650629 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[33D546A4102F2C79]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1650630 INFO  (Thread-104049) [] o.a.s.c.ZkTestServer 
client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1650630 INFO  (Thread-104049) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1650730 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[33D546A4102F2C79]) [] 
o.a.s.c.ZkTestServer start zk server on port:52782
 

[JENKINS-EA] Lucene-Solr-5.3-Linux (32bit/jdk1.9.0-ea-b78) - Build # 174 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.3-Linux/174/
Java: 32bit/jdk1.9.0-ea-b78 -client -XX:+UseConcMarkSweepGC

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 1) Thread[id=9545, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 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:746)2) Thread[id=9544, 
name=ou=system.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 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:746)3) Thread[id=9543, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 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:746)4) Thread[id=9542, 
name=apacheds, state=WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] 
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)5) Thread[id=9546, 
name=groupCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 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:746)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 
   1) Thread[id=9545, name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 

[jira] [Commented] (SOLR-8030) Transaction log does not store the update chain used for updates

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8030:


bq. But aren't the docs in the tlog stored post update chain anyway?

I'm pretty sure it's more complicated then that -- i suspect any processor that 
is configured to run _after_ the DistributedUpdateProcessor is at risk here in 
the event of tlog replay.


> Transaction log does not store the update chain used for updates
> 
>
> Key: SOLR-8030
> URL: https://issues.apache.org/jira/browse/SOLR-8030
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: ludovic Boutros
>
> Transaction Log does not store the update chain used during updates.
> Therefore tLog uses the default update chain during log replay.
> If we implement custom update logic with multiple update chains, the log 
> replay could break this logic.



--
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: Please vote for the 2nd release candidate for Lucene/Solr 5.3.1

[Yonik Seeley]

On Tue, Sep 15, 2015 at 5:15 PM, Anshum Gupta  wrote:
> Hi Noble,
>
> Sorry for spoiling the party at the last moment, but I think SOLR-8058 is a
> good candidate for a re-spin. I have a patch ready, need some time to add
> tests for it though. Thoughts?

+1 for fixing this for 5.3.1, this seems relatively serious.
I just verified that if I create a core called "json_docs" (which
begins with js), I can't access it after.

-Yonik

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

[jira] [Updated] (LUCENE-6807) AbstractRangeQueryNode toQueryString not working as intended

[Peter Barna (JIRA)]

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

Peter Barna updated LUCENE-6807:

Attachment: LUCENE-6807-option1.patch

Patch to fix LUCENE-6807 using the option of creating a new method in the 
ValueQueryNode interface.

> AbstractRangeQueryNode toQueryString not working as intended
> 
>
> Key: LUCENE-6807
> URL: https://issues.apache.org/jira/browse/LUCENE-6807
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 5.3
>Reporter: Peter Barna
>Priority: Minor
> Attachments: LUCENE-6807-option1.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> It is my understanding that for a given {{QueryNode}} node, 
> {{parse(node.toQueryString());}} should return a {{QueryNode}} which is 
> functionally identical to the original node.
> That is not the case with AbstractQueryNode:
> if we have a range query on FIELD from "A" to "B" ({{node = parse("FIELD:[A 
> B]")}}), then {{node.toQueryString()}} will return "[FIELD:A FIELD:B]" which, 
> in turn, is parsed as a range query on the default field from "FIELD:A" to 
> "FIELD:B".
> As far as I know, this affects all versions of lucene.
> I believe I have the knowledge to provide the patch, so I will be working on 
> that today.
> As of now, I have thought of two options to implement this fix, both of which 
> involve modifying the {{ValueQueryNode}} interface to include a method which 
> returns {{value}} as a {{CharSequence}}. 
> The first option is to add a new method to the interface which returns 
> (formatted if necessary) the value as a {{CharSequence}} and implement it in 
> all implementing classes ({{FieldQueryNode}} and {{NumericQueryNode}}). Then 
> in {{AbstractQueryNode#toQueryString()}} we will call that method and escape 
> the values using the provided {{EscapeQuerySyntax}}.
> The second option is to make the protected method {{getTermEscaped()}}, which 
> is already present in all implementing classes, public, and add it to the 
> interface.
> While I think that the second option is certainly cleaner, I do not know why 
> this method is protected in the first place, so I will proceed with the first 
> option until someone who is more familiar with the lucene project than I am 
> can comment on the matter.
> As I am writing this, it occurs to me that implementing the first option is 
> essentially just bypassing the protected scope on {{getTermEscapeed()}}, so 
> maybe it is correct to just review whether or not that method needs to be 
> protected. It also occurred to me to use the existing {{getValue()}} method, 
> and format and escape the {{toString()}} of that, but that depends on a 
> generic class having implemented {{toString()}} in a way that plays nicely 
> with the query parser, so, to me, this is below the two previously mentioned 
> options.



--
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-6807) AbstractRangeQueryNode toQueryString not working as intended

[Peter Barna (JIRA)]

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

Peter Barna commented on LUCENE-6807:
-

I have uploaded a patch to fix this bug using the first option. I will try to 
get patches up for the other two options (make getTermEscaped public, assume 
toString() gives something usable) tomorrow.

> AbstractRangeQueryNode toQueryString not working as intended
> 
>
> Key: LUCENE-6807
> URL: https://issues.apache.org/jira/browse/LUCENE-6807
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 5.3
>Reporter: Peter Barna
>Priority: Minor
> Attachments: LUCENE-6807-option1.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> It is my understanding that for a given {{QueryNode}} node, 
> {{parse(node.toQueryString());}} should return a {{QueryNode}} which is 
> functionally identical to the original node.
> That is not the case with AbstractQueryNode:
> if we have a range query on FIELD from "A" to "B" ({{node = parse("FIELD:[A 
> B]")}}), then {{node.toQueryString()}} will return "[FIELD:A FIELD:B]" which, 
> in turn, is parsed as a range query on the default field from "FIELD:A" to 
> "FIELD:B".
> As far as I know, this affects all versions of lucene.
> I believe I have the knowledge to provide the patch, so I will be working on 
> that today.
> As of now, I have thought of two options to implement this fix, both of which 
> involve modifying the {{ValueQueryNode}} interface to include a method which 
> returns {{value}} as a {{CharSequence}}. 
> The first option is to add a new method to the interface which returns 
> (formatted if necessary) the value as a {{CharSequence}} and implement it in 
> all implementing classes ({{FieldQueryNode}} and {{NumericQueryNode}}). Then 
> in {{AbstractQueryNode#toQueryString()}} we will call that method and escape 
> the values using the provided {{EscapeQuerySyntax}}.
> The second option is to make the protected method {{getTermEscaped()}}, which 
> is already present in all implementing classes, public, and add it to the 
> interface.
> While I think that the second option is certainly cleaner, I do not know why 
> this method is protected in the first place, so I will proceed with the first 
> option until someone who is more familiar with the lucene project than I am 
> can comment on the matter.
> As I am writing this, it occurs to me that implementing the first option is 
> essentially just bypassing the protected scope on {{getTermEscapeed()}}, so 
> maybe it is correct to just review whether or not that method needs to be 
> protected. It also occurred to me to use the existing {{getValue()}} method, 
> and format and escape the {{toString()}} of that, but that depends on a 
> generic class having implemented {{toString()}} in a way that plays nicely 
> with the query parser, so, to me, this is below the two previously mentioned 
> options.



--
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-8034) If minRF is not satisfied, leader should not put replicas in recovery

[ASF subversion and git services (JIRA)]

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

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

Commit 1703302 from [~anshumg] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1703302 ]

SOLR-8034: Leader no longer puts replicas in recovery in case of a failed 
update, when minRF isn't achieved. (merge from trunk)

> If minRF is not satisfied, leader should not put replicas in recovery
> -
>
> Key: SOLR-8034
> URL: https://issues.apache.org/jira/browse/SOLR-8034
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>Assignee: Anshum Gupta
>  Labels: solrcloud
> Attachments: SOLR-8034.patch, SOLR-8034.patch
>
>
> If the minimum replication factor parameter (minRf) in a solr update request 
> is not satisfied -- i.e. if the update was not successfully applied on at 
> least n replicas where n >= minRf -- the shard leader should not put the 
> failed replicas in "leader initiated recovery" and the client should retry 
> the update instead.
> This is so that in the scenario were minRf is not satisfied, the failed 
> replicas can still be eligible to become a leader in case of leader failure, 
> since in the client's perspective this update did not succeed.
> This came up from a network partition scenario where the leader becomes 
> sectioned off from its two followers, but they all could still talk to 
> zookeeper. The partitioned leader set its two followers as in leader 
> initiated recovery, so we couldn't just kill off the partitioned node and 
> have a follower take over leadership. For a minRf=1 case, this is the correct 
> behavior because the partitioned leader would have accepted updates that the 
> followers don't have, and therefore we can't switch leadership or we'd lose 
> those updates. However, in the case of minRf=2, solr never accepted any 
> update in the client's point of view, so in fact the partitioned leader 
> doesn't have any accepted update that the followers don't have, and therefore 
> the followers should be eligible to become leaders. Thus, I'm proposing 
> modifying the leader initiated recovery logic to not put the followers in 
> recovery if the minRf parameter is present and is not satisfied.



--
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-8034) If minRF is not satisfied, leader should not put replicas in recovery

[Tim Potter (JIRA)]

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

Tim Potter commented on SOLR-8034:
--

Hi [~mewmewball].  I don't recall talking with you - perhaps you meant someone 
else?

> If minRF is not satisfied, leader should not put replicas in recovery
> -
>
> Key: SOLR-8034
> URL: https://issues.apache.org/jira/browse/SOLR-8034
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>  Labels: solrcloud
> Attachments: SOLR-8034.patch
>
>
> If the minimum replication factor parameter (minRf) in a solr update request 
> is not satisfied -- i.e. if the update was not successfully applied on at 
> least n replicas where n >= minRf -- the shard leader should not put the 
> failed replicas in "leader initiated recovery" and the client should retry 
> the update instead.
> This is so that in the scenario were minRf is not satisfied, the failed 
> replicas can still be eligible to become a leader in case of leader failure, 
> since in the client's perspective this update did not succeed.
> This came up from a network partition scenario where the leader becomes 
> sectioned off from its two followers, but they all could still talk to 
> zookeeper. The partitioned leader set its two followers as in leader 
> initiated recovery, so we couldn't just kill off the partitioned node and 
> have a follower take over leadership. For a minRf=1 case, this is the correct 
> behavior because the partitioned leader would have accepted updates that the 
> followers don't have, and therefore we can't switch leadership or we'd lose 
> those updates. However, in the case of minRf=2, solr never accepted any 
> update in the client's point of view, so in fact the partitioned leader 
> doesn't have any accepted update that the followers don't have, and therefore 
> the followers should be eligible to become leaders. Thus, I'm proposing 
> modifying the leader initiated recovery logic to not put the followers in 
> recovery if the minRf parameter is present and is not satisfied.



--
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-7963) Suggester context filter query to accept local params query

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou commented on SOLR-7963:
--

Hello [~janhoy]

Thank you very much for your comment at
https://issues.apache.org/jira/browse/SOLR-7888#comment-14743511

{quote}
It is kind of a hack to force Lucene's AnalyzingSuggester to use same contexts 
field name as the source schema field name we pull data from 
{quote}
[~janhoy], I would suggest you take a step back and think a bit about this.

Currently, we are hard-coding the field to use in the code while we have the 
solr schema facility available.
According to [~mikemccand] blog at 
http://blog.mikemccandless.com/2013/06/a-new-lucene-suggester-based-on-infix.html
 , {quote}Unlike the existing suggesters, this new suggester does not use a 
specialized data-structure such as FSTs. Instead, it's an "ordinary" Lucene 
index under-the-hood...{quote}
Basically, the analyzing suggester index could have the very same treatment 
that we apply to normal Solr index... that was the main motivation to move to 
using the existing solr schema instead of hard coding the field.

I would suggest you think a bit more about this.

{quote}
If the source fieldType in schema.xml is e.g. text, then that Analyser is used 
for query, with lowercasing etc. Problem is that the contexts field for the 
Suggester is always indexed as String, meaning that a source string "ABC" will 
not match a query "ABC" since it will be lowercased and match only "abc"
{quote}
That is a bug in the implementation. I should be using the index-time analyzer 
defined in the schema instead. 
This can be easily fixed.

And using the analyser defined in the schema should not cause any issue with 
using the solr collection for other search  purposes as copyField could be used 
if one need to separate the field used for searching from the one used for 
suggestion.

Thank you very much [~janhoy]

> Suggester context filter query to accept local params query
> ---
>
> Key: SOLR-7963
> URL: https://issues.apache.org/jira/browse/SOLR-7963
> Project: Solr
>  Issue Type: Improvement
>  Components: Suggester
>Affects Versions: 5.4
>Reporter: Arcadius Ahouansou
>Priority: Minor
>  Labels: suggester
>
> SOLR-7888 has introduced a new parameter for filtering suggester queries
> {code}suggest.cfq=ctx1 OR ctx2{code} 
> The implementation use the Solr {{StandardQueryParser}} for parsing the cfq 
> param.
> This card is to allow to pass in local param queries such as 
> {code}
> suggest.cfq={!terms f=contextx}ctx1,ctx2
> {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-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou commented on SOLR-7888:
--

Hello [~janhoy]

Thank you for uploading the updated version.
I am pretty happy with your changes and I would suggest we go ahead with that.
There are few minor changes that are needed:
- {code}-SuggesterResult suggesterResult = 
suggester.getSuggestions(options);
+SuggesterResult suggesterResult = suggester.getSuggestions(options, 
rb.req);{code}
The additional param {{rb.req}} was needed only for SOLR-7963, so it can be 
removed here and in all subsequent methods.
- As we no longer rely on the schema, maybe we should review/rename the test 
{{testContextFilterUsesAnalyzerFromSchema()}}?
 
I am not quite sure whether the {{* Clone of CONTEXTS_FIELD_NAME in 
AnalyzingInfixSuggester}} is an excellent idea, but that it very minor.

So, please let's go ahead with this.
Thank you very much.

I will address your comments regarding SOLR-7963 later on.

> Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a 
> BooleanQuery filter parameter available in Solr
> --
>
> Key: SOLR-7888
> URL: https://issues.apache.org/jira/browse/SOLR-7888
> Project: Solr
>  Issue Type: New Feature
>  Components: Suggester
>Affects Versions: 5.2.1
>Reporter: Arcadius Ahouansou
>Assignee: Jan Høydahl
> Fix For: 5.4
>
> Attachments: SOLR-7888-7963.patch, SOLR-7888.patch
>
>
>  LUCENE-6464 has introduced a very flexible lookup method that takes as 
> parameter a BooleanQuery that is used for filtering results.
> This ticket is to expose that method to Solr.
> This would allow user to do:
> {code}
> /suggest?suggest=true=true=term=contexts:tennis
> /suggest?suggest=true=true=term=contexts:golf
>  AND contexts:football
> {code}
> etc
> Given that the context filtering in currently only implemented by the 
> {code}AnalyzingInfixSuggester{code} and by the 
> {code}BlendedInfixSuggester{code}, this initial implementation will support 
> only these 2 lookup implementations.



--
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: Switching AngularUI to default

[Upayavira]

As shown on SOLR-7858, I've added links to the top right, but the idea
of adding a distinctive grey tint to the whole page on the old UI is an
intersting idea!

Upayavira

https://issues.apache.org/jira/browse/SOLR-7858


On Tue, Sep 15, 2015, at 06:54 PM, david.w.smi...@gmail.com wrote:
> With the old UI, I suggest doing something to the CSS to make it more
> obvious you’re using the old UI… like changing the background color or
> maybe instead of the CSS insert a label somewhere.  It’s very
> confusing to switch and forget which one you’re using!
>
> On Tue, Sep 15, 2015 at 5:11 AM Stefan Matheis
>  wrote:
>> I'd go with (1); we took the same route for the current ui. otherwise
>> people are still using the current one, until it's not available
>> anymore - when they could have used the angular one already quite a
>> while. at least that's my experience with that kind of changes :)
>>
>> -Stefan
>>
>> On Tuesday, September 15, 2015 at 10:59 AM, Upayavira wrote:


>>>
>>> The Angular UI for Solr is now feature complete, and people are
>>> asking that it be made the default. There are, undoubtedly, still
>>> bugs to be found in it.
>>>
>>> The new UI will have new features (e.g. a collections tab) so will
>>> hopefully be worth people using!
>>>
>>> Here's two options, as I see it, for 5.4:
>>>
>>> 1. Make it default, with a link back to the original UI in case of
>>>bugs
>>> 2. Add a link to the new UI to the current one (should have done
>>>that ages ago) in order to gather feedback before making it
>>>default
>>>
>>> Screenshots of links are here:
>>> https://issues.apache.org/jira/browse/SOLR-7858
>>>
>>> Thoughts?
>>>
>>> Upayavira
>>>
>>> ---
>>> --
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
>>> additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com

[jira] [Comment Edited] (SOLR-8058) Collections that start with css*, js*, img*, and tpl* can't be accessed as they match the exclusion filter

[Upayavira (JIRA)]

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

Upayavira edited comment on SOLR-8058 at 9/15/15 6:43 PM:
--

I'm not quite sure what that code is trying to do. The Angular UI adds 
/partials to the list of directories, and it works just fine. Looking at the 
regexp entries, they are broken anyway: 

{code}

  excludePatterns
  /css/*,/js/*,/img/*,/tpl/*

{code}
That says any value that starts with /css, then is followed by a sequence of 
zero or more forward slashes. I think what is intended is {{/css/.*}}, no?

Why do we need these excluded patterns?


was (Author: upayavira):
I'm not quite sure what that code is trying to do. The Angular UI adds 
/partials to the list of directories, and it works just fine. Looking at the 
regexp entries, they are broken anyway: 


  excludePatterns
  /css/*,/js/*,/img/*,/tpl/*


That says any value that starts with /css, then is followed by a sequence of 
zero or more forward slashes. I think what is intended is /css/.*, no?

Why do we need these excluded patterns?

> Collections that start with css*, js*, img*, and tpl* can't be accessed as 
> they match the exclusion filter
> --
>
> Key: SOLR-8058
> URL: https://issues.apache.org/jira/browse/SOLR-8058
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
>
> Collections that match css*, js*, img*, and tpl* can't be reached as the SDF 
> short circuits paths that match those regular expressions.
> It should have only short circuited exact matches for those directories i.e.
> \css/*,/js/*,/img/*,/tpl/* but that doesn't seem to be the case.
> Need to fix this regular expression so that the collection can be reached.



--
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-8058) Collections that start with css*, js*, img*, and tpl* can't be accessed as they match the exclusion filter

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8058:


You are right, we need {{.+}} or {{.*}} there.

The reason why we added these was to bypass the SolrDispatchFilter logic and 
creation of the HttpSolrCall object for static files. This is also required so 
you don't have to setup authentication rules for static admin UI content.

> Collections that start with css*, js*, img*, and tpl* can't be accessed as 
> they match the exclusion filter
> --
>
> Key: SOLR-8058
> URL: https://issues.apache.org/jira/browse/SOLR-8058
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
>
> Collections that match css*, js*, img*, and tpl* can't be reached as the SDF 
> short circuits paths that match those regular expressions.
> It should have only short circuited exact matches for those directories i.e.
> \css/*,/js/*,/img/*,/tpl/* but that doesn't seem to be the case.
> Need to fix this regular expression so that the collection can be reached.



--
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-8058) Collections that start with css*, js*, img*, and tpl* can't be accessed as they match the exclusion filter

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-8058:
-

if we need to mark such files as "static" then perhaps we should serve them all 
from a specific directory - e.g. we could have refer to all but the index.html 
(or admin.html) files from /_admin/css/*.

Or why not make the regexp {{.*\.css$}}, i.e. ends with .css. No queries should 
end with .css. I guess people could, however, add a .html request handler. Hmm.

> Collections that start with css*, js*, img*, and tpl* can't be accessed as 
> they match the exclusion filter
> --
>
> Key: SOLR-8058
> URL: https://issues.apache.org/jira/browse/SOLR-8058
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
>
> Collections that match css*, js*, img*, and tpl* can't be reached as the SDF 
> short circuits paths that match those regular expressions.
> It should have only short circuited exact matches for those directories i.e.
> \css/*,/js/*,/img/*,/tpl/* but that doesn't seem to be the case.
> Need to fix this regular expression so that the collection can be reached.



--
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-8034) If minRF is not satisfied, leader should not put replicas in recovery

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-8034:
--

[~tpot] oops! Jessica was actually pinging me {{thelabdude}} (same name, 
different handle)

[~mewmewball] this looks good to me ... nice test case! Also, I agree that if 
the client is using {{minRf}} then it is their responsibility to handle the 
response correctly. Previously, we talked about throwing an exception instead 
of just returning to value for the client to interpret and maybe that makes it 
more explicit that clients MUST handle minRf not being achieved.  We should 
handle that in another ticket though.

> If minRF is not satisfied, leader should not put replicas in recovery
> -
>
> Key: SOLR-8034
> URL: https://issues.apache.org/jira/browse/SOLR-8034
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>  Labels: solrcloud
> Attachments: SOLR-8034.patch, SOLR-8034.patch
>
>
> If the minimum replication factor parameter (minRf) in a solr update request 
> is not satisfied -- i.e. if the update was not successfully applied on at 
> least n replicas where n >= minRf -- the shard leader should not put the 
> failed replicas in "leader initiated recovery" and the client should retry 
> the update instead.
> This is so that in the scenario were minRf is not satisfied, the failed 
> replicas can still be eligible to become a leader in case of leader failure, 
> since in the client's perspective this update did not succeed.
> This came up from a network partition scenario where the leader becomes 
> sectioned off from its two followers, but they all could still talk to 
> zookeeper. The partitioned leader set its two followers as in leader 
> initiated recovery, so we couldn't just kill off the partitioned node and 
> have a follower take over leadership. For a minRf=1 case, this is the correct 
> behavior because the partitioned leader would have accepted updates that the 
> followers don't have, and therefore we can't switch leadership or we'd lose 
> those updates. However, in the case of minRf=2, solr never accepted any 
> update in the client's point of view, so in fact the partitioned leader 
> doesn't have any accepted update that the followers don't have, and therefore 
> the followers should be eligible to become leaders. Thus, I'm proposing 
> modifying the leader initiated recovery logic to not put the followers in 
> recovery if the minRf parameter is present and is not satisfied.



--
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-8034) If minRF is not satisfied, leader should not put replicas in recovery

[Jessica Cheng Mallet (JIRA)]

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

Jessica Cheng Mallet commented on SOLR-8034:


Oops, sorry! Didn't know there's another Tim Potter. :P

> If minRF is not satisfied, leader should not put replicas in recovery
> -
>
> Key: SOLR-8034
> URL: https://issues.apache.org/jira/browse/SOLR-8034
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>Assignee: Anshum Gupta
>  Labels: solrcloud
> Attachments: SOLR-8034.patch, SOLR-8034.patch
>
>
> If the minimum replication factor parameter (minRf) in a solr update request 
> is not satisfied -- i.e. if the update was not successfully applied on at 
> least n replicas where n >= minRf -- the shard leader should not put the 
> failed replicas in "leader initiated recovery" and the client should retry 
> the update instead.
> This is so that in the scenario were minRf is not satisfied, the failed 
> replicas can still be eligible to become a leader in case of leader failure, 
> since in the client's perspective this update did not succeed.
> This came up from a network partition scenario where the leader becomes 
> sectioned off from its two followers, but they all could still talk to 
> zookeeper. The partitioned leader set its two followers as in leader 
> initiated recovery, so we couldn't just kill off the partitioned node and 
> have a follower take over leadership. For a minRf=1 case, this is the correct 
> behavior because the partitioned leader would have accepted updates that the 
> followers don't have, and therefore we can't switch leadership or we'd lose 
> those updates. However, in the case of minRf=2, solr never accepted any 
> update in the client's point of view, so in fact the partitioned leader 
> doesn't have any accepted update that the followers don't have, and therefore 
> the followers should be eligible to become leaders. Thus, I'm proposing 
> modifying the leader initiated recovery logic to not put the followers in 
> recovery if the minRf parameter is present and is not satisfied.



--
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-8034) If minRF is not satisfied, leader should not put replicas in recovery

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8034:
---
Issue Type: Improvement  (was: Bug)

> If minRF is not satisfied, leader should not put replicas in recovery
> -
>
> Key: SOLR-8034
> URL: https://issues.apache.org/jira/browse/SOLR-8034
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>Assignee: Anshum Gupta
>  Labels: solrcloud
> Attachments: SOLR-8034.patch, SOLR-8034.patch
>
>
> If the minimum replication factor parameter (minRf) in a solr update request 
> is not satisfied -- i.e. if the update was not successfully applied on at 
> least n replicas where n >= minRf -- the shard leader should not put the 
> failed replicas in "leader initiated recovery" and the client should retry 
> the update instead.
> This is so that in the scenario were minRf is not satisfied, the failed 
> replicas can still be eligible to become a leader in case of leader failure, 
> since in the client's perspective this update did not succeed.
> This came up from a network partition scenario where the leader becomes 
> sectioned off from its two followers, but they all could still talk to 
> zookeeper. The partitioned leader set its two followers as in leader 
> initiated recovery, so we couldn't just kill off the partitioned node and 
> have a follower take over leadership. For a minRf=1 case, this is the correct 
> behavior because the partitioned leader would have accepted updates that the 
> followers don't have, and therefore we can't switch leadership or we'd lose 
> those updates. However, in the case of minRf=2, solr never accepted any 
> update in the client's point of view, so in fact the partitioned leader 
> doesn't have any accepted update that the followers don't have, and therefore 
> the followers should be eligible to become leaders. Thus, I'm proposing 
> modifying the leader initiated recovery logic to not put the followers in 
> recovery if the minRf parameter is present and is not satisfied.



--
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-8057) Change default Sim to BM25 (w/backcompat config handling)

[Hoss Man (JIRA)]

Hoss Man created SOLR-8057:
--

 Summary: Change default Sim to BM25 (w/backcompat config handling)
 Key: SOLR-8057
 URL: https://issues.apache.org/jira/browse/SOLR-8057
 Project: Solr
  Issue Type: Task
Reporter: Hoss Man
Priority: Blocker
 Fix For: 6.0


LUCENE-6789 changed the default similarity for IndexSearcher to BM25 and 
renamed "DefaultSimilarity" to "ClassicSimilarity"

Solr needs to be updated accordingly:

* a "ClassicSimilarityFactory" should exist w/expected behavior/javadocs
* default behavior (in 6.0) when no similarity is specified in configs should 
(ultimately) use BM25 depending on luceneMatchVersion
** either by assuming BM25SimilarityFactory or by changing the internal 
behavior of DefaultSimilarityFactory
* comments in sample configs need updated to reflect new default behavior
* ref guide needs updated anywhere it mentions/implies that a particular 
similarity is used (or implies TF-IDF is used 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-8058) Collections that start with css*, js*, img*, and tpl* can't be accessed as they match the exclusion filter

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-8058:
-

I'm not quite sure what that code is trying to do. The Angular UI adds 
/partials to the list of directories, and it works just fine. Looking at the 
regexp entries, they are broken anyway: 


  excludePatterns
  /css/*,/js/*,/img/*,/tpl/*


That says any value that starts with /css, then is followed by a sequence of 
zero or more forward slashes. I think what is intended is /css/.*, no?

Why do we need these excluded patterns?

> Collections that start with css*, js*, img*, and tpl* can't be accessed as 
> they match the exclusion filter
> --
>
> Key: SOLR-8058
> URL: https://issues.apache.org/jira/browse/SOLR-8058
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
>
> Collections that match css*, js*, img*, and tpl* can't be reached as the SDF 
> short circuits paths that match those regular expressions.
> It should have only short circuited exact matches for those directories i.e.
> \css/*,/js/*,/img/*,/tpl/* but that doesn't seem to be the case.
> Need to fix this regular expression so that the collection can be reached.



--
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-b78) - Build # 13936 - Failure!

[Policeman Jenkins Server]

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

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 1) Thread[id=12787, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 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:746)2) Thread[id=12788, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 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:746)3) Thread[id=12786, 
name=apacheds, state=WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] 
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)4) Thread[id=12790, 
name=groupCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 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:746)5) Thread[id=12789, 
name=ou=system.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 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:746)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 
   1) Thread[id=12787, name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 

Re: Switching AngularUI to default

[david.w.smi...@gmail.com]

With the old UI, I suggest doing something to the CSS to make it more
obvious you’re using the old UI… like changing the background color or
maybe instead of the CSS insert a label somewhere.  It’s very confusing to
switch and forget which one you’re using!

On Tue, Sep 15, 2015 at 5:11 AM Stefan Matheis  wrote:

> I'd go with (1); we took the same route for the current ui. otherwise
> people are still using the current one, until it's not available anymore -
> when they could have used the angular one already quite a while. at least
> that's my experience with that kind of changes :)
>
> -Stefan
>
> On Tuesday, September 15, 2015 at 10:59 AM, Upayavira wrote:
>
> The Angular UI for Solr is now feature complete, and people are asking
> that it be made the default. There are, undoubtedly, still bugs to be
> found in it.
>
> The new UI will have new features (e.g. a collections tab) so will
> hopefully be worth people using!
>
> Here's two options, as I see it, for 5.4:
>
> 1. Make it default, with a link back to the original UI in case of bugs
> 2. Add a link to the new UI to the current one (should have done that
> ages ago) in order to gather feedback before making it default
>
> Screenshots of links are here:
> https://issues.apache.org/jira/browse/SOLR-7858
>
> Thoughts?
>
> Upayavira
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Created] (SOLR-8058) Collections that start with css*, js*, img*, and tpl* can't be accessed as they match the exclusion filter

[Anshum Gupta (JIRA)]

Anshum Gupta created SOLR-8058:
--

 Summary: Collections that start with css*, js*, img*, and tpl* 
can't be accessed as they match the exclusion filter
 Key: SOLR-8058
 URL: https://issues.apache.org/jira/browse/SOLR-8058
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3, 5.2.1, 5.2, 5.3.1
Reporter: Anshum Gupta
Assignee: Anshum Gupta
Priority: Blocker


Collections that match css*, js*, img*, and tpl* can't be reached as the SDF 
short circuits paths that match those regular expressions.

It should have only short circuited exact matches for those directories i.e.
\css/*,/js/*,/img/*,/tpl/* but that doesn't seem to be the case.

Need to fix this regular expression so that the collection can be reached.



--
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

Switching AngularUI to default

[Upayavira]

The Angular UI for Solr is now feature complete, and people are asking
that it be made the default. There are, undoubtedly, still bugs to be
found in it.

The new UI will have new features (e.g. a collections tab) so will
hopefully be worth people using!

Here's two options, as I see it, for 5.4:

1. Make it default, with a link back to the original UI in case of bugs
2. Add a link to the new UI to the current one (should have done that
ages ago) in order to gather feedback before making it default

Screenshots of links are here:
https://issues.apache.org/jira/browse/SOLR-7858

Thoughts?

Upayavira

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

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_60) - Build # 5257 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5257/
Java: 32bit/jdk1.8.0_60 -server -XX:+UseG1GC

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

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([FA52F81AFC0D1C68:7206C7C052F17190]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.junit.Assert.assertNull(Assert.java:562)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testNoConfigSetExist(CollectionsAPIDistributedZkTest.java:519)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:166)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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 

Re: Switching AngularUI to default

[Stefan Matheis]

I'd go with (1); we took the same route for the current ui. otherwise people 
are still using the current one, until it's not available anymore - when they 
could have used the angular one already quite a while. at least that's my 
experience with that kind of changes :) 

-Stefan 


On Tuesday, September 15, 2015 at 10:59 AM, Upayavira wrote:

> The Angular UI for Solr is now feature complete, and people are asking
> that it be made the default. There are, undoubtedly, still bugs to be
> found in it.
> 
> The new UI will have new features (e.g. a collections tab) so will
> hopefully be worth people using!
> 
> Here's two options, as I see it, for 5.4:
> 
> 1. Make it default, with a link back to the original UI in case of bugs
> 2. Add a link to the new UI to the current one (should have done that
> ages ago) in order to gather feedback before making it default
> 
> Screenshots of links are here:
> https://issues.apache.org/jira/browse/SOLR-7858
> 
> Thoughts?
> 
> Upayavira
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> (mailto:dev-unsubscr...@lucene.apache.org)
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> (mailto:dev-h...@lucene.apache.org)
> 
> 

[jira] [Commented] (SOLR-8026) DistribJoinFromCollectionTest test failures

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8026:


I understand that no one have a time to review. Since it's only test change, I 
bring it back (commit) in a day or two.  

> DistribJoinFromCollectionTest test failures
> ---
>
> Key: SOLR-8026
> URL: https://issues.apache.org/jira/browse/SOLR-8026
> Project: Solr
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Joel Bernstein
>Assignee: Mikhail Khludnev
> Attachments: SOLR-8026.patch, SOLR-8026.patch
>
>
> Trunk DistribJoinFromCollectionTest is failing for me locally and appears be 
> failing on jenkins as well. Here is the error from my local machine. 
> [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=DistribJoinFromCollectionTest -Dtests.method=test 
> -Dtests.seed=5C8C1B007BE0841E -Dtests.slow=true -Dtests.locale=it 
> -Dtests.timezone=Australia/Melbourne -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 44.4s | DistribJoinFromCollectionTest.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
>[junit4]> Expected: not "1.0"
>[junit4]>  got: "1.0"
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([5C8C1B007BE0841E:D4D824DAD51CE9E6]:0)
>[junit4]>  at 
> org.apache.solr.cloud.DistribJoinFromCollectionTest.assertScore(DistribJoinFromCollectionTest.java:170)
>[junit4]>  at 
> org.apache.solr.cloud.DistribJoinFromCollectionTest.testJoins(DistribJoinFromCollectionTest.java:132)
>[junit4]>  at 
> org.apache.solr.cloud.DistribJoinFromCollectionTest.test(DistribJoinFromCollectionTest.java:100)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> 44372 INFO  
> (SUITE-DistribJoinFromCollectionTest-seed#[5C8C1B007BE0841E]-worker) 
> [n:127.0.0.1:59399_ c:from_1x2 s:shard1 r:core_node2 
> x:from_1x2_shard1_replica2] o.a.s.SolrTestCaseJ4 ###deleteCore



--
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-6779) Reduce memory allocated by CompressingStoredFieldsWriter to write large strings

[ASF subversion and git services (JIRA)]

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

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

Commit 1703219 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1703219 ]

LUCENE-6779: Reduce memory allocated by CompressingStoredFieldsWriter to write 
strings larger than 64kb by an amount equal to string's utf8 size

> Reduce memory allocated by CompressingStoredFieldsWriter to write large 
> strings
> ---
>
> Key: LUCENE-6779
> URL: https://issues.apache.org/jira/browse/LUCENE-6779
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/codecs
>Reporter: Shalin Shekhar Mangar
> Attachments: LUCENE-6779.patch, LUCENE-6779.patch, LUCENE-6779.patch, 
> LUCENE-6779.patch, LUCENE-6779_alt.patch
>
>
> In SOLR-7927, I am trying to reduce the memory required to index very large 
> documents (between 10 to 100MB) and one of the places which allocate a lot of 
> heap is the UTF8 encoding in CompressingStoredFieldsWriter. The same problem 
> existed in JavaBinCodec and we reduced its memory allocation by falling back 
> to a double pass approach in SOLR-7971 when the utf8 size of the string is 
> greater than 64KB.
> I propose to make the same changes to CompressingStoredFieldsWriter as we 
> made to JavaBinCodec in SOLR-7971.



--
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-8053) support basic auth in SolrJ

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8053:
--

bq.but could you explain a little about how this works in with the existing 
basic auth stuff in HttpClientUtil

This was a hack introduced to add the basic auth headers when Solr makes 
inter-node requests. After 5.3 we have native support for inter-node 
authentication. This lets you to have only one user/pwd combination in the 
entire cluster which meant all requests were performed as same user

IMHO we should deprecate this.

This ticket makes the user/pwd configurable of a per request basis.

{code:java}
SolrRequest req ;//create  anew request object
req.setBasicAuthCredentials(userName,  password);
solrClient.request(req);
{code}

> support basic auth in SolrJ
> ---
>
> Key: SOLR-8053
> URL: https://issues.apache.org/jira/browse/SOLR-8053
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-8053.patch
>
>




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

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

[jira] [Resolved] (LUCENE-6779) Reduce memory allocated by CompressingStoredFieldsWriter to write large strings

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved LUCENE-6779.
---
   Resolution: Fixed
 Assignee: Shalin Shekhar Mangar
Fix Version/s: 5.4
   Trunk

Thanks for the reviews Dawid and Robert!

> Reduce memory allocated by CompressingStoredFieldsWriter to write large 
> strings
> ---
>
> Key: LUCENE-6779
> URL: https://issues.apache.org/jira/browse/LUCENE-6779
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/codecs
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6779.patch, LUCENE-6779.patch, LUCENE-6779.patch, 
> LUCENE-6779.patch, LUCENE-6779_alt.patch
>
>
> In SOLR-7927, I am trying to reduce the memory required to index very large 
> documents (between 10 to 100MB) and one of the places which allocate a lot of 
> heap is the UTF8 encoding in CompressingStoredFieldsWriter. The same problem 
> existed in JavaBinCodec and we reduced its memory allocation by falling back 
> to a double pass approach in SOLR-7971 when the utf8 size of the string is 
> greater than 64KB.
> I propose to make the same changes to CompressingStoredFieldsWriter as we 
> made to JavaBinCodec in SOLR-7971.



--
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-6549) bin/solr script should support a -s option to set the -Dsolr.solr.home property

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-6549:
--

The change was intentional. I found that having the CMS start collecting sooner 
rather than later reduced pause times in my testing. However, if you're seeing 
something different, I'd love to see some empirical evidence that using 50 vs. 
70 is causing problems. Keep in mind this is the threshold when concurrent 
collections start, although there is some stop-the-world phases of CMS, so I 
can see how starting too early (or too often) can lead to issues. Of course, 
initial GC tuning params will never be correct for all workloads, so if 70 
works better for you, then use 70. The default is 68 if not specified. If we 
want to remove those options, that's fine as well, but be sure to remove 
{{-XX:+UseCMSInitiatingOccupancyOnly}} to let the JVM pick the correct value.

> bin/solr script should support a -s option to set the -Dsolr.solr.home 
> property
> ---
>
> Key: SOLR-6549
> URL: https://issues.apache.org/jira/browse/SOLR-6549
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 4.10.2, 5.0
>
>
> The bin/solr script supports a -d parameter for specifying the directory 
> containing the webapp, resources, etc, lib ... In most cases, these binaries 
> are reusable (and will eventually be in a server directory SOLR-3619) even if 
> you want to have multiple solr.solr.home directories on the same server. In 
> other words, it is more common/better to do:
> {code}
> bin/solr start -d server -s home1
> bin/solr start -d server -s home2
> {code}
> than to do:
> {code}
> bin/solr start -d server1
> bin/solr start -d server2
> {code}
> Basically, the start script needs to support a -s option that allows you to 
> share binaries but have different Solr home directories for running multiple 
> Solr instances on the same host.



--
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-8056) Solrj does not accept custom SolrParams

[Hrishikesh Gadre (JIRA)]

Hrishikesh Gadre created SOLR-8056:
--

 Summary: Solrj does not accept custom SolrParams
 Key: SOLR-8056
 URL: https://issues.apache.org/jira/browse/SOLR-8056
 Project: Solr
  Issue Type: Bug
  Components: SolrJ
Affects Versions: 4.10.3
Reporter: Hrishikesh Gadre
Priority: Minor


Solrj users can customize the Http client by overriding HttpClientConfigurer 
class (e.g. Krb5HttpClientConfigurer). But Solrj does not allow this 
customization at an individual SolrClient level. e.g. HttpSolrClient does not 
have a constructor which accepts default SolrParams which would be passed down 
to HttpClientUtil while creating an internal client.

I observed this while working on supporting Basic authentication with Solr 
(4.10.3) version. As a work-around, I had to use external Http client support 
in Solr. e.g.

-BEFORE--
CloudSolrServer  cloudSolrServer = new CloudSolrServer(zkEnsemble);

--AFTER
ModifiableSolrParams solrParams = new ModifiableSolrParams();
solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_USER, getLdapUserName());
solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_PASS, getLdapUserPasswd());

DefaultHttpClient client = (DefaultHttpClient) 
HttpClientUtil.createClient(solrParams);
cloudSolrServer = new CloudSolrServer(zkEnsemble, new LBHttpSolrServer(client));
--

I think it would be great necessary constructors in the SolrClient 
implementations so that users can pass custom properties during initialization.




--
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-8056) Solrj client constructor does not accept custom SolrParams

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre updated SOLR-8056:
---
Summary: Solrj client constructor does not accept custom SolrParams  (was: 
Solrj does not accept custom SolrParams)

> Solrj client constructor does not accept custom SolrParams
> --
>
> Key: SOLR-8056
> URL: https://issues.apache.org/jira/browse/SOLR-8056
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 4.10.3
>Reporter: Hrishikesh Gadre
>Priority: Minor
>
> Solrj users can customize the Http client by overriding HttpClientConfigurer 
> class (e.g. Krb5HttpClientConfigurer). But Solrj does not allow this 
> customization at an individual SolrClient level. e.g. HttpSolrClient does not 
> have a constructor which accepts default SolrParams which would be passed 
> down to HttpClientUtil while creating an internal client.
> I observed this while working on supporting Basic authentication with Solr 
> (4.10.3) version. As a work-around, I had to use external Http client support 
> in Solr. e.g.
> -BEFORE--
> CloudSolrServer  cloudSolrServer = new CloudSolrServer(zkEnsemble);
> --AFTER
> ModifiableSolrParams solrParams = new ModifiableSolrParams();
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_USER, getLdapUserName());
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_PASS, getLdapUserPasswd());
> DefaultHttpClient client = (DefaultHttpClient) 
> HttpClientUtil.createClient(solrParams);
> cloudSolrServer = new CloudSolrServer(zkEnsemble, new 
> LBHttpSolrServer(client));
> --
> I think it would be great necessary constructors in the SolrClient 
> implementations so that users can pass custom properties during 
> initialization.



--
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-6590) Explore different ways to apply boosts

[Terry Smith (JIRA)]

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

Terry Smith commented on LUCENE-6590:
-

[~jpountz]: PhraseQuery is missing a call to ToStringUtils.boost in it's 
toString method on the 5.x branch.


> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, 
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
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-8053) support basic auth in SolrJ

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-8053:


I just filed [SOLR-8056|https://issues.apache.org/jira/browse/SOLR-8056] to 
provide similar support at the SolrClient level as well.

> support basic auth in SolrJ
> ---
>
> Key: SOLR-8053
> URL: https://issues.apache.org/jira/browse/SOLR-8053
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-8053.patch
>
>




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

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

[jira] [Commented] (SOLR-8056) Solrj client constructor does not accept custom SolrParams

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8056:
--

Isn't it already supported?

> Solrj client constructor does not accept custom SolrParams
> --
>
> Key: SOLR-8056
> URL: https://issues.apache.org/jira/browse/SOLR-8056
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 4.10.3
>Reporter: Hrishikesh Gadre
>Priority: Minor
>
> Solrj users can customize the Http client by overriding HttpClientConfigurer 
> class (e.g. Krb5HttpClientConfigurer). But Solrj does not allow this 
> customization at an individual SolrClient level. e.g. HttpSolrClient does not 
> have a constructor which accepts default SolrParams which would be passed 
> down to HttpClientUtil while creating an internal client.
> I observed this while working on supporting Basic authentication with Solr 
> (4.10.3) version. As a work-around, I had to use external Http client support 
> in Solr. e.g.
> -BEFORE--
> CloudSolrServer  cloudSolrServer = new CloudSolrServer(zkEnsemble);
> --AFTER
> ModifiableSolrParams solrParams = new ModifiableSolrParams();
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_USER, getLdapUserName());
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_PASS, getLdapUserPasswd());
> DefaultHttpClient client = (DefaultHttpClient) 
> HttpClientUtil.createClient(solrParams);
> cloudSolrServer = new CloudSolrServer(zkEnsemble, new 
> LBHttpSolrServer(client));
> --
> I think it would be great necessary constructors in the SolrClient 
> implementations so that users can pass custom properties during 
> initialization.



--
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-8056) Add a Solrj client constructor to accept custom SolrParams

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-8056:
-
Summary: Add a Solrj client constructor to accept custom SolrParams  (was: 
Solrj client constructor does not accept custom SolrParams)

> Add a Solrj client constructor to accept custom SolrParams
> --
>
> Key: SOLR-8056
> URL: https://issues.apache.org/jira/browse/SOLR-8056
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: 4.10.3, Trunk
>Reporter: Hrishikesh Gadre
>Priority: Minor
>
> Solrj users can customize the Http client by overriding HttpClientConfigurer 
> class (e.g. Krb5HttpClientConfigurer). But Solrj does not allow this 
> customization at an individual SolrClient level. e.g. HttpSolrClient does not 
> have a constructor which accepts default SolrParams which would be passed 
> down to HttpClientUtil while creating an internal client.
> I observed this while working on supporting Basic authentication with Solr 
> (4.10.3) version. As a work-around, I had to use external Http client support 
> in Solr. e.g.
> -BEFORE--
> CloudSolrServer  cloudSolrServer = new CloudSolrServer(zkEnsemble);
> --AFTER
> ModifiableSolrParams solrParams = new ModifiableSolrParams();
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_USER, getLdapUserName());
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_PASS, getLdapUserPasswd());
> DefaultHttpClient client = (DefaultHttpClient) 
> HttpClientUtil.createClient(solrParams);
> cloudSolrServer = new CloudSolrServer(zkEnsemble, new 
> LBHttpSolrServer(client));
> --
> I think it would be great necessary constructors in the SolrClient 
> implementations so that users can pass custom properties during 
> initialization.



--
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-8056) Solrj client constructor does not accept custom SolrParams

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-8056:
-
Issue Type: Improvement  (was: Bug)

> Solrj client constructor does not accept custom SolrParams
> --
>
> Key: SOLR-8056
> URL: https://issues.apache.org/jira/browse/SOLR-8056
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: 4.10.3, Trunk
>Reporter: Hrishikesh Gadre
>Priority: Minor
>
> Solrj users can customize the Http client by overriding HttpClientConfigurer 
> class (e.g. Krb5HttpClientConfigurer). But Solrj does not allow this 
> customization at an individual SolrClient level. e.g. HttpSolrClient does not 
> have a constructor which accepts default SolrParams which would be passed 
> down to HttpClientUtil while creating an internal client.
> I observed this while working on supporting Basic authentication with Solr 
> (4.10.3) version. As a work-around, I had to use external Http client support 
> in Solr. e.g.
> -BEFORE--
> CloudSolrServer  cloudSolrServer = new CloudSolrServer(zkEnsemble);
> --AFTER
> ModifiableSolrParams solrParams = new ModifiableSolrParams();
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_USER, getLdapUserName());
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_PASS, getLdapUserPasswd());
> DefaultHttpClient client = (DefaultHttpClient) 
> HttpClientUtil.createClient(solrParams);
> cloudSolrServer = new CloudSolrServer(zkEnsemble, new 
> LBHttpSolrServer(client));
> --
> I think it would be great necessary constructors in the SolrClient 
> implementations so that users can pass custom properties during 
> initialization.



--
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-8034) If minRF is not satisfied, leader should not put replicas in recovery

[Jessica Cheng Mallet (JIRA)]

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

Jessica Cheng Mallet updated SOLR-8034:
---
Attachment: SOLR-8034.patch

> If minRF is not satisfied, leader should not put replicas in recovery
> -
>
> Key: SOLR-8034
> URL: https://issues.apache.org/jira/browse/SOLR-8034
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>  Labels: solrcloud
> Attachments: SOLR-8034.patch, SOLR-8034.patch
>
>
> If the minimum replication factor parameter (minRf) in a solr update request 
> is not satisfied -- i.e. if the update was not successfully applied on at 
> least n replicas where n >= minRf -- the shard leader should not put the 
> failed replicas in "leader initiated recovery" and the client should retry 
> the update instead.
> This is so that in the scenario were minRf is not satisfied, the failed 
> replicas can still be eligible to become a leader in case of leader failure, 
> since in the client's perspective this update did not succeed.
> This came up from a network partition scenario where the leader becomes 
> sectioned off from its two followers, but they all could still talk to 
> zookeeper. The partitioned leader set its two followers as in leader 
> initiated recovery, so we couldn't just kill off the partitioned node and 
> have a follower take over leadership. For a minRf=1 case, this is the correct 
> behavior because the partitioned leader would have accepted updates that the 
> followers don't have, and therefore we can't switch leadership or we'd lose 
> those updates. However, in the case of minRf=2, solr never accepted any 
> update in the client's point of view, so in fact the partitioned leader 
> doesn't have any accepted update that the followers don't have, and therefore 
> the followers should be eligible to become leaders. Thus, I'm proposing 
> modifying the leader initiated recovery logic to not put the followers in 
> recovery if the minRf parameter is present and is not satisfied.



--
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-7948) MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-7948:
-

[~markrmil...@gmail.com] - did you ever get anywhere with this issue? Are there 
any other ideas for workarounds?

> MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1
> -
>
> Key: SOLR-7948
> URL: https://issues.apache.org/jira/browse/SOLR-7948
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Affects Versions: 5.2.1
> Environment: OS:suse 11
> JDK:java version "1.7.0_65" 
> Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> HADOOP:hadoop 2.7.1 
> SOLR:5.2.1
>Reporter: davidchiu
>Assignee: Mark Miller
>
> When I used MapReduceIndexerTool of 5.2.1 to index files, I got follwoing 
> errors,but I used 4.9.0's MapReduceIndexerTool, it did work with hadoop 2.7.1.
> Exception ERROR as following:
> INFO  - 2015-08-20 11:44:45.155; [   ] org.apache.solr.hadoop.HeartBeater; 
> Heart beat reporting class is 
> org.apache.hadoop.mapreduce.task.TaskAttemptContextImpl
> INFO  - 2015-08-20 11:44:45.161; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Using this unpacked directory as 
> solr home: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
> INFO  - 2015-08-20 11:44:45.162; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Creating embedded Solr server with 
> solrHomeDir: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip,
>  fs: 
> DFS[DFSClient[clientName=DFSClient_attempt_1440040092614_0004_r_01_0_1678264055_1,
>  ugi=root (auth:SIMPLE)]], outputShardDir: 
> hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1
> INFO  - 2015-08-20 11:44:45.194; [   ] 
> org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for 
> directory: 
> '/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/'
> INFO  - 2015-08-20 11:44:45.206; [   ] org.apache.solr.hadoop.HeartBeater; 
> HeartBeat thread running
> INFO  - 2015-08-20 11:44:45.207; [   ] org.apache.solr.hadoop.HeartBeater; 
> Issuing heart beat for 1 threads
> INFO  - 2015-08-20 11:44:45.418; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Constructed instance information 
> solr.home 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
>  
> (/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip),
>  instance dir 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/,
>  conf dir 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/conf/,
>  writing index to solr.data.dir 
> hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1/data,
>  with permdir 
> hdfs://127.0.0.10:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1
> INFO  - 2015-08-20 11:44:45.426; [   ] org.apache.solr.core.SolrXmlConfig; 
> Loading container configuration from 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/solr.xml
> INFO  - 2015-08-20 11:44:45.474; [   ] 
> org.apache.solr.core.CorePropertiesLocator; Config-defined core root 
> directory: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
> INFO  - 2015-08-20 11:44:45.503; [   ] org.apache.solr.core.CoreContainer; 
> New CoreContainer 1656436773
> INFO  - 2015-08-20 11:44:45.503; [   ] org.apache.solr.core.CoreContainer; 
> Loading cores into CoreContainer 
> [instanceDir=/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/]
> 

[jira] [Comment Edited] (SOLR-8056) Solrj client constructor does not accept custom SolrParams

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-8056 at 9/15/15 4:00 PM:
---

Isn't it already supported? [~ichattopadhyaya]


was (Author: noble.paul):
Isn't it already supported?

> Solrj client constructor does not accept custom SolrParams
> --
>
> Key: SOLR-8056
> URL: https://issues.apache.org/jira/browse/SOLR-8056
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 4.10.3
>Reporter: Hrishikesh Gadre
>Priority: Minor
>
> Solrj users can customize the Http client by overriding HttpClientConfigurer 
> class (e.g. Krb5HttpClientConfigurer). But Solrj does not allow this 
> customization at an individual SolrClient level. e.g. HttpSolrClient does not 
> have a constructor which accepts default SolrParams which would be passed 
> down to HttpClientUtil while creating an internal client.
> I observed this while working on supporting Basic authentication with Solr 
> (4.10.3) version. As a work-around, I had to use external Http client support 
> in Solr. e.g.
> -BEFORE--
> CloudSolrServer  cloudSolrServer = new CloudSolrServer(zkEnsemble);
> --AFTER
> ModifiableSolrParams solrParams = new ModifiableSolrParams();
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_USER, getLdapUserName());
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_PASS, getLdapUserPasswd());
> DefaultHttpClient client = (DefaultHttpClient) 
> HttpClientUtil.createClient(solrParams);
> cloudSolrServer = new CloudSolrServer(zkEnsemble, new 
> LBHttpSolrServer(client));
> --
> I think it would be great necessary constructors in the SolrClient 
> implementations so that users can pass custom properties during 
> initialization.



--
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-6590) Explore different ways to apply boosts

[Terry Smith (JIRA)]

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

Terry Smith commented on LUCENE-6590:
-

Also FunctionQuery.


 



> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, 
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
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-8034) If minRF is not satisfied, leader should not put replicas in recovery

[Jessica Cheng Mallet (JIRA)]

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

Jessica Cheng Mallet commented on SOLR-8034:


Ah, and regarding

{quote}
I'm kind of split on this as the replica here would be out of sync from the 
leader and would never know about it, increasing the odds of inconsistency when 
the client doesn't handle it the right way i.e. it kind of self-heals at this 
point, and that would stop happening.
{quote}
I'd hope that if the user is explicitly using minRf that they handle it the 
right way (i.e. retry if minRf isn't achieved). The contract would be if the 
request fails, it needs to be retried or we can possibly see inconsistent 
state. I think this is true currently in a normal update if the forwarded 
parallel update to the followers succeeds but somehow it fails on the leader--a 
failure would be returned to the user but the update could be present on the 
followers. 

> If minRF is not satisfied, leader should not put replicas in recovery
> -
>
> Key: SOLR-8034
> URL: https://issues.apache.org/jira/browse/SOLR-8034
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>  Labels: solrcloud
> Attachments: SOLR-8034.patch, SOLR-8034.patch
>
>
> If the minimum replication factor parameter (minRf) in a solr update request 
> is not satisfied -- i.e. if the update was not successfully applied on at 
> least n replicas where n >= minRf -- the shard leader should not put the 
> failed replicas in "leader initiated recovery" and the client should retry 
> the update instead.
> This is so that in the scenario were minRf is not satisfied, the failed 
> replicas can still be eligible to become a leader in case of leader failure, 
> since in the client's perspective this update did not succeed.
> This came up from a network partition scenario where the leader becomes 
> sectioned off from its two followers, but they all could still talk to 
> zookeeper. The partitioned leader set its two followers as in leader 
> initiated recovery, so we couldn't just kill off the partitioned node and 
> have a follower take over leadership. For a minRf=1 case, this is the correct 
> behavior because the partitioned leader would have accepted updates that the 
> followers don't have, and therefore we can't switch leadership or we'd lose 
> those updates. However, in the case of minRf=2, solr never accepted any 
> update in the client's point of view, so in fact the partitioned leader 
> doesn't have any accepted update that the followers don't have, and therefore 
> the followers should be eligible to become leaders. Thus, I'm proposing 
> modifying the leader initiated recovery logic to not put the followers in 
> recovery if the minRf parameter is present and is not satisfied.



--
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-8029) Modernize and standardize Solr APIs

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8029:
--

Do you mean ,the introspect API returns the schema of the output?

> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: 6.0
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 3 types of requests in the new API 
> * {{/solr2//*}} : Operations on specific collections 
> * {{/solr2/_cluster/*}} : Cluster-wide operations which are not specific to 
> any collections. 
> * {{/solr2/_node/*}} : Operations on the node receiving the request. This is 
> the counter part of the core admin API
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



--
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-8053) support basic auth in SolrJ

[ASF subversion and git services (JIRA)]

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

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

Commit 1703145 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1703145 ]

SOLR-8053: Basic auth support in SolrJ

> support basic auth in SolrJ
> ---
>
> Key: SOLR-8053
> URL: https://issues.apache.org/jira/browse/SOLR-8053
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-8053.patch
>
>




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

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

[jira] [Commented] (SOLR-8055) ArrayIndexOutOfBoundsException seen in SOLR on running ToParentBlockJoinQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8055:


could you please check that queries are orthogonal:
q=*:*=visibility:show AND (stock:1)=type:scrap ?

Do you have deletes in the index?

> ArrayIndexOutOfBoundsException seen in SOLR on running ToParentBlockJoinQuery
> -
>
> Key: SOLR-8055
> URL: https://issues.apache.org/jira/browse/SOLR-8055
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0
>Reporter: Shekhar Palta
>
> On running the following query with q=*:* and fq=({!parent which=type:scrap 
> v='visibility:show AND (stock:1)'}) we ran into the following exception :
> java.lang.ArrayIndexOutOfBoundsException: 33554431\n\tat
> org.apache.lucene.util.FixedBitSet.get(FixedBitSet.java:150)\n\tat
> 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.nextDoc(ToParentBlockJoinQuery.java:284)\n\tat
> 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:177)\n\tat
> 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:148)\n\tat
> org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)\n\tat
> 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:592)\n\tat
> 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:284)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1264)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:951)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1109)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1630)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1506)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:586)\n\tat
> 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:511)\n\tat
> 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:227)\n\tat
> 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)\n\tat
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2006)\n\tat
> 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
> 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:413)\n\tat
> 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:204)\n\tat
> 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
> 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
> This used to run perfectly fine before. We increased the memory for SOLR from 
> 3000M to 4096M and ran Optimise again and things seemed to work fine. I want 
> to understand if this can occur again and the steps we need to take to 
> prevent it from  occurring



--
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-8055) ArrayIndexOutOfBoundsException seen in SOLR on running ToParentBlockJoinQuery

[Shekhar Palta (JIRA)]

Shekhar Palta created SOLR-8055:
---

 Summary: ArrayIndexOutOfBoundsException seen in SOLR on running 
ToParentBlockJoinQuery
 Key: SOLR-8055
 URL: https://issues.apache.org/jira/browse/SOLR-8055
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.0
Reporter: Shekhar Palta


On running the following query with q=*:* and fq=({!parent which=type:scrap 
v='visibility:show AND (stock:1)'}) we ran into the following exception :

java.lang.ArrayIndexOutOfBoundsException: 33554431\n\tat
org.apache.lucene.util.FixedBitSet.get(FixedBitSet.java:150)\n\tat

org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.nextDoc(ToParentBlockJoinQuery.java:284)\n\tat

org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:177)\n\tat

org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:148)\n\tat
org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)\n\tat
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:592)\n\tat
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:284)\n\tat

org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1264)\n\tat

org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:951)\n\tat

org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1109)\n\tat

org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1630)\n\tat

org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1506)\n\tat

org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:586)\n\tat

org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:511)\n\tat

org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:227)\n\tat

org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)\n\tat
org.apache.solr.core.SolrCore.execute(SolrCore.java:2006)\n\tat

org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat

org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:413)\n\tat

org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:204)\n\tat

org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat

org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat



This used to run perfectly fine before. We increased the memory for SOLR from 
3000M to 4096M and ran Optimise again and things seemed to work fine. I want to 
understand if this can occur again and the steps we need to take to prevent it 
from  occurring



--
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-6785) Consider merging Query.rewrite() into Query.createWeight()

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-6785:
---

[~jpountz] are you happy with the latest patch?  Or do you want to try your 
alternative API above?

> Consider merging Query.rewrite() into Query.createWeight()
> --
>
> Key: LUCENE-6785
> URL: https://issues.apache.org/jira/browse/LUCENE-6785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
> Attachments: LUCENE-6785.patch, LUCENE-6785.patch
>
>
> Prompted by the discussion on LUCENE-6590.
> Query.rewrite() is a bit of an oddity.  You call it to create a query for a 
> specific IndexSearcher, and to ensure that you get a query implementation 
> that has a working createWeight() method.  However, Weight itself already 
> encapsulates the notion of a per-searcher query.
> You also need to repeatedly call rewrite() until the query has stopped 
> rewriting itself, which is a bit trappy - there are a few places (in 
> highlighting code for example) that just call rewrite() once, rather than 
> looping round as IndexSearcher.rewrite() does.  Most queries don't need to be 
> called multiple times, however, so this seems a bit redundant.  And the ones 
> that do currently return un-rewritten queries can be changed simply enough to 
> rewrite them.
> Finally, in pretty much every case I can find in the codebase, rewrite() is 
> called purely as a prelude to createWeight().  This means, in the case of for 
> example large BooleanQueries, we end up cloning the whole query structure, 
> only to throw it away immediately.
> I'd like to try removing rewrite() entirely, and merging the logic into 
> createWeight(), simplifying the API and removing the trap where code only 
> calls rewrite once.  What do people think?



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

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

[jira] [Created] (LUCENE-6807) AbstractRangeQueryNode toQueryString not working as intended

[Peter Barna (JIRA)]

Peter Barna created LUCENE-6807:
---

 Summary: AbstractRangeQueryNode toQueryString not working as 
intended
 Key: LUCENE-6807
 URL: https://issues.apache.org/jira/browse/LUCENE-6807
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/queryparser
Affects Versions: 5.3
Reporter: Peter Barna
Priority: Minor


It is my understanding that for a given {{QueryNode}} node, 
{{parse(node.toQueryString());}} should return a {{QueryNode}} which is 
functionally identical to the original node.

That is not the case with AbstractQueryNode:
if we have a range query on FIELD from "A" to "B" ({{node = parse("FIELD:[A 
B]")}}), then {{node.toQueryString()}} will return "[FIELD:A FIELD:B]" which, 
in turn, is parsed as a range query on the default field from "FIELD:A" to 
"FIELD:B".

As far as I know, this affects all versions of lucene.

I believe I have the knowledge to provide the patch, so I will be working on 
that today.

As of now, I have thought of two options to implement this fix, both of which 
involve modifying the {{ValueQueryNode}} interface to include a method which 
returns {{value}} as a {{CharSequence}}. 

The first option is to add a new method to the interface which returns 
(formatted if necessary) the value as a {{CharSequence}} and implement it in 
all implementing classes ({{FieldQueryNode}} and {{NumericQueryNode}}). Then in 
{{AbstractQueryNode#toQueryString()}} we will call that method and escape the 
values using the provided {{EscapeQuerySyntax}}.

The second option is to make the protected method {{getTermEscaped()}}, which 
is already present in all implementing classes, public, and add it to the 
interface.

While I think that the second option is certainly cleaner, I do not know why 
this method is protected in the first place, so I will proceed with the first 
option until someone who is more familiar with the lucene project than I am can 
comment on the matter.

As I am writing this, it occurs to me that implementing the first option is 
essentially just bypassing the protected scope on {{getTermEscapeed()}}, so 
maybe it is correct to just review whether or not that method needs to be 
protected. It also occurred to me to use the existing {{getValue()}} method, 
and format and escape the {{toString()}} of that, but that depends on a generic 
class having implemented {{toString()}} in a way that plays nicely with the 
query parser, so, to me, this is below the two previously mentioned options.



--
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-6779) Reduce memory allocated by CompressingStoredFieldsWriter to write large strings

[ASF subversion and git services (JIRA)]

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

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

Commit 1703231 from sha...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1703231 ]

LUCENE-6779: Reduce memory allocated by CompressingStoredFieldsWriter to write 
strings larger than 64kb by an amount equal to string's utf8 size

> Reduce memory allocated by CompressingStoredFieldsWriter to write large 
> strings
> ---
>
> Key: LUCENE-6779
> URL: https://issues.apache.org/jira/browse/LUCENE-6779
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/codecs
>Reporter: Shalin Shekhar Mangar
> Attachments: LUCENE-6779.patch, LUCENE-6779.patch, LUCENE-6779.patch, 
> LUCENE-6779.patch, LUCENE-6779_alt.patch
>
>
> In SOLR-7927, I am trying to reduce the memory required to index very large 
> documents (between 10 to 100MB) and one of the places which allocate a lot of 
> heap is the UTF8 encoding in CompressingStoredFieldsWriter. The same problem 
> existed in JavaBinCodec and we reduced its memory allocation by falling back 
> to a double pass approach in SOLR-7971 when the utf8 size of the string is 
> greater than 64KB.
> I propose to make the same changes to CompressingStoredFieldsWriter as we 
> made to JavaBinCodec in SOLR-7971.



--
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-7948) MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7948:
---

In the end, you have to harmonize the httpclient jars it seems.

I updated my example project to work with Solr 5.2.1, so it does work: 
https://github.com/markrmiller/solr-map-reduce-example

In this case it meant adding the following to the script:

{noformat}
## Harmonize Conflicting Jar Dependencies
###

# Hadoop uses a lower version than Solr and the flags to use user libs first 
don't help this conflict
solr_http_client_version=4.4.1

find $hadoop_distrib -name "httpclient-*.jar" -type f -exec rm {} \;
find $hadoop_distrib -name "httpcore-*.jar" -type f -exec rm {} \;

solr_client=$solr_distrib/server/solr-webapp/webapp/WEB-INF/lib/httpclient-$solr_http_client_version.jar
solr_core=$solr_distrib/server/solr-webapp/webapp/WEB-INF/lib/httpcore-$solr_http_client_version.jar

cp $solr_client $hadoop_distrib/share/hadoop/tools/lib
cp $solr_corer $hadoop_distrib/share/hadoop/tools/lib

cp $solr_client $hadoop_distrib/share/hadoop/kms/tomcat/webapps/kms/WEB-INF/lib
cp $solr_corer $hadoop_distrib/share/hadoop/kms/tomcat/webapps/kms/WEB-INF/lib

cp $solr_client 
$hadoop_distrib/share/hadoop/httpfs/tomcat/webapps/webhdfs/WEB-INF/lib
cp $solr_corer 
$hadoop_distrib/share/hadoop/httpfs/tomcat/webapps/webhdfs/WEB-INF/lib

cp $solr_client $hadoop_distrib/share/hadoop/common/lib
cp $solr_corer $hadoop_distrib/share/hadoop/common/lib
{noformat}

> MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1
> -
>
> Key: SOLR-7948
> URL: https://issues.apache.org/jira/browse/SOLR-7948
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Affects Versions: 5.2.1
> Environment: OS:suse 11
> JDK:java version "1.7.0_65" 
> Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> HADOOP:hadoop 2.7.1 
> SOLR:5.2.1
>Reporter: davidchiu
>Assignee: Mark Miller
>
> When I used MapReduceIndexerTool of 5.2.1 to index files, I got follwoing 
> errors,but I used 4.9.0's MapReduceIndexerTool, it did work with hadoop 2.7.1.
> Exception ERROR as following:
> INFO  - 2015-08-20 11:44:45.155; [   ] org.apache.solr.hadoop.HeartBeater; 
> Heart beat reporting class is 
> org.apache.hadoop.mapreduce.task.TaskAttemptContextImpl
> INFO  - 2015-08-20 11:44:45.161; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Using this unpacked directory as 
> solr home: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
> INFO  - 2015-08-20 11:44:45.162; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Creating embedded Solr server with 
> solrHomeDir: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip,
>  fs: 
> DFS[DFSClient[clientName=DFSClient_attempt_1440040092614_0004_r_01_0_1678264055_1,
>  ugi=root (auth:SIMPLE)]], outputShardDir: 
> hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1
> INFO  - 2015-08-20 11:44:45.194; [   ] 
> org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for 
> directory: 
> '/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/'
> INFO  - 2015-08-20 11:44:45.206; [   ] org.apache.solr.hadoop.HeartBeater; 
> HeartBeat thread running
> INFO  - 2015-08-20 11:44:45.207; [   ] org.apache.solr.hadoop.HeartBeater; 
> Issuing heart beat for 1 threads
> INFO  - 2015-08-20 11:44:45.418; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Constructed instance information 
> solr.home 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
>  
> (/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip),
>  instance dir 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/,
>  conf dir 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/conf/,
>  writing index to solr.data.dir 
> 

[jira] [Commented] (SOLR-8056) Solrj client constructor does not accept custom SolrParams

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-8056:


I see following three constructors for HttpSolrClient (on trunk)

public HttpSolrClient(String baseURL)
public HttpSolrClient(String baseURL, HttpClient client)
public HttpSolrClient(String baseURL, HttpClient client, ResponseParser parser)

As I mentioned in the description, it is currently possible to provide a custom 
HttpClient. But solrj doesn't do any cleanup and it is left to the application. 
If we provide this support, application won't need to worry about connection 
management as well. Let me know if I have missed anything.

> Solrj client constructor does not accept custom SolrParams
> --
>
> Key: SOLR-8056
> URL: https://issues.apache.org/jira/browse/SOLR-8056
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 4.10.3
>Reporter: Hrishikesh Gadre
>Priority: Minor
>
> Solrj users can customize the Http client by overriding HttpClientConfigurer 
> class (e.g. Krb5HttpClientConfigurer). But Solrj does not allow this 
> customization at an individual SolrClient level. e.g. HttpSolrClient does not 
> have a constructor which accepts default SolrParams which would be passed 
> down to HttpClientUtil while creating an internal client.
> I observed this while working on supporting Basic authentication with Solr 
> (4.10.3) version. As a work-around, I had to use external Http client support 
> in Solr. e.g.
> -BEFORE--
> CloudSolrServer  cloudSolrServer = new CloudSolrServer(zkEnsemble);
> --AFTER
> ModifiableSolrParams solrParams = new ModifiableSolrParams();
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_USER, getLdapUserName());
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_PASS, getLdapUserPasswd());
> DefaultHttpClient client = (DefaultHttpClient) 
> HttpClientUtil.createClient(solrParams);
> cloudSolrServer = new CloudSolrServer(zkEnsemble, new 
> LBHttpSolrServer(client));
> --
> I think it would be great necessary constructors in the SolrClient 
> implementations so that users can pass custom properties during 
> initialization.



--
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-8056) Solrj client constructor does not accept custom SolrParams

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre updated SOLR-8056:
---
Affects Version/s: Trunk

> Solrj client constructor does not accept custom SolrParams
> --
>
> Key: SOLR-8056
> URL: https://issues.apache.org/jira/browse/SOLR-8056
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 4.10.3, Trunk
>Reporter: Hrishikesh Gadre
>Priority: Minor
>
> Solrj users can customize the Http client by overriding HttpClientConfigurer 
> class (e.g. Krb5HttpClientConfigurer). But Solrj does not allow this 
> customization at an individual SolrClient level. e.g. HttpSolrClient does not 
> have a constructor which accepts default SolrParams which would be passed 
> down to HttpClientUtil while creating an internal client.
> I observed this while working on supporting Basic authentication with Solr 
> (4.10.3) version. As a work-around, I had to use external Http client support 
> in Solr. e.g.
> -BEFORE--
> CloudSolrServer  cloudSolrServer = new CloudSolrServer(zkEnsemble);
> --AFTER
> ModifiableSolrParams solrParams = new ModifiableSolrParams();
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_USER, getLdapUserName());
> solrParams.set(HttpClientUtil.PROP_BASIC_AUTH_PASS, getLdapUserPasswd());
> DefaultHttpClient client = (DefaultHttpClient) 
> HttpClientUtil.createClient(solrParams);
> cloudSolrServer = new CloudSolrServer(zkEnsemble, new 
> LBHttpSolrServer(client));
> --
> I think it would be great necessary constructors in the SolrClient 
> implementations so that users can pass custom properties during 
> initialization.



--
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-6590) Explore different ways to apply boosts

[Terry Smith (JIRA)]

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

Terry Smith commented on LUCENE-6590:
-

Hmm, so is NumericRangeQuery.

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, 
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
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-8034) If minRF is not satisfied, leader should not put replicas in recovery

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8034:


Thanks for fixing the assert.

bq.replica will not realize it's down on its own since the partition is between 
the leader and the replica, not between the replica and zookeeper – so it won't 
be set to down until the leader tries to forward the document to it and fails

Right, should've realized that.

Also, about my opinion being split, I wasn't in on this, but I thought more and 
it makes more sense to go with this.

Thanks [~mewmewball] . LGTM overall, I'll commit this.

> If minRF is not satisfied, leader should not put replicas in recovery
> -
>
> Key: SOLR-8034
> URL: https://issues.apache.org/jira/browse/SOLR-8034
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>  Labels: solrcloud
> Attachments: SOLR-8034.patch, SOLR-8034.patch
>
>
> If the minimum replication factor parameter (minRf) in a solr update request 
> is not satisfied -- i.e. if the update was not successfully applied on at 
> least n replicas where n >= minRf -- the shard leader should not put the 
> failed replicas in "leader initiated recovery" and the client should retry 
> the update instead.
> This is so that in the scenario were minRf is not satisfied, the failed 
> replicas can still be eligible to become a leader in case of leader failure, 
> since in the client's perspective this update did not succeed.
> This came up from a network partition scenario where the leader becomes 
> sectioned off from its two followers, but they all could still talk to 
> zookeeper. The partitioned leader set its two followers as in leader 
> initiated recovery, so we couldn't just kill off the partitioned node and 
> have a follower take over leadership. For a minRf=1 case, this is the correct 
> behavior because the partitioned leader would have accepted updates that the 
> followers don't have, and therefore we can't switch leadership or we'd lose 
> those updates. However, in the case of minRf=2, solr never accepted any 
> update in the client's point of view, so in fact the partitioned leader 
> doesn't have any accepted update that the followers don't have, and therefore 
> the followers should be eligible to become leaders. Thus, I'm proposing 
> modifying the leader initiated recovery logic to not put the followers in 
> recovery if the minRf parameter is present and is not satisfied.



--
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-8034) If minRF is not satisfied, leader should not put replicas in recovery

[Anshum Gupta (JIRA)]

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

Anshum Gupta reassigned SOLR-8034:
--

Assignee: Anshum Gupta

> If minRF is not satisfied, leader should not put replicas in recovery
> -
>
> Key: SOLR-8034
> URL: https://issues.apache.org/jira/browse/SOLR-8034
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>Assignee: Anshum Gupta
>  Labels: solrcloud
> Attachments: SOLR-8034.patch, SOLR-8034.patch
>
>
> If the minimum replication factor parameter (minRf) in a solr update request 
> is not satisfied -- i.e. if the update was not successfully applied on at 
> least n replicas where n >= minRf -- the shard leader should not put the 
> failed replicas in "leader initiated recovery" and the client should retry 
> the update instead.
> This is so that in the scenario were minRf is not satisfied, the failed 
> replicas can still be eligible to become a leader in case of leader failure, 
> since in the client's perspective this update did not succeed.
> This came up from a network partition scenario where the leader becomes 
> sectioned off from its two followers, but they all could still talk to 
> zookeeper. The partitioned leader set its two followers as in leader 
> initiated recovery, so we couldn't just kill off the partitioned node and 
> have a follower take over leadership. For a minRf=1 case, this is the correct 
> behavior because the partitioned leader would have accepted updates that the 
> followers don't have, and therefore we can't switch leadership or we'd lose 
> those updates. However, in the case of minRf=2, solr never accepted any 
> update in the client's point of view, so in fact the partitioned leader 
> doesn't have any accepted update that the followers don't have, and therefore 
> the followers should be eligible to become leaders. Thus, I'm proposing 
> modifying the leader initiated recovery logic to not put the followers in 
> recovery if the minRf parameter is present and is not satisfied.



--
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 (64bit/jdk1.8.0) - Build # 55 - Failure!

[Policeman Jenkins Server]

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

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

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

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:52281 within 3 ms
at 
__randomizedtesting.SeedInfo.seed([2DF5854D75C9D0C0:A5A1BA97DB35BD38]: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:260)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:365)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.concurrent.TimeoutException: Could not connect to 
ZooKeeper 127.0.0.1:52281 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.DistribCursorPagingTest

Re: Please vote for the 2nd release candidate for Lucene/Solr 5.3.1

[Yonik Seeley]

+1

-Yonik

On Sun, Sep 13, 2015 at 2:59 AM, Noble Paul  wrote:
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.1-RC2-rev1702683/
>
> You can run the smoke tester directly with this command:
> python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.1-RC2-rev1702683/
>
>
> +1
>
>
> SUCCESS! [0:55:00.971757]
>
> --
> -
> Noble Paul
>
> -
> 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] [Commented] (SOLR-8034) If minRF is not satisfied, leader should not put replicas in recovery

[Jessica Cheng Mallet (JIRA)]

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

Jessica Cheng Mallet commented on SOLR-8034:


[~anshumg], I fixed the comment for the assertion, but I didn't add the test 
that the replica is down after the first network partition, because the point 
is that the replica will not realize it's down on its own since the partition 
is between the leader and the replica, not between the replica and zookeeper -- 
so it won't be set to down until the leader tries to forward the document to it 
and fails, and then set it in leader-initiated-recovery.

[~tpot], we discussed this in ticket 4072.

> If minRF is not satisfied, leader should not put replicas in recovery
> -
>
> Key: SOLR-8034
> URL: https://issues.apache.org/jira/browse/SOLR-8034
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>  Labels: solrcloud
> Attachments: SOLR-8034.patch, SOLR-8034.patch
>
>
> If the minimum replication factor parameter (minRf) in a solr update request 
> is not satisfied -- i.e. if the update was not successfully applied on at 
> least n replicas where n >= minRf -- the shard leader should not put the 
> failed replicas in "leader initiated recovery" and the client should retry 
> the update instead.
> This is so that in the scenario were minRf is not satisfied, the failed 
> replicas can still be eligible to become a leader in case of leader failure, 
> since in the client's perspective this update did not succeed.
> This came up from a network partition scenario where the leader becomes 
> sectioned off from its two followers, but they all could still talk to 
> zookeeper. The partitioned leader set its two followers as in leader 
> initiated recovery, so we couldn't just kill off the partitioned node and 
> have a follower take over leadership. For a minRf=1 case, this is the correct 
> behavior because the partitioned leader would have accepted updates that the 
> followers don't have, and therefore we can't switch leadership or we'd lose 
> those updates. However, in the case of minRf=2, solr never accepted any 
> update in the client's point of view, so in fact the partitioned leader 
> doesn't have any accepted update that the followers don't have, and therefore 
> the followers should be eligible to become leaders. Thus, I'm proposing 
> modifying the leader initiated recovery logic to not put the followers in 
> recovery if the minRf parameter is present and is not satisfied.



--
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-7913) Add stream.body support to MLT QParser

[Steve Molloy (JIRA)]

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

Steve Molloy updated SOLR-7913:
---
Attachment: SOLR-7913.patch

Patch allowing to use stream.body in mlt QParser. Need to align RequestUtil 
logic and TestRemoteStreaming, both of which would prevent stream from getting 
to QParser in there current state. Hacked the RequestUtil and ignored one of 
the TestRemoteStreaming for now, everything else passes on 5.3.1 code and 
applies cleanly on trunk.

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
> Attachments: SOLR-7913.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
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-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7666:
-

(Solr 5.3, Windows, Chrome) Logging screen, once visited, does not stop calling 
XHR even when navigating to the other screens.

E.g. 
http://localhost:8983/solr/admin/info/logging?_=1442346075922=0=json 
(every 10 seconds)

> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



--
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-6780) GeoPointDistanceQuery doesn't work with a large radius?

[ASF subversion and git services (JIRA)]

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

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

Commit 1703281 from [~mikemccand] in branch 'dev/branches/lucene6780'
[ https://svn.apache.org/r1703281 ]

LUCENE-6780: let random radius be big

> GeoPointDistanceQuery doesn't work with a large radius?
> ---
>
> Key: LUCENE-6780
> URL: https://issues.apache.org/jira/browse/LUCENE-6780
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Attachments: LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch, 
> LUCENE-6780.patch, LUCENE-6780.patch
>
>
> I'm working on LUCENE-6698 but struggling with test failures ...
> Then I noticed that TestGeoPointQuery's test never tests on large distances, 
> so I modified the test to sometimes do so (like TestBKDTree) and hit test 
> failures.



--
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-8058) Collections that start with css*, js*, img*, and tpl* can't be accessed as they match the exclusion filter

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8058:


I agree, and while working on this, I did think about moving things to a single 
static root, but that was reasonably invasive so decided against it at that 
point.
About things ending in {{.css}}, it's better I think to just document the 
_exact_ static directory names to be reserved keywords for Solr. I'm open to 
suggestions though.

> Collections that start with css*, js*, img*, and tpl* can't be accessed as 
> they match the exclusion filter
> --
>
> Key: SOLR-8058
> URL: https://issues.apache.org/jira/browse/SOLR-8058
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
>
> Collections that match css*, js*, img*, and tpl* can't be reached as the SDF 
> short circuits paths that match those regular expressions.
> It should have only short circuited exact matches for those directories i.e.
> \css/*,/js/*,/img/*,/tpl/* but that doesn't seem to be the case.
> Need to fix this regular expression so that the collection can be reached.



--
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-8029) Modernize and standardize Solr APIs

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar commented on SOLR-8029:
-

bq. Do you mean ,the introspect API returns the schema of the output?

Schema for both the input and output, yes.

> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: 6.0
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 3 types of requests in the new API 
> * {{/solr2//*}} : Operations on specific collections 
> * {{/solr2/_cluster/*}} : Cluster-wide operations which are not specific to 
> any collections. 
> * {{/solr2/_node/*}} : Operations on the node receiving the request. This is 
> the counter part of the core admin API
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



--
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: Couple of AngularJS issues in Solr 5.3

[Alexandre Rafalovitch]

I cannot re-open the ticket. I am but a lowly user, the commit/reopen
powers are not mine :-)

I'll keep putting issues into there then and let you route them as appropriate.

Regards,
   Alex.

Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter:
http://www.solr-start.com/


On 15 September 2015 at 16:24, Upayavira  wrote:
> They are small details - I'm happy for you to re-open that ticket, and
> I'll sort them from there.
>
> Thanks for testing - really appreciated!
>
> Upayavira
>
> On Tue, Sep 15, 2015, at 09:18 PM, Alexandre Rafalovitch wrote:
>> I've hit a couple of issues in the new UI for Solr 5.3.
>>
>> I have posted them to SOLR-7666, not realizing that it was a closed
>> ticket.
>>
>> Not sure what the next step is. Should I repost them to a better JIRA,
>> create individual Jira for each (and link to ???) or something else.
>>
>> The issues I saw were:
>> *) Query screen form is not populated when clicking from the "Load
>> Terms" section
>> *) Logging screen does not stop calling "more logs" URL even when user
>> goes to different part of UI
>> *) Document screen submit button seems to be not wired it for several
>> types of submission.
>>
>> Regards,
>>Alex.
>>
>> -
>> 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
>

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

[jira] [Commented] (SOLR-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7666:
-

When clicking from *term value* link to the query screen, it does not seem that 
the query value is actually used.

Reproduction:
*) Solr 5.3, techproducts example
*)  http://localhost:8983/solr/index.html#/techproducts/schema-browser?field=cat
*) Load Term Info
*) Click on 'electronics' or any other
*) We go to 
http://localhost:8983/solr/index.html#/techproducts/query?q=cat:electronics
*) The search screen shows no results and boxes are not pre-populated with the 
*cat:electronics'"

> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



--
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-4968) The collection alias api should have a list cmd.

[Steve Molloy (JIRA)]

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

Steve Molloy updated SOLR-4968:
---
Attachment: SOLR-4968.patch

Same patch without the eclipse workspace part in the paths (not sure why 
eclipse added those)

> The collection alias api should have a list cmd.
> 
>
> Key: SOLR-4968
> URL: https://issues.apache.org/jira/browse/SOLR-4968
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-4968.patch, SOLR-4968.patch, SOLR-4968.patch
>
>




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

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

[jira] [Commented] (LUCENE-6698) Add BKDDistanceQuery

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6698:


I committed the current patch on the 
https://svn.apache.org/repos/asf/lucene/dev/branches/lucene6780 branch but the 
test is still failing ... but {{TestGeoPointQuery}} seems to be failing in the 
same way when I make its test similarly evil, so hopefully there is a single 
root cause :)

> Add BKDDistanceQuery
> 
>
> Key: LUCENE-6698
> URL: https://issues.apache.org/jira/browse/LUCENE-6698
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: LUCENE-6698.patch
>
>
> Our BKD tree impl should be very fast at doing "distance from lat/lon center 
> point < X" query.
> I haven't started this ... [~nknize] expressed interest in working on it.



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

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

Re: Couple of AngularJS issues in Solr 5.3

[Upayavira]

They are small details - I'm happy for you to re-open that ticket, and
I'll sort them from there.

Thanks for testing - really appreciated!

Upayavira

On Tue, Sep 15, 2015, at 09:18 PM, Alexandre Rafalovitch wrote:
> I've hit a couple of issues in the new UI for Solr 5.3.
> 
> I have posted them to SOLR-7666, not realizing that it was a closed
> ticket.
> 
> Not sure what the next step is. Should I repost them to a better JIRA,
> create individual Jira for each (and link to ???) or something else.
> 
> The issues I saw were:
> *) Query screen form is not populated when clicking from the "Load
> Terms" section
> *) Logging screen does not stop calling "more logs" URL even when user
> goes to different part of UI
> *) Document screen submit button seems to be not wired it for several
> types of submission.
> 
> Regards,
>Alex.
> 
> -
> 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] [Commented] (SOLR-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7666:
-

(Solr 5.3, Windows, Chrome and Firefox), Dashboard screen:
The bars under *System* (all three) are uniform color and missing size 
information. Just grey bars. The same instance in default UI shows usage 
percentages, bar is partially filled, etc.

JVM/Args parameter is empty. In default UI, it has a long list of values. The 
other two values (Runtime and Processors) are ok.

> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



--
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: Couple of AngularJS issues in Solr 5.3

[Upayavira]

I've re-opened it - keep putting them there. Thanks!

On Tue, Sep 15, 2015, at 09:27 PM, Alexandre Rafalovitch wrote:
> I cannot re-open the ticket. I am but a lowly user, the commit/reopen
> powers are not mine :-)
> 
> I'll keep putting issues into there then and let you route them as
> appropriate.
> 
> Regards,
>Alex.
> 
> Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter:
> http://www.solr-start.com/
> 
> 
> On 15 September 2015 at 16:24, Upayavira  wrote:
> > They are small details - I'm happy for you to re-open that ticket, and
> > I'll sort them from there.
> >
> > Thanks for testing - really appreciated!
> >
> > Upayavira
> >
> > On Tue, Sep 15, 2015, at 09:18 PM, Alexandre Rafalovitch wrote:
> >> I've hit a couple of issues in the new UI for Solr 5.3.
> >>
> >> I have posted them to SOLR-7666, not realizing that it was a closed
> >> ticket.
> >>
> >> Not sure what the next step is. Should I repost them to a better JIRA,
> >> create individual Jira for each (and link to ???) or something else.
> >>
> >> The issues I saw were:
> >> *) Query screen form is not populated when clicking from the "Load
> >> Terms" section
> >> *) Logging screen does not stop calling "more logs" URL even when user
> >> goes to different part of UI
> >> *) Document screen submit button seems to be not wired it for several
> >> types of submission.
> >>
> >> Regards,
> >>Alex.
> >>
> >> -
> >> 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
> >
> 
> -
> 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] [Commented] (SOLR-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7666:
-

(Solr 5.3, Windows, Chrome) *Documents* screen is not working when clicking 
*Submit Document* button. Seems to happen with JSON and Document Builder types. 
Others seem to react. The exception trace in the console:
{quote}
ReferenceError: callack is not defined
at Scope.$scope.submit (documents.js:119)
at $parseFunctionCall (angular.js:12355)
at callback (angular.js:22972)
at Scope.$eval (angular.js:14406)
at Scope.$apply (angular.js:14505)
at HTMLButtonElement. (angular.js:22977)
at HTMLButtonElement.n.event.dispatch (jquery-2.1.3.min.js:28)
at HTMLButtonElement.r.handle (jquery-2.1.3.min.js:28)
{quote}


> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



--
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-6780) GeoPointDistanceQuery doesn't work with a large radius?

[ASF subversion and git services (JIRA)]

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

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

Commit 1703282 from [~mikemccand] in branch 'dev/branches/lucene6780'
[ https://svn.apache.org/r1703282 ]

LUCENE-6698, LUCENE-6780: add BKDDistanceQuery

> GeoPointDistanceQuery doesn't work with a large radius?
> ---
>
> Key: LUCENE-6780
> URL: https://issues.apache.org/jira/browse/LUCENE-6780
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Attachments: LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch, 
> LUCENE-6780.patch, LUCENE-6780.patch
>
>
> I'm working on LUCENE-6698 but struggling with test failures ...
> Then I noticed that TestGeoPointQuery's test never tests on large distances, 
> so I modified the test to sometimes do so (like TestBKDTree) and hit test 
> failures.



--
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-6698) Add BKDDistanceQuery

[ASF subversion and git services (JIRA)]

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

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

Commit 1703282 from [~mikemccand] in branch 'dev/branches/lucene6780'
[ https://svn.apache.org/r1703282 ]

LUCENE-6698, LUCENE-6780: add BKDDistanceQuery

> Add BKDDistanceQuery
> 
>
> Key: LUCENE-6698
> URL: https://issues.apache.org/jira/browse/LUCENE-6698
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: LUCENE-6698.patch
>
>
> Our BKD tree impl should be very fast at doing "distance from lat/lon center 
> point < X" query.
> I haven't started this ... [~nknize] expressed interest in working on it.



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

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

[jira] [Commented] (LUCENE-6780) GeoPointDistanceQuery doesn't work with a large radius?

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6780:


I was working on getting {{BKDDistanceQuery}} working again, but hit failures 
with a large radius, so I also fixed {{TestGeoPointQuery}} to use a large 
radius (just committed) and it causes test failures, e.g.:

{noformat}
[junit4:pickseed] Seed property 'tests.seed' already defined: 651AF6100346C910
   [junit4]  says g'day! Master seed: 651AF6100346C910
   [junit4] Executing 1 suite with 1 JVM.
   [junit4] 
   [junit4] Started J0 PID(28673@localhost).
   [junit4] Suite: org.apache.lucene.search.TestGeoPointQuery
   [junit4]   1> T0: id=5 docID=5 lat=-30.70619555695309 
lon=-119.07908745059306 deleted?=false expected=false but got true 
query=GeoPointDistanceQuery: field=geoField: Center: 
[119.51155579512795,-29.46313019984308] Distance: 9353340.676650032 meters]
   [junit4]   2> Zář 15, 2015 10:00:15 ODP. 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[T0,5,TGRP-TestGeoPointQuery]
   [junit4]   2> java.lang.AssertionError: wrong hit
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([651AF6100346C910]:0)
   [junit4]   2>at org.junit.Assert.fail(Assert.java:93)
   [junit4]   2>at 
org.apache.lucene.search.TestGeoPointQuery$VerifyHits.test(TestGeoPointQuery.java:560)
   [junit4]   2>at 
org.apache.lucene.search.TestGeoPointQuery$1._run(TestGeoPointQuery.java:501)
   [junit4]   2>at 
org.apache.lucene.search.TestGeoPointQuery$1.run(TestGeoPointQuery.java:396)
   [junit4]   2> 
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeoPointQuery 
-Dtests.method=testRandomTiny -Dtests.seed=651AF6100346C910 
-Dtests.multiplier=5 -Dtests.locale=cs -Dtests.timezone=Africa/Windhoek 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.24s | TestGeoPointQuery.testRandomTiny <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=14, name=T0, state=RUNNABLE, 
group=TGRP-TestGeoPointQuery]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([651AF6100346C910:2C5D28565D67F1BC]:0)
   [junit4]> Caused by: java.lang.AssertionError: wrong hit
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([651AF6100346C910]:0)
   [junit4]>at 
org.apache.lucene.search.TestGeoPointQuery$VerifyHits.test(TestGeoPointQuery.java:560)
   [junit4]>at 
org.apache.lucene.search.TestGeoPointQuery$1._run(TestGeoPointQuery.java:501)
   [junit4]>at 
org.apache.lucene.search.TestGeoPointQuery$1.run(TestGeoPointQuery.java:396)
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene53): 
{id=PostingsFormat(name=LuceneVarGapFixedInterval), geoField=FST50}, 
docValues:{id=DocValuesFormat(name=Direct), 
geoField=DocValuesFormat(name=Lucene50)}, 
sim=RandomSimilarityProvider(queryNorm=false,coord=yes): {}, locale=cs, 
timezone=Africa/Windhoek
   [junit4]   2> NOTE: Linux 3.13.0-61-generic amd64/Oracle Corporation 
1.8.0_40 (64-bit)/cpus=8,threads=1,free=383358232,total=504889344
   [junit4]   2> NOTE: All tests run in this JVM: [TestGeoPointQuery]
   [junit4] Completed [1/1] in 0.57s, 1 test, 1 error <<< FAILURES!
   [junit4] 
   [junit4] 
   [junit4] Tests with failures:
   [junit4]   - org.apache.lucene.search.TestGeoPointQuery.testRandomTiny
{noformat}

A very large radius (such that it can span the entire earth) should work?

I'll also commit how far I got with the {{BKDDistanceQuery}} to the branch ...

> GeoPointDistanceQuery doesn't work with a large radius?
> ---
>
> Key: LUCENE-6780
> URL: https://issues.apache.org/jira/browse/LUCENE-6780
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Attachments: LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch, 
> LUCENE-6780.patch, LUCENE-6780.patch
>
>
> I'm working on LUCENE-6698 but struggling with test failures ...
> Then I noticed that TestGeoPointQuery's test never tests on large distances, 
> so I modified the test to sometimes do so (like TestBKDTree) and hit test 
> failures.



--
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

Couple of AngularJS issues in Solr 5.3

[Alexandre Rafalovitch]

I've hit a couple of issues in the new UI for Solr 5.3.

I have posted them to SOLR-7666, not realizing that it was a closed ticket.

Not sure what the next step is. Should I repost them to a better JIRA,
create individual Jira for each (and link to ???) or something else.

The issues I saw were:
*) Query screen form is not populated when clicking from the "Load
Terms" section
*) Logging screen does not stop calling "more logs" URL even when user
goes to different part of UI
*) Document screen submit button seems to be not wired it for several
types of submission.

Regards,
   Alex.

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

Re: Please vote for the 2nd release candidate for Lucene/Solr 5.3.1

[Anshum Gupta]

Hi Noble,

Sorry for spoiling the party at the last moment, but I think SOLR-8058
 is a good candidate for a
re-spin. I have a patch ready, need some time to add tests for it though.
Thoughts?

On Sat, Sep 12, 2015 at 11:59 PM, Noble Paul  wrote:

> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.1-RC2-rev1702683/
>
> You can run the smoke tester directly with this command:
> python3 -u dev-tools/scripts/smokeTestRelease.py
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.1-RC2-rev1702683/
>
>
> +1
>
>
> SUCCESS! [0:55:00.971757]
>
> --
> -
> Noble Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Anshum Gupta

[jira] [Commented] (SOLR-7925) Implement indexing from gzip format file

[Chris Eldredge (JIRA)]

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

Chris Eldredge commented on SOLR-7925:
--

Sounds potentially very useful when posting large amount of data to Solr.

> Implement indexing from gzip format file
> 
>
> Key: SOLR-7925
> URL: https://issues.apache.org/jira/browse/SOLR-7925
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 5.2.1
>Reporter: Song　Hyonwoo
>Priority: Minor
>  Labels: patch
> Attachments: SOLR-7925.patch
>
>
> This will support the update of gzipped format file of Json, Xml and CSV.
> The request path will use "update/compress/gzip" instead of "update" with 
> "update.contentType" parameter  and  "Content-Type: application/gzip" as 
> Header field.
> The following is sample request using curl command. (use not --data but 
> --data-binary)
> curl 
> "http://localhost:8080/solr/collection1/update/compress/gzip?update.contentType=application/json=true;
>  -H 'Content-Type: application/gzip' --data-binary @data.json.gz
> To activate this function need to add following request handler information 
> to solrconfig.xml
>class="org.apache.solr.handler.CompressedUpdateRequestHandler">
> 
>   application/gzip
> 
>   



--
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-8052) Kerberos auth plugin does not work with Java 9 Jigsaw

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8052:


Hi [~thetaphi], I don't see how this is really related to Kerberos auth plugin. 
Was that a mistake ?

> Kerberos auth plugin does not work with Java 9 Jigsaw
> -
>
> Key: SOLR-8052
> URL: https://issues.apache.org/jira/browse/SOLR-8052
> Project: Solr
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: 5.3
>Reporter: Uwe Schindler
>
> As described in my status update yesterday, there are some problems in 
> dependencies shipped with Solr that don't work with Java 9 Jigsaw builds.
> org.apache.solr.cloud.SaslZkACLProviderTest.testSaslZkACLProvider
> {noformat}
>[junit4]> Throwable #1: java.lang.RuntimeException: 
> java.lang.IllegalAccessException: Class org.apache.hadoop.minikdc.MiniKdc can 
> not access a member of class sun.security.krb5.Config (module 
> java.security.jgss) with modifiers "public static", module java.security.jgss 
> does not export sun.security.krb5 to 
>[junit4]>at 
> org.apache.solr.cloud.SaslZkACLProviderTest$SaslZkTestServer.run(SaslZkACLProviderTest.java:211)
>[junit4]>at 
> org.apache.solr.cloud.SaslZkACLProviderTest.setUp(SaslZkACLProviderTest.java:81)
>[junit4]>at java.lang.Thread.run(java.base@9.0/Thread.java:746)
>[junit4]> Caused by: java.lang.IllegalAccessException: Class 
> org.apache.hadoop.minikdc.MiniKdc can not access a member of class 
> sun.security.krb5.Config (module java.security.jgss) with modifiers "public 
> static", module java.security.jgss does not export sun.security.krb5 to 
> 
>[junit4]>at 
> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(java.base@9.0/AccessibleObject.java:384)
>[junit4]>at 
> java.lang.reflect.AccessibleObject.checkAccess(java.base@9.0/AccessibleObject.java:376)
>[junit4]>at 
> org.apache.hadoop.minikdc.MiniKdc.initKDCServer(MiniKdc.java:478)
>[junit4]>at 
> org.apache.hadoop.minikdc.MiniKdc.start(MiniKdc.java:320)
>[junit4]>at 
> org.apache.solr.cloud.SaslZkACLProviderTest$SaslZkTestServer.run(SaslZkACLProviderTest.java:204)
>[junit4]>... 38 moreThrowable #2: 
> java.lang.NullPointerException
>[junit4]>at 
> org.apache.solr.cloud.ZkTestServer$ZKServerMain.shutdown(ZkTestServer.java:334)
>[junit4]>at 
> org.apache.solr.cloud.ZkTestServer.shutdown(ZkTestServer.java:526)
>[junit4]>at 
> org.apache.solr.cloud.SaslZkACLProviderTest$SaslZkTestServer.shutdown(SaslZkACLProviderTest.java:218)
>[junit4]>at 
> org.apache.solr.cloud.SaslZkACLProviderTest.tearDown(SaslZkACLProviderTest.java:116)
>[junit4]>at java.lang.Thread.run(java.base@9.0/Thread.java:746)
> {noformat}
> This is really bad, bad, bad! All security related stuff should never ever be 
> reflected on!
> So we have to open issue in MiniKdc project so they remove the "hacks". 
> Elasticsearch had
> similar problems with Amazon's AWS API. The worked around with a funny hack 
> in their SecurityPolicy
> (https://github.com/elastic/elasticsearch/pull/13538). But as Solr does not 
> run with SecurityManager
> in production, there is no way to do that. 
> We should report issue on the MiniKdc project, so they fix their code and 
> remove the really bad reflection on Java's internal classes.
> FYI, my 
> [conclusion|http://mail-archives.apache.org/mod_mbox/lucene-dev/201509.mbox/%3C014801d0ee23%245c8f5df0%2415ae19d0%24%40thetaphi.de%3E]
>  from yesterday.



--
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-6305) BooleanQuery.equals should ignore clause order

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-6305:
--

bq. If you have a system that always generates queries the same way (and there 
are quite a few of those who use lucene/solr), then the extra work is unwanted 
overhead. And in some cases, the overhead could be significant (very very large 
queries... i've seen examples).

+1

bq. One trade-off I would be ok with would be to make the multiset lazily 
computed so that it does not get computed unless you call equals/hashcode. ... 
the best option in that case might be to build a custom query.

Why (in the latest patch) is the multiset (and multiset comparison in .equals) 
part of BooleanQuery at all?

I wasn't following the interconnection between all of these issues very 
closely, but i thought Adrien mentioned at one point that one of the 
motivations/ benefits of the FooQuery.Builder APIs (and making the queries 
immutable) was that it would allow us to simplify (and make more efficient) 
some of the methods like .equals and .hashCode by moving the expensive logic 
(ie: deterministically ordering the clauses) into the Builder.build() methods 
so that the queries themselves wouldn't have to carry around the extra data 
structures or do any particularly complex logic in .equals()

wouldn't that be the best of both worlds?  only do the expensive comparisons / 
deterministic ordering of the BooleanClauses once in BooleanQuery.build(), and 
for "expert" cases where you are programatically creating adding clauses in a 
known deterministic order anyway, you can write you're own custom 
BooleanQuery.Builder (sub)class?

> BooleanQuery.equals should ignore clause order
> --
>
> Key: LUCENE-6305
> URL: https://issues.apache.org/jira/browse/LUCENE-6305
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6305.patch, LUCENE-6305.patch
>
>
> BooleanQuery.equals is sensitive to the order in which clauses have been 
> added. So for instance "+A +B" would be considered different from "+B +A" 
> although it generates the same matches and scores.



--
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-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7666:
-

*Query screen*
- *indent* check seems to be miswired. Shows unchecked on load, despite flag 
actually being on. Trying to check/uncheck it removes the flag from the query 
whatever the check mark shows. Probably related to the comment above (check=on 
vs. check=true)
- debugQuery check also does not seem to affect the actual query

> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



--
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-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7666:
-

*Core Admin* screen 
- is missing *Optimize* button.
- *deletedDocs* shows 0, where present UI shows - (dash)


> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



--
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] [Reopened] (SOLR-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Upayavira (JIRA)]

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

Upayavira reopened SOLR-7666:
-

Additional minor bugs found, re-opening

> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



--
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-8058) Collections that start with css*, js*, img*, and tpl* can't be accessed as they match the exclusion filter

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8058:
---
Attachment: SOLR-8058.patch

Here's the fix. Strangely, the test passes even without the patch, so I'm 
certainly missing something from the test framework somewhere.

The test is fairly straight, it creates a collection called "css33", adds a 
document to it and tries to query and assert on numFound.

> Collections that start with css*, js*, img*, and tpl* can't be accessed as 
> they match the exclusion filter
> --
>
> Key: SOLR-8058
> URL: https://issues.apache.org/jira/browse/SOLR-8058
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Attachments: SOLR-8058.patch
>
>
> Collections that match css*, js*, img*, and tpl* can't be reached as the SDF 
> short circuits paths that match those regular expressions.
> It should have only short circuited exact matches for those directories i.e.
> \css/*,/js/*,/img/*,/tpl/* but that doesn't seem to be the case.
> Need to fix this regular expression so that the collection can be reached.



--
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-8034) If minRF is not satisfied, leader should not put replicas in recovery

[ASF subversion and git services (JIRA)]

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

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

Commit 1703289 from [~anshumg] in branch 'dev/trunk'
[ https://svn.apache.org/r1703289 ]

SOLR-8034: Leader no longer puts replicas in recovery in case of a failed 
update, when minRF isn't achieved.

> If minRF is not satisfied, leader should not put replicas in recovery
> -
>
> Key: SOLR-8034
> URL: https://issues.apache.org/jira/browse/SOLR-8034
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>Assignee: Anshum Gupta
>  Labels: solrcloud
> Attachments: SOLR-8034.patch, SOLR-8034.patch
>
>
> If the minimum replication factor parameter (minRf) in a solr update request 
> is not satisfied -- i.e. if the update was not successfully applied on at 
> least n replicas where n >= minRf -- the shard leader should not put the 
> failed replicas in "leader initiated recovery" and the client should retry 
> the update instead.
> This is so that in the scenario were minRf is not satisfied, the failed 
> replicas can still be eligible to become a leader in case of leader failure, 
> since in the client's perspective this update did not succeed.
> This came up from a network partition scenario where the leader becomes 
> sectioned off from its two followers, but they all could still talk to 
> zookeeper. The partitioned leader set its two followers as in leader 
> initiated recovery, so we couldn't just kill off the partitioned node and 
> have a follower take over leadership. For a minRf=1 case, this is the correct 
> behavior because the partitioned leader would have accepted updates that the 
> followers don't have, and therefore we can't switch leadership or we'd lose 
> those updates. However, in the case of minRf=2, solr never accepted any 
> update in the client's point of view, so in fact the partitioned leader 
> doesn't have any accepted update that the followers don't have, and therefore 
> the followers should be eligible to become leaders. Thus, I'm proposing 
> modifying the leader initiated recovery logic to not put the followers in 
> recovery if the minRf parameter is present and is not satisfied.



--
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-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7666:
-

*Schema Browser* screen: dropdown list is not sorted.

> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



--
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-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7666:
-

*Query screen*: Default query is different both in reality and in 
copy-able/display version:
- current UI
-- (displayed) 
http://localhost:8983/solr/techproducts/select?q=*%3A*=json=true
-- (real) 
http://localhost:8983/solr/techproducts/select?q=*%3A*=json=true&_=1442349762965
- Angular UI
-- (displayed) 
http://localhost:8983/solr/techproducts/select?/solr/techproducts/select?wt=json=*:*=on
-- (real) 
http://localhost:8983/solr/techproducts%2Fselect?doNotIntercept=true=on=*:*=json

Differences in Angular (Chrome Network monitor for "real" part):
- indent=*on* (instead of *true*)
- display URL duplicates the URI components
- real URL uses *doNotIntercept=true* instead of timestamp
- real URL has escape for the last slash in the URL component but not in query 
value

> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



--
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-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch edited comment on SOLR-7666 at 9/15/15 8:56 PM:
--

*Query screen*
- *indent* check seems to be miswired. Shows unchecked on load, despite flag 
actually being on. Trying to check/uncheck it removes the flag from the query 
whatever the check mark shows. Probably related to the comment above (check=on 
vs. check=true)
- debugQuery check also does not seem to affect the actual query
- facet check also thinks it is *on* vs. *true* in current UI


was (Author: arafalov):
*Query screen*
- *indent* check seems to be miswired. Shows unchecked on load, despite flag 
actually being on. Trying to check/uncheck it removes the flag from the query 
whatever the check mark shows. Probably related to the comment above (check=on 
vs. check=true)
- debugQuery check also does not seem to affect the actual query

> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



--
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-8058) Collections that start with css*, js*, img*, and tpl* can't be accessed as they match the exclusion filter

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8058:


Working on the changes so that JettyConfig for the tests include the exclusion 
filter.

> Collections that start with css*, js*, img*, and tpl* can't be accessed as 
> they match the exclusion filter
> --
>
> Key: SOLR-8058
> URL: https://issues.apache.org/jira/browse/SOLR-8058
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Attachments: SOLR-8058.patch
>
>
> Collections that match css*, js*, img*, and tpl* can't be reached as the SDF 
> short circuits paths that match those regular expressions.
> It should have only short circuited exact matches for those directories i.e.
> \css/*,/js/*,/img/*,/tpl/* but that doesn't seem to be the case.
> Need to fix this regular expression so that the collection can be reached.



--
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: Please vote for the 2nd release candidate for Lucene/Solr 5.3.1

[Timothy Potter]

+1

Java 7 only - SUCCESS! [0:52:50.796135]

On Mon, Sep 14, 2015 at 12:55 AM, Shalin Shekhar Mangar
 wrote:
> +1
>
> SUCCESS! [3:09:03.352112]
>
> On Sun, Sep 13, 2015 at 12:29 PM, Noble Paul  wrote:
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.1-RC2-rev1702683/
>>
>> You can run the smoke tester directly with this command:
>> python3 -u dev-tools/scripts/smokeTestRelease.py
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.1-RC2-rev1702683/
>>
>>
>> +1
>>
>>
>> SUCCESS! [0:55:00.971757]
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Created] (LUCENE-6806) FunctionQuery.AllScorer.explain overwrites FunctionWeight.queryNorm in trappy fashion

[Terry Smith (JIRA)]

Terry Smith created LUCENE-6806:
---

 Summary: FunctionQuery.AllScorer.explain overwrites 
FunctionWeight.queryNorm in trappy fashion
 Key: LUCENE-6806
 URL: https://issues.apache.org/jira/browse/LUCENE-6806
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Terry Smith
Priority: Minor


FunctionQuery.AllScorer.explain is:

{code:java}
public Explanation explain(int doc, float queryNorm) throws IOException {
  float sc = qWeight * vals.floatVal(doc);

  return Explanation.match(sc, "FunctionQuery(" + func + "), product of:",
  vals.explain(doc),
  Explanation.match(queryNorm, "boost"),
  Explanation.match(weight.queryNorm = 1f, "queryNorm"));
}
{code}

The following line has a subtle assignment that overwrites weight.queryNorm.

{code:java}
  Explanation.match(weight.queryNorm = 1f, "queryNorm"));
{code}

Because weights aren't reused between search and explain this doesn't break 
anything but it's awfully subtle.

Seeing as queryNorm is ALWAYS 1 here, could we just drop this extra line from 
the explain output and use the following instead?

{code:java}
public Explanation explain(int doc, float queryNorm) throws IOException {
  float sc = qWeight * vals.floatVal(doc);

  return Explanation.match(sc, "FunctionQuery(" + func + "), product of:",
  vals.explain(doc),
  Explanation.match(queryNorm, "boost"));
}
{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-8029) Modernize and standardize Solr APIs

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar commented on SOLR-8029:
-

Right, my point was to see if we can use it beyond just being a doc, and use it 
to format the response. The {{wt}} param will still drive the encoding/decoding 
(i.e. json/xml/hocon whatever..), but instead of all APIs just populating and 
serializing a generic NamedList, it would help to make sure what the APIs 
return conform to the doc we make available. That way, something like Avro for 
example, can use the doc as configuration to encode/decode it's data.

> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: 6.0
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 3 types of requests in the new API 
> * {{/solr2//*}} : Operations on specific collections 
> * {{/solr2/_cluster/*}} : Cluster-wide operations which are not specific to 
> any collections. 
> * {{/solr2/_node/*}} : Operations on the node receiving the request. This is 
> the counter part of the core admin API
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



--
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-6780) GeoPointDistanceQuery doesn't work with a large radius?

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6780:


bq. The slow times were related to recomputing the bbox 

Wait: we only compute this (call {{GeoPointDistanceQuery.computeBBox}}) once 
for the query, on init, right?

> GeoPointDistanceQuery doesn't work with a large radius?
> ---
>
> Key: LUCENE-6780
> URL: https://issues.apache.org/jira/browse/LUCENE-6780
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Attachments: LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch, 
> LUCENE-6780.patch, LUCENE-6780.patch
>
>
> I'm working on LUCENE-6698 but struggling with test failures ...
> Then I noticed that TestGeoPointQuery's test never tests on large distances, 
> so I modified the test to sometimes do so (like TestBKDTree) and hit test 
> failures.



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

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

[jira] [Updated] (LUCENE-6779) Reduce memory allocated by CompressingStoredFieldsWriter to write large strings

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated LUCENE-6779:
--
Attachment: LUCENE-6779.patch

Patch with a TestGrowableByteArrayDataOutput that stresses small and large 
strings.

> Reduce memory allocated by CompressingStoredFieldsWriter to write large 
> strings
> ---
>
> Key: LUCENE-6779
> URL: https://issues.apache.org/jira/browse/LUCENE-6779
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/codecs
>Reporter: Shalin Shekhar Mangar
> Attachments: LUCENE-6779.patch, LUCENE-6779.patch, LUCENE-6779.patch, 
> LUCENE-6779.patch, LUCENE-6779_alt.patch
>
>
> In SOLR-7927, I am trying to reduce the memory required to index very large 
> documents (between 10 to 100MB) and one of the places which allocate a lot of 
> heap is the UTF8 encoding in CompressingStoredFieldsWriter. The same problem 
> existed in JavaBinCodec and we reduced its memory allocation by falling back 
> to a double pass approach in SOLR-7971 when the utf8 size of the string is 
> greater than 64KB.
> I propose to make the same changes to CompressingStoredFieldsWriter as we 
> made to JavaBinCodec in SOLR-7971.



--
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-6779) Reduce memory allocated by CompressingStoredFieldsWriter to write large strings

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6779:
-

+1, thanks for adding those tests.

> Reduce memory allocated by CompressingStoredFieldsWriter to write large 
> strings
> ---
>
> Key: LUCENE-6779
> URL: https://issues.apache.org/jira/browse/LUCENE-6779
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/codecs
>Reporter: Shalin Shekhar Mangar
> Attachments: LUCENE-6779.patch, LUCENE-6779.patch, LUCENE-6779.patch, 
> LUCENE-6779.patch, LUCENE-6779_alt.patch
>
>
> In SOLR-7927, I am trying to reduce the memory required to index very large 
> documents (between 10 to 100MB) and one of the places which allocate a lot of 
> heap is the UTF8 encoding in CompressingStoredFieldsWriter. The same problem 
> existed in JavaBinCodec and we reduced its memory allocation by falling back 
> to a double pass approach in SOLR-7971 when the utf8 size of the string is 
> greater than 64KB.
> I propose to make the same changes to CompressingStoredFieldsWriter as we 
> made to JavaBinCodec in SOLR-7971.



--
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-8055) ArrayIndexOutOfBoundsException seen in SOLR on running ToParentBlockJoinQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8055:


I suppose it's caused by deletes in the index. Deletes can be caused by 
duplicating uniqueKey. 

> ArrayIndexOutOfBoundsException seen in SOLR on running ToParentBlockJoinQuery
> -
>
> Key: SOLR-8055
> URL: https://issues.apache.org/jira/browse/SOLR-8055
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0
>Reporter: Shekhar Palta
>
> On running the following query with q=*:* and fq=({!parent which=type:scrap 
> v='visibility:show AND (stock:1)'}) we ran into the following exception :
> java.lang.ArrayIndexOutOfBoundsException: 33554431\n\tat
> org.apache.lucene.util.FixedBitSet.get(FixedBitSet.java:150)\n\tat
> 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.nextDoc(ToParentBlockJoinQuery.java:284)\n\tat
> 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:177)\n\tat
> 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:148)\n\tat
> org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)\n\tat
> 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:592)\n\tat
> 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:284)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1264)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:951)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1109)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1630)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1506)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:586)\n\tat
> 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:511)\n\tat
> 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:227)\n\tat
> 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)\n\tat
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2006)\n\tat
> 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
> 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:413)\n\tat
> 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:204)\n\tat
> 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
> 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
> This used to run perfectly fine before. We increased the memory for SOLR from 
> 3000M to 4096M and ran Optimise again and things seemed to work fine. I want 
> to understand if this can occur again and the steps we need to take to 
> prevent it from  occurring



--
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 # 2729 - Failure!

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:49917/collection1: Service Unavailable
request: 
http://127.0.0.1:49936/collection1/update?update.distrib=FROMLEADER=http%3A%2F%2F127.0.0.1%3A49917%2Fcollection1%2F=javabin=2

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:49917/collection1: Service Unavailable



request: 
http://127.0.0.1:49936/collection1/update?update.distrib=FROMLEADER=http%3A%2F%2F127.0.0.1%3A49917%2Fcollection1%2F=javabin=2
at 
__randomizedtesting.SeedInfo.seed([55FA867C44767BC4:DDAEB9A6EA8A163C]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:632)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:981)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:167)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.indexDoc(AbstractFullDistribZkTestBase.java:770)
at 
org.apache.solr.cloud.DistribCursorPagingTest.doRandomSortsOnLargeIndex(DistribCursorPagingTest.java:537)
at 
org.apache.solr.cloud.DistribCursorPagingTest.test(DistribCursorPagingTest.java:93)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:39)
at 

[jira] [Commented] (SOLR-8055) ArrayIndexOutOfBoundsException seen in SOLR on running ToParentBlockJoinQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8055:


right. you have to delete whole block always. 

> ArrayIndexOutOfBoundsException seen in SOLR on running ToParentBlockJoinQuery
> -
>
> Key: SOLR-8055
> URL: https://issues.apache.org/jira/browse/SOLR-8055
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0
>Reporter: Shekhar Palta
>
> On running the following query with q=*:* and fq=({!parent which=type:scrap 
> v='visibility:show AND (stock:1)'}) we ran into the following exception :
> java.lang.ArrayIndexOutOfBoundsException: 33554431\n\tat
> org.apache.lucene.util.FixedBitSet.get(FixedBitSet.java:150)\n\tat
> 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.nextDoc(ToParentBlockJoinQuery.java:284)\n\tat
> 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:177)\n\tat
> 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:148)\n\tat
> org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)\n\tat
> 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:592)\n\tat
> 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:284)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1264)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:951)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1109)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1630)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1506)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:586)\n\tat
> 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:511)\n\tat
> 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:227)\n\tat
> 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)\n\tat
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2006)\n\tat
> 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
> 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:413)\n\tat
> 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:204)\n\tat
> 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
> 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
> This used to run perfectly fine before. We increased the memory for SOLR from 
> 3000M to 4096M and ran Optimise again and things seemed to work fine. I want 
> to understand if this can occur again and the steps we need to take to 
> prevent it from  occurring



--
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-8029) Modernize and standardize Solr APIs

[Steve Molloy (JIRA)]

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

Steve Molloy commented on SOLR-8029:


bq. The wt param will still drive the encoding/decoding

Is there any plans for supporting HTTP Accept header at some point for setting 
response type?

> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: 6.0
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 3 types of requests in the new API 
> * {{/solr2//*}} : Operations on specific collections 
> * {{/solr2/_cluster/*}} : Cluster-wide operations which are not specific to 
> any collections. 
> * {{/solr2/_node/*}} : Operations on the node receiving the request. This is 
> the counter part of the core admin API
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



--
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-8055) ArrayIndexOutOfBoundsException seen in SOLR on running ToParentBlockJoinQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-8055 at 9/15/15 12:34 PM:
--

-could you please check that queries are orthogonal:-
-q=\*:\*=visibility:show AND (stock:1)=type:scrap ?-

Do you have deletes in the index?


was (Author: mkhludnev):
-could you please check that queries are orthogonal:
q=\*:\*=visibility:show AND (stock:1)=type:scrap ?-

Do you have deletes in the index?

> ArrayIndexOutOfBoundsException seen in SOLR on running ToParentBlockJoinQuery
> -
>
> Key: SOLR-8055
> URL: https://issues.apache.org/jira/browse/SOLR-8055
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0
>Reporter: Shekhar Palta
>
> On running the following query with q=*:* and fq=({!parent which=type:scrap 
> v='visibility:show AND (stock:1)'}) we ran into the following exception :
> java.lang.ArrayIndexOutOfBoundsException: 33554431\n\tat
> org.apache.lucene.util.FixedBitSet.get(FixedBitSet.java:150)\n\tat
> 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.nextDoc(ToParentBlockJoinQuery.java:284)\n\tat
> 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:177)\n\tat
> 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:148)\n\tat
> org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)\n\tat
> 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:592)\n\tat
> 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:284)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1264)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:951)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1109)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1630)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1506)\n\tat
> 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:586)\n\tat
> 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:511)\n\tat
> 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:227)\n\tat
> 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)\n\tat
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2006)\n\tat
> 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
> 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:413)\n\tat
> 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:204)\n\tat
> 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
> 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
> This used to run perfectly fine before. We increased the memory for SOLR from 
> 3000M to 4096M and ran Optimise again and things seemed to work fine. I want 
> to understand if this can occur again and the steps we need to take to 
> prevent it from  occurring



--
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