[jira] [Commented] (LUCENE-3759) Support joining in a distributed environment.

[Scott Blum (JIRA)]

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

Scott Blum commented on LUCENE-3759:


Ping?  Anyone still care or know anything about this issue?

> Support joining in a distributed environment.
> -
>
> Key: LUCENE-3759
> URL: https://issues.apache.org/jira/browse/LUCENE-3759
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/join
>Reporter: Martijn van Groningen
>
> Add two more methods in JoinUtil to support joining in a distributed manner.
> * Method to retrieve all from values.
> * Method to create a TermsQuery based on a set of from terms.
> With these two methods distributed joining can be supported following these 
> steps:
> # Retrieve from values from each shard
> # Merge the retrieved from values. 
> # Create a TermsQuery based on the merged from terms and send this query to 
> all shards. 



--
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-3759) Support joining in a distributed environment.

[Jerry Russell (JIRA)]

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

Jerry Russell commented on LUCENE-3759:
---

I am still waiting for it - but only if it can perform reasonably well..:)

> Support joining in a distributed environment.
> -
>
> Key: LUCENE-3759
> URL: https://issues.apache.org/jira/browse/LUCENE-3759
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/join
>Reporter: Martijn van Groningen
>
> Add two more methods in JoinUtil to support joining in a distributed manner.
> * Method to retrieve all from values.
> * Method to create a TermsQuery based on a set of from terms.
> With these two methods distributed joining can be supported following these 
> steps:
> # Retrieve from values from each shard
> # Merge the retrieved from values. 
> # Create a TermsQuery based on the merged from terms and send this query to 
> all shards. 



--
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-8038) Add SQL aggregate support without GROUP BY clause

[Joel Bernstein (JIRA)]

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

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

New patch testing aggregates without GROUP BY that contain a WHERE clause and 
zero hit StatStream output.

> Add SQL aggregate support without GROUP BY clause
> -
>
> Key: SOLR-8038
> URL: https://issues.apache.org/jira/browse/SOLR-8038
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-8038.patch, SOLR-8038.patch, SOLR-8038.patch
>
>
> Currently the SQL interface only supports aggregate functions when a GROUP BY 
> clause is present. This ticket will add the capability to query for 
> aggregates without a GROUP BY clause.
> Example:
> select max(a), sum(b), min(c) from table1.
> The underlying implementation will be a *StatsStream* class which outputs the 
> results from a *StatsComponent* query as a single Tuple.



--
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-8062) Solr should raise an exception if minRf is specified and not achieved for an update request

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8062:


I agree with this. Specially, considering that now LIR doesn't kick in if the 
minRF isn't  achieved, this makes all the more sense.


> Solr should raise an exception if minRf is specified and not achieved for an 
> update request
> ---
>
> Key: SOLR-8062
> URL: https://issues.apache.org/jira/browse/SOLR-8062
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Timothy Potter
>
> See discussion in SOLR-8034



--
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-4646) lowercaseOperators is enabled by default for edismax query parser

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-4646:


The comment from [~dsmiley] talks about implementation.  My opinion below is 
about the default setting.

I think the default should be false.  There are plenty of situations where the 
word that gets turned into an operator is better suited as part of the query.  
For example, "q=peaches and cream" is an example where "and" as a term can be 
extremely important to obtaining relevant results.  Depending on the content in 
the index, it can be a very different query than "q=peaches AND cream".  With 
the current default, you can only achieve the latter query, unless you do 
tricks like stick an escape in the operator:

{code}
q=peaches an\d cream
{code}

Lowercase operators is a feature that many people want, so it's a good thing 
that we have this setting.  In my opinion, enabling it by default is the wrong 
thing to do.

> lowercaseOperators is enabled by default for edismax query parser
> -
>
> Key: SOLR-4646
> URL: https://issues.apache.org/jira/browse/SOLR-4646
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Affects Versions: 4.1, 4.2
>Reporter: Alexander Koval
>Priority: Trivial
>
> [Documentation|http://wiki.apache.org/solr/ExtendedDisMax#lowercaseOperators] 
> says:
> *lowercaseOperators*
> This param controls whether to try to interpret lowercase words as boolean 
> operators such as "and", "not" and "or". Set {{=true}} to 
> allow this. Default is {{"*false*"}}.
> But in fact {{lowercaseOperators=true}} by default.
> And if one of boolean operators in lowercase is present in query it turns off 
> {{mm}} parameter:
> * {{q=Young+6+or+Ariston=edismax=name=100%25=true}}
>   {{"parsedquery_toString": "+((name:young) (name:6) (name:ariston))"}}
> * 
> {{q=Young+6+or+Ariston=edismax=name=100%25=false=true}}
>   {{"parsedquery_toString": "+(((name:young) (name:6) (name:ariston))~3)"}}



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

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

[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 801 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/801/

7 tests failed.
REGRESSION:  org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest

Error Message:
Captured an uncaught exception in thread: Thread[id=18777, 
name=RecoveryThread-source_collection_shard1_replica2, state=RUNNABLE, 
group=TGRP-CdcrReplicationHandlerTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=18777, 
name=RecoveryThread-source_collection_shard1_replica2, state=RUNNABLE, 
group=TGRP-CdcrReplicationHandlerTest]
Caused by: org.apache.solr.common.cloud.ZooKeeperException: 
at __randomizedtesting.SeedInfo.seed([AD79661DF28559C5]:0)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:234)
Caused by: org.apache.solr.common.SolrException: java.io.FileNotFoundException: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_AD79661DF28559C5-001/jetty-002/cores/source_collection_shard1_replica2/data/tlog/tlog.008.1513034951642054656
 (No such file or directory)
at 
org.apache.solr.update.CdcrTransactionLog.reopenOutputStream(CdcrTransactionLog.java:244)
at 
org.apache.solr.update.CdcrTransactionLog.incref(CdcrTransactionLog.java:173)
at 
org.apache.solr.update.UpdateLog.getRecentUpdates(UpdateLog.java:1079)
at 
org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1579)
at 
org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1610)
at org.apache.solr.core.SolrCore.seedVersionBuckets(SolrCore.java:877)
at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:526)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:227)
Caused by: java.io.FileNotFoundException: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_AD79661DF28559C5-001/jetty-002/cores/source_collection_shard1_replica2/data/tlog/tlog.008.1513034951642054656
 (No such file or directory)
at java.io.RandomAccessFile.open0(Native Method)
at java.io.RandomAccessFile.open(RandomAccessFile.java:316)
at java.io.RandomAccessFile.(RandomAccessFile.java:243)
at 
org.apache.solr.update.CdcrTransactionLog.reopenOutputStream(CdcrTransactionLog.java:236)
... 7 more


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

Error Message:
544 threads leaked from SUITE scope at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest: 1) Thread[id=15756, 
name=qtp303629789-15756, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
 at 
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
 at com.sun.jmx.mbeanserver.Repository.retrieve(Repository.java:487)
 at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1088)
 at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643)
 at 
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
 at 
javax.management.AttributeValueExp.getAttribute(AttributeValueExp.java:163) 
at javax.management.AttributeValueExp.apply(AttributeValueExp.java:105) 
at javax.management.BinaryRelQueryExp.apply(BinaryRelQueryExp.java:109) 
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.filterListOfObjectInstances(DefaultMBeanServerInterceptor.java:1626)
 at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.queryNames(DefaultMBeanServerInterceptor.java:546)
 at 
com.sun.jmx.mbeanserver.JmxMBeanServer.queryNames(JmxMBeanServer.java:619)  
   at org.apache.solr.core.JmxMonitoredMap.clear(JmxMonitoredMap.java:144)  
   at org.apache.solr.core.SolrCore.close(SolrCore.java:1257) at 
org.apache.solr.core.CoreContainer.unload(CoreContainer.java:908) at 
org.apache.solr.handler.admin.CoreAdminHandler.handleUnloadAction(CoreAdminHandler.java:713)
 at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:222)
 at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:192)
 

[jira] [Commented] (SOLR-7858) Make Angular UI default

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-7858:
--

bq.I am unsure who the "we" is you are referring to.

"we" means Solr project. If a feature is built and committed, it is a part of 
the project. 

bq.As I understand it, you and one other have had a private discussion and on 
the basis of that some public discussion has occurred, without a conclusion as 
yet.

Aren't all features built like that? . one developer coming up with a 
suggestion and then the interested developers would comment/vote on the idea. 

bq.That doesn't, to me, constitute a community wide agreement that the URL 
structure will be changing according to your proposal, does it?

The proposal was for v2 APIs . The idea is to have fewer top level names that 
could conflict with collection names. 

What do you mean when you say community wide agreement? I don't think any 
feature gets all people to vote for it. 

bq.Your suggestion is not that different to what I have already proposed - that 
everything (css/etc too) live under /admin, along with the admin APIs. 

Yes, we are not suggesting very different things. The reason I prepended an 
underscore is to avoid conflicts with real collection names. In that aspect 
{{/_admin/}} is better than {{admin}} .





> Make Angular UI default
> ---
>
> Key: SOLR-7858
> URL: https://issues.apache.org/jira/browse/SOLR-7858
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Reporter: Upayavira
>Assignee: Upayavira
>Priority: Minor
> Attachments: SOLR-7858.patch, new ui link.png, original UI link.png
>
>
> Angular UI is very close to feature complete. Once SOLR-7856 is dealt with, 
> it should function well in most cases. I propose that, as soon as 5.3 has 
> been released, we make the Angular UI default, ready for the 5.4 release. We 
> can then fix any more bugs as they are found, but more importantly start 
> working on the features that were the reason for doing this work in the first 
> place.



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandlerBackup.doTestBackup

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([8456D8B921705415:C5DDF8DC06CEA75A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.handler.TestReplicationHandlerBackup.doTestBackup(TestReplicationHandlerBackup.java:241)
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)


FAILED:  org.apache.solr.search.stats.TestDistribIDF.testSimpleQuery

Error Message:
Error from server at 

[jira] [Commented] (LUCENE-6811) AnalyzingInfixSuggester cannot be used in more than one thread

[Varun Thacker (JIRA)]

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

Varun Thacker commented on LUCENE-6811:
---

Hi [~lukhnos] ,

The lookup implementation is thread safe. So you should reuse the suggester 
across threads.

> AnalyzingInfixSuggester cannot be used in more than one thread
> --
>
> Key: LUCENE-6811
> URL: https://issues.apache.org/jira/browse/LUCENE-6811
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Affects Versions: 5.3
>Reporter: Lukhnos Liu
>  Labels: suggester
>
> Currently AnalyzingInfixSuggester always opens an index writer, even if the 
> suggester will be used entirely in read-only mode. I was trying to serve 
> suggestions out of the same index in a multithreaded setup, but I could only 
> create one suggester per index per process because of this design.
> I've created a GitHub project to demonstrate the bug: 
> [https://github.com/lukhnos/lucene-analyzing-infix-suggester-bug]
> To run the demo:
> {code}
> ./gradlew build
> java -jar build/libs/lucene-analyzing-infix-suggester-bug.jar
> {code}
> The exception reads:
> {code}
> Exception in thread "Thread-1" java.lang.RuntimeException: 
> org.apache.lucene.store.LockObtainFailedException: Lock held by this virtual 
> machine: /write.lock
> at 
> org.lukhnos.lucenestudy.AnalyzingInfixSuggesterBug$1SuggestReader.run(AnalyzingInfixSuggesterBug.java:65)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.lucene.store.LockObtainFailedException: Lock held by 
> this virtual machine: /write.lock
> at 
> org.apache.lucene.store.NativeFSLockFactory.obtainFSLock(NativeFSLockFactory.java:127)
> at org.apache.lucene.store.FSLockFactory.obtainLock(FSLockFactory.java:41)
> at org.apache.lucene.store.BaseDirectory.obtainLock(BaseDirectory.java:45)
> at org.apache.lucene.index.IndexWriter.(IndexWriter.java:775)
> at 
> org.apache.lucene.search.suggest.analyzing.AnalyzingInfixSuggester.(AnalyzingInfixSuggester.java:251)
> at 
> org.apache.lucene.search.suggest.analyzing.AnalyzingInfixSuggester.(AnalyzingInfixSuggester.java:163)
> at 
> org.lukhnos.lucenestudy.AnalyzingInfixSuggesterBug$1SuggestReader.run(AnalyzingInfixSuggesterBug.java:51)
> ... 1 more
> {code}
> To work around this problem, I'm currently using my own modified "read only" 
> AnalyzingInfixSuggester, in which I commented out the index writer creation 
> code in the constructor. Then, in the lookup method, I also commented out the 
> part where we get an EarlyTerminatingSortingCollector out of the index 
> writer, so that only a TopFieldCollector is used.
> I was wondering if a read-only mode can be added to AnalyzingInfixSuggester, 
> or at least the contract of getIndexWriterConfig can be changed -- since one 
> will have to subclass to use a different index writer config anyway -- such 
> that if one returns null in getIndexWriterConfig, the suggester will operate 
> in read-only mode, and so no index writer is created. Of course an error will 
> have to be thrown if any build or update methods are called in such mode.



--
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-8069) Ensure that only the valid ZooKeeper registered leader can put a replica into Leader Initiated Recovery.

[Jessica Cheng Mallet (JIRA)]

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

Jessica Cheng Mallet commented on SOLR-8069:


bq. I don't think we really protect against such cases where there is only a 
single leader that can accept an update
This is not the scenario I'm describing. If you have 3 replicas and one that 
was the leader gets partitioned off, one of the other 2 will get elected and 
they can carry on. However, during this transition time, because the cluster 
state update hasn't been completed or propagated through watches, the old 
leader can still get trailing updates from the client. In a normal case where 
the updates are successfully forwarded to all replicas, no one cares. But in 
this case, the old leader cannot forward the update to others (because it's 
partitioned off), so it should not reply success to the client because that 
would be wrong (it is not the leader and it does not have the right to tell the 
others to recover).

> Ensure that only the valid ZooKeeper registered leader can put a replica into 
> Leader Initiated Recovery.
> 
>
> Key: SOLR-8069
> URL: https://issues.apache.org/jira/browse/SOLR-8069
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Critical
> Attachments: SOLR-8069.patch, SOLR-8069.patch
>
>
> I've seen this twice now. Need to work on a test.
> When some issues hit all the replicas at once, you can end up in a situation 
> where the rightful leader was put or put itself into LIR. Even on restart, 
> this rightful leader won't take leadership and you have to manually clear the 
> LIR nodes.
> It seems that if all the replicas participate in election on startup, LIR 
> should just be cleared.



--
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-8080) 'bin/solr start' should print informative errors when the JVM version is insufficient

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8080:
---
Affects Version/s: 5.4

> 'bin/solr start' should print informative errors when the JVM version is 
> insufficient
> -
>
> Key: SOLR-8080
> URL: https://issues.apache.org/jira/browse/SOLR-8080
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.3, Trunk, 5.4
>Reporter: Steve Rowe
>Priority: Minor
>
> From the unpacked 5.3.0 distribution, with Java6 set in {{$JAVA_HOME}} and 
> the {{$PATH}}, there is some indication that there is a problem (Java7 is 
> minimum supported JVM version) - bin/solr times out waiting for Solr to start 
> up - but no info is printed about what the problem might be:
> {noformat}
> $ echo $JAVA_HOME
> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> $ java -version
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
> $ bin/solr start
> Waiting up to 30 seconds to see Solr running on port 8983 [\]  Still not 
> seeing Solr listening on 8983 after 30 seconds!
> tail:~/temp/solr-5.3.0/server/logs/solr.log: No such file or directory
> {noformat}
> On trunk (built via {{ant server}} with Java8), the situation is worse - 
> although Solr started, it's not in a usable state, and there is no indication 
> given that there is a problem:
> {noformat}
> $ java -version
> java version "1.7.0_71"
> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
> $ echo $JAVA_HOME
> /Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home
> sarowe@smb [2048]$ bin/solr start
> Waiting up to 30 seconds to see Solr running on port 8983 [/]  
> Started Solr server on port 8983 (pid=50551). Happy searching!
> {noformat}
> From {{server/logs/solr.log}}:
> {noformat}
> 2015-09-21 17:15:28.991 WARN  (main) [   ] o.e.j.u.c.AbstractLifeCycle FAILED 
> So
> lrRequestFilter: java.lang.UnsupportedClassVersionError: 
> org/apache/solr/servlet
> /SolrDispatchFilter : Unsupported major.minor version 52.0
> java.lang.UnsupportedClassVersionError: 
> org/apache/solr/servlet/SolrDispatchFilt
> er : Unsupported major.minor version 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:14
> 2)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> [...]
> 2015-09-21 17:15:29.020 INFO  (main) [   ] o.e.j.s.ServerConnector Started 
> ServerConnector@24d25ddc{HTTP/1.1}{0.0.0.0:8983}
> 2015-09-21 17:15:29.020 INFO  (main) [   ] o.e.j.s.Server Started @1237ms
> {noformat}



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

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

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

[Apache Jenkins Server]

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

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

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

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=78933, 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:43264: Could not find collection : 
awholynewstresscollection_collection3_0
at __randomizedtesting.SeedInfo.seed([DFADB585E81E4D08]: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)




Build Log:
[...truncated 11403 lines...]
   [junit4] Suite: 
org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/solr/build/solr-core/test/J0/temp/solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest_DFADB585E81E4D08-001/init-core-data-001
   [junit4]   2> 4309811 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false)
   [junit4]   2> 4309812 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   1> Formatting using clusterid: testClusterID
   [junit4]   2> 4309943 WARN  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.a.h.m.i.MetricsConfig Cannot locate configuration: tried 
hadoop-metrics2-namenode.properties,hadoop-metrics2.properties
   [junit4]   2> 4309964 WARN  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.a.h.h.HttpRequestLog Jetty request log can only be enabled using Log4j
   [junit4]   2> 4309967 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.m.log jetty-6.1.26
   [junit4]   2> 4309991 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.m.log Extract 
jar:file:/x1/jenkins/.ivy2/cache/org.apache.hadoop/hadoop-hdfs/tests/hadoop-hdfs-2.6.0-tests.jar!/webapps/hdfs
 to ./temp/Jetty_localhost_58641_hdfs.mcxvom/webapp
   [junit4]   2> 4310129 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.m.log NO JSP Support for /, did not find 
org.apache.jasper.servlet.JspServlet
   [junit4]   2> 4310670 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.m.log Started 
HttpServer2$SelectChannelConnectorWithSafeStartup@localhost:58641
   [junit4]   2> 4310931 WARN  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.a.h.h.HttpRequestLog Jetty request log can only be enabled using Log4j
   [junit4]   2> 4310932 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.m.log jetty-6.1.26
   [junit4]   2> 4310945 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.m.log Extract 
jar:file:/x1/jenkins/.ivy2/cache/org.apache.hadoop/hadoop-hdfs/tests/hadoop-hdfs-2.6.0-tests.jar!/webapps/datanode
 to ./temp/Jetty_localhost_40518_datanodejl87bb/webapp
   [junit4]   2> 4311107 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.m.log NO JSP Support for /, did not find 
org.apache.jasper.servlet.JspServlet
   [junit4]   2> 4311566 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] o.m.log Started 
HttpServer2$SelectChannelConnectorWithSafeStartup@localhost:40518
   [junit4]   2> 4311616 WARN  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[DFADB585E81E4D08]-worker) [
] 

Re: [CI] Lucene 5x Linux 64 Test Only - Build # 64501 - Failure!

[Michael McCandless]

Thanks for digging, Hoss ... I just forwarded the email I had received
via ES's internal list.

Spooky if the email never made it into the dev@lucene.apache.org
moderation queue ...

Mike McCandless

http://blog.mikemccandless.com


On Tue, Sep 22, 2015 at 12:22 PM, Chris Hostetter
 wrote:
>
> Mike: please forward me the entire email (from jenkins) that you recieved
> with all headers.
>
> I don't believe this email ever made it to the dev@lucene moderation queue
> at all (i can't find a record of it at first glace, but because of how the
> moderation queue uses attachments it's a pain to check w/o fully qualified
> date headers and the sender info) ... i suspect the copy you got was just
> because it was sent to some internal @elastic list (not avert being
> moderated on dev@lucene)
>
>
>
> : Date: Tue, 22 Sep 2015 12:01:47 -0400
> : From: Michael McCandless 
> : Reply-To: dev@lucene.apache.org
> : To: Dev Elasticsearch 
> : Cc: "dev@lucene.apache.org" ,
> : "sim...@apache.org" 
> : Subject: Re: [CI] Lucene 5x Linux 64 Test Only - Build # 64501 - Failure!
> :
> : This was a test bug, I committed a fix:
> : https://issues.apache.org/jira/browse/LUCENE-6734
> :
> : But unfortunately it looks like ES Jenkins build failures still require
> : moderation ... I'll dig.
> :
> : Mike McCandless
> :
> : On Fri, Sep 18, 2015 at 3:10 PM,  wrote:
> :
> : > *BUILD FAILURE*
> : > Build URL
> : > http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/64501/
> : > 
> 
> : > Project:lucene_linux_java8_64_test_only Randomization: 
> JDKEA8,network,heap[578m],-server
> : > +UseConcMarkSweepGC -UseCompressedOops +AggressiveOpts,sec manager on Date
> : > of build:Fri, 18 Sep 2015 21:02:55 +0200 Build duration:7 min 29 sec
> : > *CHANGES* No Changes
> : > *BUILD ARTIFACTS*
> : > -
> : > 
> checkout/lucene/build/codecs/test/temp/junit4-J0-20150918_210929_793.events
> : > 
> 
> : > -
> : > 
> checkout/lucene/build/codecs/test/temp/junit4-J1-20150918_210929_793.events
> : > 
> 
> : > -
> : > 
> checkout/lucene/build/codecs/test/temp/junit4-J2-20150918_210929_793.events
> : > 
> 
> : > -
> : > 
> checkout/lucene/build/codecs/test/temp/junit4-J3-20150918_210929_793.events
> : > 
> 
> : > -
> : > 
> checkout/lucene/build/codecs/test/temp/junit4-J4-20150918_210929_794.events
> : > 
> 

[jira] [Commented] (SOLR-4646) lowercaseOperators is enabled by default for edismax query parser

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-4646:


This is an old conversation but I hit this today (from real user queries) and 
thought I'd offer my opinion.  Allowing lowercase operators, _as it's currently 
implemented in edismax_ is trappy.  A user might type "foo bar or baz", and 
based on how edismax is implemented, "foo" will always be 
BooleanClause.Occur.SHOULD  ('mm' is ignored, 'q.op' is ignored).  I'd feel 
better about it if in this mode, the default operator was set to AND.  
Nonetheless I think this feature is trappy; users don't necessarily know this 
syntax and it's implications.

> lowercaseOperators is enabled by default for edismax query parser
> -
>
> Key: SOLR-4646
> URL: https://issues.apache.org/jira/browse/SOLR-4646
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Affects Versions: 4.1, 4.2
>Reporter: Alexander Koval
>Priority: Trivial
>
> [Documentation|http://wiki.apache.org/solr/ExtendedDisMax#lowercaseOperators] 
> says:
> *lowercaseOperators*
> This param controls whether to try to interpret lowercase words as boolean 
> operators such as "and", "not" and "or". Set {{=true}} to 
> allow this. Default is {{"*false*"}}.
> But in fact {{lowercaseOperators=true}} by default.
> And if one of boolean operators in lowercase is present in query it turns off 
> {{mm}} parameter:
> * {{q=Young+6+or+Ariston=edismax=name=100%25=true}}
>   {{"parsedquery_toString": "+((name:young) (name:6) (name:ariston))"}}
> * 
> {{q=Young+6+or+Ariston=edismax=name=100%25=false=true}}
>   {{"parsedquery_toString": "+(((name:young) (name:6) (name:ariston))~3)"}}



--
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-8073) Solr fails to start on Windows with obscure errors when using relative path

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8073:
-

Looks like relative vs. absolute value to **-s** params resolves several 
directories under the server instead of under the current path. This ends up 
picking up different configuration files and probably causing this error:

Here are the differences in the command line (common elements removed).

With relative path:
bq. -Xloggc:"C:\Projects\solr-5.3.1\server\logs"/solr_gc.log 
-Dlog4j.configuration="file:C:\Projects\solr-5.3.1\server\resources\log4j.properties"
 -Dsolr.solr.home="example\techproducts\solr"

With absolute path:
bq. 
-Xloggc:"c:\Projects\solr-5.3.1\example\techproducts\solr\..\logs"/solr_gc.log 
-Dlog4j.configuration="file:C:\Projects\solr-5.3.1\example\resources\log4j.properties"
 -Dsolr.solr.home="c:\Projects\solr-5.3.1\example\techproducts\solr"

The relative path file access tracing shows:
{quote}
"12:01:28.7091929 
PM","java.exe","8816","IRP_MJ_CREATE","C:\Projects\solr-5.3.1\server\example\techproducts\solr\","PATH
 NOT FOUND","Desired Access: Read Data/List Directory, Synchronize, 
Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: 
n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
"12:01:29.6735187 
PM","java.exe","4496","FASTIO_NETWORK_QUERY_OPEN","C:\Projects\solr-5.3.1\server\example\techproducts\solr\lib","FAST
 IO DISALLOWED",""
"12:01:29.6735466 
PM","java.exe","4496","IRP_MJ_CREATE","C:\Projects\solr-5.3.1\server\example\techproducts\solr\lib","PATH
 NOT FOUND","Desired Access: Read Attributes, Disposition: Open, Options: Open 
Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: 
n/a"
"12:01:29.8164747 
PM","java.exe","4496","FASTIO_NETWORK_QUERY_OPEN","C:\Projects\solr-5.3.1\server\example\techproducts\solr\solr.xml","FAST
 IO DISALLOWED",""
"12:01:29.8165034 
PM","java.exe","4496","IRP_MJ_CREATE","C:\Projects\solr-5.3.1\server\example\techproducts\solr\solr.xml","PATH
 NOT FOUND","Desired Access: Read Attributes, Disposition: Open, Options: Open 
Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: 
n/a"
{quote}

Notice, it resolves to under the **server** directory, incorrectly.

> Solr fails to start on Windows with obscure errors when using relative path
> ---
>
> Key: SOLR-8073
> URL: https://issues.apache.org/jira/browse/SOLR-8073
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
> Environment: Windows 7
>Reporter: Alexandre Rafalovitch
>Priority: Critical
>
> Clean 5.3  (and 5.3.1 RC3) on Windows:
> * bin\solr start -e techproducts
> * Visit Admin UI - all works
> * bin\solr stop -all
> * bin\solr start -s example\techproducts\solr
> * ERROR: Solr at http://localhost:8983/solr did not come online within 30 
> seconds!
> * Visit Admin UI - get an error:
> {quote}
> HTTP ERROR 500
> Problem accessing /solr/. Reason:
> Server Error
> Caused by:
> java.lang.NullPointerException
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> 

Re: [CI] Lucene 5x Linux 64 Test Only - Build # 64501 - Failure!

[Steve Rowe]

This email was never delivered to me for moderation either.

In fact, the last MODERATE email I received for email from Elastic’s CI server 
was on Sept. 8th for Build URL 
http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/62794/.

> On Sep 22, 2015, at 12:27 PM, Michael McCandless  
> wrote:
> 
> Thanks for digging, Hoss ... I just forwarded the email I had received
> via ES's internal list.
> 
> Spooky if the email never made it into the dev@lucene.apache.org
> moderation queue ...
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com
> 
> 
> On Tue, Sep 22, 2015 at 12:22 PM, Chris Hostetter
>  wrote:
>> 
>> Mike: please forward me the entire email (from jenkins) that you recieved
>> with all headers.
>> 
>> I don't believe this email ever made it to the dev@lucene moderation queue
>> at all (i can't find a record of it at first glace, but because of how the
>> moderation queue uses attachments it's a pain to check w/o fully qualified
>> date headers and the sender info) ... i suspect the copy you got was just
>> because it was sent to some internal @elastic list (not avert being
>> moderated on dev@lucene)
>> 
>> 
>> 
>> : Date: Tue, 22 Sep 2015 12:01:47 -0400
>> : From: Michael McCandless 
>> : Reply-To: dev@lucene.apache.org
>> : To: Dev Elasticsearch 
>> : Cc: "dev@lucene.apache.org" ,
>> : "sim...@apache.org" 
>> : Subject: Re: [CI] Lucene 5x Linux 64 Test Only - Build # 64501 - Failure!
>> :
>> : This was a test bug, I committed a fix:
>> : https://issues.apache.org/jira/browse/LUCENE-6734
>> :
>> : But unfortunately it looks like ES Jenkins build failures still require
>> : moderation ... I'll dig.
>> :
>> : Mike McCandless
>> :
>> : On Fri, Sep 18, 2015 at 3:10 PM,  wrote:
>> :
>> : > *BUILD FAILURE*
>> : > Build URL
>> : > http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/64501/
>> : > 
>> 
>> : > Project:lucene_linux_java8_64_test_only Randomization: 
>> JDKEA8,network,heap[578m],-server
>> : > +UseConcMarkSweepGC -UseCompressedOops +AggressiveOpts,sec manager on 
>> Date
>> : > of build:Fri, 18 Sep 2015 21:02:55 +0200 Build duration:7 min 29 sec
>> : > *CHANGES* No Changes
>> : > *BUILD ARTIFACTS*
>> : > -
>> : > 
>> checkout/lucene/build/codecs/test/temp/junit4-J0-20150918_210929_793.events
>> : > 
>> 
>> : > -
>> : > 
>> checkout/lucene/build/codecs/test/temp/junit4-J1-20150918_210929_793.events
>> : > 
>> 
>> : > -
>> : > 
>> checkout/lucene/build/codecs/test/temp/junit4-J2-20150918_210929_793.events
>> : > 
>> 
>> : > -
>> : > 
>> checkout/lucene/build/codecs/test/temp/junit4-J3-20150918_210929_793.events
>> : > 
>> 

[jira] [Updated] (SOLR-8085) ChaosMonkey Safe Leader Test fail with shard inconsistency.

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-8085:
---
Attachment: fail.150922_130608

Another one that has a smaller log file.

Throwable #1: java.lang.AssertionError: shard3 is not consistent.  Got 375 from 
http://127.0.0.1:40940/collection1lastClient and got 230 from 
http://127.0.0.1:47239/collection1


> ChaosMonkey Safe Leader Test fail with shard inconsistency.
> ---
>
> Key: SOLR-8085
> URL: https://issues.apache.org/jira/browse/SOLR-8085
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
> Attachments: fail.150922_125320, fail.150922_130608
>
>
> I've been discussing this fail I found with Yonik.
> The problem seems to be that a replica tries to recover and publishes 
> recovering - the attempt then fails, but docs are now coming in from the 
> leader. The replica tries to recover again and has gotten enough docs to pass 
> peery sync.
> I'm trying a possible solution now where we won't allow peer sync after a 
> recovery that is not successful.



--
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: [CI] Lucene 5x Linux 64 Test Only - Build # 64501 - Failure!

[Michael McCandless]

Hmm this is no good :)  We (ES) made a change that we thought would
fix the munged Return-Path, but maybe instead it broke the emails
entirely!  I'll dig on our end ... thanks Steve and Hoss.

Mike McCandless

http://blog.mikemccandless.com


On Tue, Sep 22, 2015 at 12:43 PM, Steve Rowe  wrote:
> This email was never delivered to me for moderation either.
>
> In fact, the last MODERATE email I received for email from Elastic’s CI 
> server was on Sept. 8th for Build URL 
> http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/62794/.
>
>> On Sep 22, 2015, at 12:27 PM, Michael McCandless  
>> wrote:
>>
>> Thanks for digging, Hoss ... I just forwarded the email I had received
>> via ES's internal list.
>>
>> Spooky if the email never made it into the dev@lucene.apache.org
>> moderation queue ...
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Tue, Sep 22, 2015 at 12:22 PM, Chris Hostetter
>>  wrote:
>>>
>>> Mike: please forward me the entire email (from jenkins) that you recieved
>>> with all headers.
>>>
>>> I don't believe this email ever made it to the dev@lucene moderation queue
>>> at all (i can't find a record of it at first glace, but because of how the
>>> moderation queue uses attachments it's a pain to check w/o fully qualified
>>> date headers and the sender info) ... i suspect the copy you got was just
>>> because it was sent to some internal @elastic list (not avert being
>>> moderated on dev@lucene)
>>>
>>>
>>>
>>> : Date: Tue, 22 Sep 2015 12:01:47 -0400
>>> : From: Michael McCandless 
>>> : Reply-To: dev@lucene.apache.org
>>> : To: Dev Elasticsearch 
>>> : Cc: "dev@lucene.apache.org" ,
>>> : "sim...@apache.org" 
>>> : Subject: Re: [CI] Lucene 5x Linux 64 Test Only - Build # 64501 - Failure!
>>> :
>>> : This was a test bug, I committed a fix:
>>> : https://issues.apache.org/jira/browse/LUCENE-6734
>>> :
>>> : But unfortunately it looks like ES Jenkins build failures still require
>>> : moderation ... I'll dig.
>>> :
>>> : Mike McCandless
>>> :
>>> : On Fri, Sep 18, 2015 at 3:10 PM,  wrote:
>>> :
>>> : > *BUILD FAILURE*
>>> : > Build URL
>>> : > http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/64501/
>>> : > 
>>> 
>>> : > Project:lucene_linux_java8_64_test_only Randomization: 
>>> JDKEA8,network,heap[578m],-server
>>> : > +UseConcMarkSweepGC -UseCompressedOops +AggressiveOpts,sec manager on 
>>> Date
>>> : > of build:Fri, 18 Sep 2015 21:02:55 +0200 Build duration:7 min 29 sec
>>> : > *CHANGES* No Changes
>>> : > *BUILD ARTIFACTS*
>>> : > -
>>> : > 
>>> checkout/lucene/build/codecs/test/temp/junit4-J0-20150918_210929_793.events
>>> : > 
>>> 
>>> : > -
>>> : > 
>>> checkout/lucene/build/codecs/test/temp/junit4-J1-20150918_210929_793.events
>>> : > 
>>> 
>>> : > -
>>> : > 
>>> checkout/lucene/build/codecs/test/temp/junit4-J2-20150918_210929_793.events
>>> : > 
>>> 

[jira] [Updated] (SOLR-8085) ChaosMonkey Safe Leader Test fail with shard inconsistency.

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-8085:
---
Attachment: fail.150922_125320

Here's a fail from HdfsChaosMonkeySafeLeaderTest on trunk (with some minor 
patches provided by Mark).

Throwable #1: java.lang.AssertionError: shard3 is not consistent.  Got 658 from 
http://127.0.0.1:44649/collection1lastClient and got 330 from 
http://127.0.0.1:38249/collection1


> ChaosMonkey Safe Leader Test fail with shard inconsistency.
> ---
>
> Key: SOLR-8085
> URL: https://issues.apache.org/jira/browse/SOLR-8085
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
> Attachments: fail.150922_125320
>
>
> I've been discussing this fail I found with Yonik.
> The problem seems to be that a replica tries to recover and publishes 
> recovering - the attempt then fails, but docs are now coming in from the 
> leader. The replica tries to recover again and has gotten enough docs to pass 
> peery sync.
> I'm trying a possible solution now where we won't allow peer sync after a 
> recovery that is not successful.



--
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-7858) Make Angular UI default

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-7858:
--

As we plan to move to V2 API in 6.0 we plan to not restrict a collection name 
other that the well known ones ({{_cluster}}, {{_node}} etc ) . The UI is 
something that could live in a special dir such as {{/solr/_admin/index.html}} 
or {{/solr/_ui/index.html}}. All the other files also must move out of the top 
level . For instance, js , css and images also move under the path 
{{/solr/_admin/}} or {{/solr/_ui/}}

We should make these changes in 5x itself and keep redirect rules for old-> 
new. In 6.0 we should get rid of the rules as well



> Make Angular UI default
> ---
>
> Key: SOLR-7858
> URL: https://issues.apache.org/jira/browse/SOLR-7858
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Reporter: Upayavira
>Assignee: Upayavira
>Priority: Minor
> Attachments: SOLR-7858.patch, new ui link.png, original UI link.png
>
>
> Angular UI is very close to feature complete. Once SOLR-7856 is dealt with, 
> it should function well in most cases. I propose that, as soon as 5.3 has 
> been released, we make the Angular UI default, ready for the 5.4 release. We 
> can then fix any more bugs as they are found, but more importantly start 
> working on the features that were the reason for doing this work in the first 
> place.



--
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-7858) Make Angular UI default

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-7858:
-

@noble.paul I am unsure who the "we" is you are referring to. As I understand 
it, you and one other have had a private discussion and on the basis of that 
some public discussion has occurred, without a conclusion as yet. That doesn't, 
to me, constitute a community wide agreement that the URL structure will be 
changing according to your proposal, does it?

Your suggestion is not that different to what I have already proposed - that 
everything (css/etc too) live under /admin, along with the admin APIs. The only 
URL we need to keep consistent is the /solr/ one, which must redirect somewhere 
sensible, which could be _admin/ or _ui/ or whatever.

> Make Angular UI default
> ---
>
> Key: SOLR-7858
> URL: https://issues.apache.org/jira/browse/SOLR-7858
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Reporter: Upayavira
>Assignee: Upayavira
>Priority: Minor
> Attachments: SOLR-7858.patch, new ui link.png, original UI link.png
>
>
> Angular UI is very close to feature complete. Once SOLR-7856 is dealt with, 
> it should function well in most cases. I propose that, as soon as 5.3 has 
> been released, we make the Angular UI default, ready for the 5.4 release. We 
> can then fix any more bugs as they are found, but more importantly start 
> working on the features that were the reason for doing this work in the first 
> place.



--
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-8038) Add StatsStream to the Streaming API and wire it into the SQLHandler

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8038:
--

I'll do some manual testing using the JDBC driver and if all looks good I'll 
commit to trunk.

> Add StatsStream to the Streaming API and wire it into the SQLHandler
> 
>
> Key: SOLR-8038
> URL: https://issues.apache.org/jira/browse/SOLR-8038
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-8038.patch, SOLR-8038.patch, SOLR-8038.patch, 
> SOLR-8038.patch
>
>
> Currently the SQL interface only supports aggregate functions when a GROUP BY 
> clause is present. This ticket will add the capability to query for 
> aggregates without a GROUP BY clause.
> Example:
> select max(a), sum(b), min(c) from table1.
> The underlying implementation will be a *StatsStream* class which outputs the 
> results from a *StatsComponent* query as a single Tuple.



--
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-8038) Add StatsStream to the Streaming API and wire it into the SQLHandler

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8038:
-
Summary: Add StatsStream to the Streaming API and wire it into the 
SQLHandler  (was: Add SQL aggregate support without GROUP BY clause)

> Add StatsStream to the Streaming API and wire it into the SQLHandler
> 
>
> Key: SOLR-8038
> URL: https://issues.apache.org/jira/browse/SOLR-8038
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-8038.patch, SOLR-8038.patch, SOLR-8038.patch
>
>
> Currently the SQL interface only supports aggregate functions when a GROUP BY 
> clause is present. This ticket will add the capability to query for 
> aggregates without a GROUP BY clause.
> Example:
> select max(a), sum(b), min(c) from table1.
> The underlying implementation will be a *StatsStream* class which outputs the 
> results from a *StatsComponent* query as a single Tuple.



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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.3-Linux/229/
Java: 64bit/jdk1.8.0_60 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.update.HardAutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([27212B94DE965906:9DF344EC5DB8B713]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:765)
at 
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100)
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=//result[@numFound=1]
xml response was: 

00


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




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

[jira] [Assigned] (SOLR-8086) Add support for SELECT DISTINCT queries to the SQL interface

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-8086:


Assignee: Joel Bernstein

> Add support for SELECT DISTINCT queries to the SQL interface
> 
>
> Key: SOLR-8086
> URL: https://issues.apache.org/jira/browse/SOLR-8086
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> This ticket will add the SELECT DISTINCT query to the SQL interface.
> There will be a Map/Reduce implementation using the UniqueStream and an JSON 
> Facet API implementation using the FacetStream. A flag will be added to the 
> FacetStream to only add the distinct terms to the tuples and ignore the facet 
> counts.



--
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-8086) Add support for SELECT DISTINCT queries to the SQL interface

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-8086:


 Summary: Add support for SELECT DISTINCT queries to the SQL 
interface
 Key: SOLR-8086
 URL: https://issues.apache.org/jira/browse/SOLR-8086
 Project: Solr
  Issue Type: New Feature
Reporter: Joel Bernstein


This ticket will add the SELECT DISTINCT query to the SQL interface.

There will be a Map/Reduce implementation using the UniqueStream and an JSON 
Facet API implementation using the FacetStream. A flag will be added to the 
FacetStream to only add the distinct terms to the tuples and ignore the facet 
counts.



--
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] [Closed] (SOLR-7903) Add the FacetStream to the Streaming API and Wire It Into the SQLHandler

[Joel Bernstein (JIRA)]

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

Joel Bernstein closed SOLR-7903.

Resolution: Fixed

> Add the FacetStream to the Streaming API and Wire It Into the SQLHandler
> 
>
> Key: SOLR-7903
> URL: https://issues.apache.org/jira/browse/SOLR-7903
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: Trunk
>
> Attachments: SOLR-7093.patch, SOLR-7093.patch, SOLR-7093.patch, 
> SOLR-7093.patch, SOLR-7903.patch, SOLR-7903.patch, SOLR-7903.patch, 
> SOLR-7903.patch, SOLR-7903.patch
>
>
> This ticket adds the FacetStream class to the Streaming API and wires it into 
> the SQLHandler. The FacetStream will abstract the results from the JSON Facet 
> API as a Stream of Tuples. This will provide an alternative to the 
> RollupStream which uses Map/Reduce for aggregations.
> This ticket will also wire the FacetStream into the SQL interface, allowing 
> users to switch between the RollupStream (Map/Reduce) and the FacetStream 
> (JSON Facet API) as the underlying engine for SQL Group By aggregates.  SQL 
> clients can switch between Facets and Map Reduce with the new 
> *aggregationMode* http param.



--
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-8086) Add support for SELECT DISTINCT queries to the SQL interface

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8086:
-
Description: 
This ticket will add the SELECT DISTINCT query to the SQL interface.

There will be a Map/Reduce implementation using the UniqueStream and a JSON 
Facet API implementation using the FacetStream. A flag will be added to the 
FacetStream to only add the distinct terms to the tuples and ignore the facet 
counts.

SQL clients will be able to switch between Map/Reduce and JSON Facet API using 
the *aggregationMode* [map_reduce or facet] http param introduced in SOLR-7903.


  was:
This ticket will add the SELECT DISTINCT query to the SQL interface.

There will be a Map/Reduce implementation using the UniqueStream and a JSON 
Facet API implementation using the FacetStream. A flag will be added to the 
FacetStream to only add the distinct terms to the tuples and ignore the facet 
counts.


> Add support for SELECT DISTINCT queries to the SQL interface
> 
>
> Key: SOLR-8086
> URL: https://issues.apache.org/jira/browse/SOLR-8086
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> This ticket will add the SELECT DISTINCT query to the SQL interface.
> There will be a Map/Reduce implementation using the UniqueStream and a JSON 
> Facet API implementation using the FacetStream. A flag will be added to the 
> FacetStream to only add the distinct terms to the tuples and ignore the facet 
> counts.
> SQL clients will be able to switch between Map/Reduce and JSON Facet API 
> using the *aggregationMode* [map_reduce or facet] http param introduced in 
> SOLR-7903.



--
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-8069) Ensure that only the valid ZooKeeper registered leader can put a replica into Leader Initiated Recovery.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8069:
---

The defensive checks are just sugar like I said. If we are going to check zk if 
we are still leader it makes sense to check our local reckoning first. 

The meat of the change is the parent version check. If it fails, we don't care. 
The leader has moved on - we don't care about retries. 

> Ensure that only the valid ZooKeeper registered leader can put a replica into 
> Leader Initiated Recovery.
> 
>
> Key: SOLR-8069
> URL: https://issues.apache.org/jira/browse/SOLR-8069
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Critical
> Attachments: SOLR-8069.patch, SOLR-8069.patch
>
>
> I've seen this twice now. Need to work on a test.
> When some issues hit all the replicas at once, you can end up in a situation 
> where the rightful leader was put or put itself into LIR. Even on restart, 
> this rightful leader won't take leadership and you have to manually clear the 
> LIR nodes.
> It seems that if all the replicas participate in election on startup, LIR 
> should just be cleared.



--
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-8086) Add support for SELECT DISTINCT queries to the SQL interface

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8086:
-
Description: 
This ticket will add the SELECT DISTINCT query to the SQL interface.

There will be a Map/Reduce implementation using the UniqueStream and a JSON 
Facet API implementation using the FacetStream. A flag will be added to the 
FacetStream to only add the distinct terms to the tuples and ignore the facet 
counts.

  was:
This ticket will add the SELECT DISTINCT query to the SQL interface.

There will be a Map/Reduce implementation using the UniqueStream and an JSON 
Facet API implementation using the FacetStream. A flag will be added to the 
FacetStream to only add the distinct terms to the tuples and ignore the facet 
counts.


> Add support for SELECT DISTINCT queries to the SQL interface
> 
>
> Key: SOLR-8086
> URL: https://issues.apache.org/jira/browse/SOLR-8086
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> This ticket will add the SELECT DISTINCT query to the SQL interface.
> There will be a Map/Reduce implementation using the UniqueStream and a JSON 
> Facet API implementation using the FacetStream. A flag will be added to the 
> FacetStream to only add the distinct terms to the tuples and ignore the facet 
> counts.



--
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-6810) Upgrade to Spatial4j 0.5

[ASF subversion and git services (JIRA)]

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

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

Commit 1704759 from [~dsmiley] in branch 'dev/trunk'
[ https://svn.apache.org/r1704759 ]

LUCENE-6810: Spatial4j 0.5 upgrade. Mostly fixes a few edge-case bugs.
* the spatial4j tests jar is published and we use some utilities there; this 
adds a test dependency on it & SLF4J.

> Upgrade to Spatial4j 0.5
> 
>
> Key: LUCENE-6810
> URL: https://issues.apache.org/jira/browse/LUCENE-6810
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 5.4
>
> Attachments: LUCENE-6810_Spatial4j_0_5.patch
>
>
> Spatial4j 0.5 was released a few days ago.  There are some bug fixes, most of 
> which were surfaced via the tests here.  It also publishes the test jar 
> (thanks [~nknize] for that one) and with that there are a couple test 
> utilities here I can remove.
> https://github.com/locationtech/spatial4j/blob/master/CHANGES.md



--
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-8085) ChaosMonkey Safe Leader Test fail with shard inconsistency.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8085:
---

bq. I'm trying a possible solution now where we won't allow peer sync after a 
recovery that is not successful.

This seems to work out well. 

Most of these issues show up easier when running the more heavyweight hdfs 
tests though, so I am running those - because we truncate support in hdfs was 
not added until 2.7, when a replication fails, we still replay all the buffered 
docs. A badly timed server restart can then pass incorrectly on peer sync if 
this happens, regardless of my attempted fix that won't cross jetty restarts.

> ChaosMonkey Safe Leader Test fail with shard inconsistency.
> ---
>
> Key: SOLR-8085
> URL: https://issues.apache.org/jira/browse/SOLR-8085
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
> Attachments: fail.150922_125320, fail.150922_130608
>
>
> I've been discussing this fail I found with Yonik.
> The problem seems to be that a replica tries to recover and publishes 
> recovering - the attempt then fails, but docs are now coming in from the 
> leader. The replica tries to recover again and has gotten enough docs to pass 
> peery sync.
> I'm trying a possible solution now where we won't allow peer sync after a 
> recovery that is not successful.



--
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-8038) Add StatsStream to the Streaming API and wire it into the SQLHandler

[Joel Bernstein (JIRA)]

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

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

Patch with pre-commit passing and updated CHANGES.txt

> Add StatsStream to the Streaming API and wire it into the SQLHandler
> 
>
> Key: SOLR-8038
> URL: https://issues.apache.org/jira/browse/SOLR-8038
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-8038.patch, SOLR-8038.patch, SOLR-8038.patch, 
> SOLR-8038.patch
>
>
> Currently the SQL interface only supports aggregate functions when a GROUP BY 
> clause is present. This ticket will add the capability to query for 
> aggregates without a GROUP BY clause.
> Example:
> select max(a), sum(b), min(c) from table1.
> The underlying implementation will be a *StatsStream* class which outputs the 
> results from a *StatsComponent* query as a single Tuple.



--
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-7962) Passing additional arguments to solr.cmd using "-a" does not work on Windows

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-7962:
--

I vote we add a pass thru for {{-X}} like we have for {{-D}} and get rid of 
{{-a}} completely as it won't work with Windows without some heavy lifting. If 
you need additional args that don't start with -D or -X, then use 
{{solr.in.sh|cmd}} to pass them thru.

> Passing additional arguments to solr.cmd using "-a" does not work on Windows
> 
>
> Key: SOLR-7962
> URL: https://issues.apache.org/jira/browse/SOLR-7962
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Dawid Weiss
>




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

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

[jira] [Resolved] (SOLR-5886) Store the response in zk for async calls so that it can be returned by REQUESTSTATUS API

[Anshum Gupta (JIRA)]

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

Anshum Gupta resolved SOLR-5886.

Resolution: Fixed

> Store the response in zk for async calls so that it can be returned by 
> REQUESTSTATUS API
> 
>
> Key: SOLR-5886
> URL: https://issues.apache.org/jira/browse/SOLR-5886
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: Trunk, 5.3
>
> Attachments: SOLR-5886-git.patch, SOLR-5886-git.patch, 
> SOLR-5886.patch, SOLR-5886.patch, SOLR-5986-git.patch
>
>
> As of now, only the state of a pre-submitted tasks is returned in the 
> response  to the REQUESTSTATUS Collections API call. 
> Pass more information, specially in case of a call erroring out.



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

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

[jira] [Resolved] (SOLR-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 resolved SOLR-8034.

Resolution: Fixed

> 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
> Fix For: Trunk, 5.4
>
> 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:
---
Fix Version/s: 5.4
   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
> Fix For: Trunk, 5.4
>
> 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-5886) Store the response in zk for async calls so that it can be returned by REQUESTSTATUS API

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-5886:
---
Fix Version/s: (was: 5.4)
   5.3

> Store the response in zk for async calls so that it can be returned by 
> REQUESTSTATUS API
> 
>
> Key: SOLR-5886
> URL: https://issues.apache.org/jira/browse/SOLR-5886
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-5886-git.patch, SOLR-5886-git.patch, 
> SOLR-5886.patch, SOLR-5886.patch, SOLR-5986-git.patch
>
>
> As of now, only the state of a pre-submitted tasks is returned in the 
> response  to the REQUESTSTATUS Collections API call. 
> Pass more information, specially in case of a call erroring out.



--
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-4646) lowercaseOperators is enabled by default for edismax query parser

[JIRA]

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

Jan Høydahl commented on SOLR-4646:
---

bq. lowercase "and" and "or" were meant to be a natural language improvement
Setting a natural language "improvement" as default when it only works for 
english language content seems odd. For content in any other language, it won't 
work since we use other words for and/or, and instead you may get weird 
behavior. That is a bit too much magic for a default setting, so I still 
support a change to {{false}} as default.

> lowercaseOperators is enabled by default for edismax query parser
> -
>
> Key: SOLR-4646
> URL: https://issues.apache.org/jira/browse/SOLR-4646
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Affects Versions: 4.1, 4.2
>Reporter: Alexander Koval
>Priority: Trivial
>
> [Documentation|http://wiki.apache.org/solr/ExtendedDisMax#lowercaseOperators] 
> says:
> *lowercaseOperators*
> This param controls whether to try to interpret lowercase words as boolean 
> operators such as "and", "not" and "or". Set {{=true}} to 
> allow this. Default is {{"*false*"}}.
> But in fact {{lowercaseOperators=true}} by default.
> And if one of boolean operators in lowercase is present in query it turns off 
> {{mm}} parameter:
> * {{q=Young+6+or+Ariston=edismax=name=100%25=true}}
>   {{"parsedquery_toString": "+((name:young) (name:6) (name:ariston))"}}
> * 
> {{q=Young+6+or+Ariston=edismax=name=100%25=false=true}}
>   {{"parsedquery_toString": "+(((name:young) (name:6) (name:ariston))~3)"}}



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

[Mani (JIRA)]

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

Mani commented on SOLR-7948:


Thank you [~davidchiu] & [~markrmil...@gmail.com] for the suggestions
I faced a similar issue and jar harmonization on the client side helped me to 
resolve.

Environment : 
Solr : 5.2.1
I was running a SolrJ Client Artifact in Jboss 6.2. And httpclient jars (4.2.1) 
part of system dependencies packaged along with jboss is conflicting & 
overriding the jars (4.4.1) packaged with my artifact. 

Using exclusions from [1] in the jboss-deployment-structure.xml one can prevent 
the server to automatically add the dependencies.
[1] https://docs.jboss.org/author/display/AS72/Class+Loading+in+AS7

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

[jira] [Commented] (SOLR-7962) Passing additional arguments to solr.cmd using "-a" does not work on Windows

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-7962:
--

bin/solr has never supported -f with -e because it needs to do things after 
starting the server, so foreground mode doesn't work ...

also, I'm not seeing any issues with using -a on the mac with 5.3.0:

{code}
[~/dev/lw/tools/solr-5.3.0]$ bin/solr -e techproducts -a 
"-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"
Creating Solr home directory 
/Users/timpotter/dev/lw/tools/solr-5.3.0/example/techproducts/solr

Starting up Solr on port 8983 using command:
bin/solr start -p 8983 -s "example/techproducts/solr" -a 
"-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"

Waiting up to 30 seconds to see Solr running on port 8983 [/]  
Started Solr server on port 8983 (pid=55115). Happy searching!


Setup new core instance directory:
/Users/timpotter/dev/lw/tools/solr-5.3.0/example/techproducts/solr/techproducts

Creating new core 'techproducts' using command:
http://localhost:8983/solr/admin/cores?action=CREATE=techproducts=techproducts

{
  "responseHeader":{
"status":0,
"QTime":1237},
  "core":"techproducts"}


Indexing tech product example docs from 
/Users/timpotter/dev/lw/tools/solr-5.3.0/example/exampledocs
SimplePostTool version 5.0.0
Posting files to [base] url http://localhost:8983/solr/techproducts/update 
using content-type application/xml...
POSTing file gb18030-example.xml to [base]
POSTing file hd.xml to [base]
POSTing file ipod_other.xml to [base]
POSTing file ipod_video.xml to [base]
POSTing file manufacturers.xml to [base]
POSTing file mem.xml to [base]
POSTing file money.xml to [base]
POSTing file monitor.xml to [base]
POSTing file monitor2.xml to [base]
POSTing file mp500.xml to [base]
POSTing file sd500.xml to [base]
POSTing file solr.xml to [base]
POSTing file utf8-example.xml to [base]
POSTing file vidcard.xml to [base]
14 files indexed.
COMMITting Solr index changes to 
http://localhost:8983/solr/techproducts/update...
Time spent: 0:00:00.291

Solr techproducts example launched successfully. Direct your Web browser to 
http://localhost:8983/solr to visit the Solr Admin UI
{code}

> Passing additional arguments to solr.cmd using "-a" does not work on Windows
> 
>
> Key: SOLR-7962
> URL: https://issues.apache.org/jira/browse/SOLR-7962
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Dawid Weiss
>




--
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-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[Alessandro Benedetti (JIRA)]

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

Alessandro Benedetti commented on SOLR-6246:


Any update on this ?
is Anyone working on this at the minute ?
I agree is quite important as basically is not possible to consistently use the 
suggester when Solr in Cloud mode !


> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9
>Reporter: Varun Thacker
> Fix For: 5.2, Trunk
>
> Attachments: SOLR-6246-test.patch, SOLR-6246-test.patch, 
> SOLR-6246.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
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-6810) Upgrade to Spatial4j 0.5

[ASF subversion and git services (JIRA)]

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

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

Commit 1704760 from [~dsmiley] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1704760 ]

LUCENE-6810: Spatial4j 0.5 upgrade. Mostly fixes a few edge-case bugs.
* the spatial4j tests jar is published and we use some utilities there; this 
adds a test dependency on it & SLF4J.

> Upgrade to Spatial4j 0.5
> 
>
> Key: LUCENE-6810
> URL: https://issues.apache.org/jira/browse/LUCENE-6810
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 5.4
>
> Attachments: LUCENE-6810_Spatial4j_0_5.patch
>
>
> Spatial4j 0.5 was released a few days ago.  There are some bug fixes, most of 
> which were surfaced via the tests here.  It also publishes the test jar 
> (thanks [~nknize] for that one) and with that there are a couple test 
> utilities here I can remove.
> https://github.com/locationtech/spatial4j/blob/master/CHANGES.md



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.HardAutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([C526F6FB6BF3230E:7FF49983E8DDCD1B]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:765)
at 
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


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




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

[jira] [Resolved] (LUCENE-6671) CompositeStrategyTest.testOperations "[Overlaps] Should have matched" AssertionError

[David Smiley (JIRA)]

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

David Smiley resolved LUCENE-6671.
--
   Resolution: Fixed
Fix Version/s: 5.4

Fixed by LUCENE-6810 (upgrade to Spatial4j 0.5)

> CompositeStrategyTest.testOperations "[Overlaps] Should have matched" 
> AssertionError
> 
>
> Key: LUCENE-6671
> URL: https://issues.apache.org/jira/browse/LUCENE-6671
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Michael McCandless
>Assignee: David Smiley
> Fix For: 5.4
>
>
> I hit this while doing unrelated beasting:
> {noformat}
> -test:
> [mkdir] Created dir: /l/trunk/lucene/build/spatial/test
> [junit4:pickseed] Seed property 'tests.seed' already defined: E1320619EC8749DF
> [mkdir] Created dir: /l/trunk/lucene/build/spatial/test/temp
> [mkdir] Created dir: /l/trunk/.caches/test-stats/spatial
>[junit4]  says hallo! Master seed: E1320619EC8749DF
>[junit4] Executing 1 suite with 1 JVM.
>[junit4] 
>[junit4] Started J0 PID(32324@localhost).
>[junit4] Suite: org.apache.lucene.spatial.composite.CompositeStrategyTest
>[junit4] OK  0.29s | CompositeStrategyTest.testOperations {#0 
> seed=[E1320619EC8749DF:9319DB8F802FC2C7]}
>[junit4] OK  0.08s | CompositeStrategyTest.testOperations {#1 
> seed=[E1320619EC8749DF:274F6773B4ED09EB]}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CompositeStrategyTest -Dtests.method=testOperations 
> -Dtests.seed=E1320619EC8749DF -Dtests.locale=nl_NL 
> -Dtests.timezone=Antarctica/Casey -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 0.15s | CompositeStrategyTest.testOperations {#2 
> seed=[E1320619EC8749DF:A9A6F1AFE5294120]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: [Overlaps] qIdx:1 
> Should have matched I#2:Circle(Pt(x=45.0,y=-8.0), d=88.4° 9827.73km) 
> Q:Circle(Pt(x=-135.0,y=8.0), d=57.5° 6396.19km)
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1320619EC8749DF:A9A6F1AFE5294120]:0)
>[junit4]>  at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:127)
>[junit4]>  at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:121)
>[junit4]>  at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:56)
>[junit4]>  at 
> org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations(CompositeStrategyTest.java:99)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4] OK  0.04s | CompositeStrategyTest.testOperations {#3 
> seed=[E1320619EC8749DF:98485A4A89D71A09]}
>[junit4] OK  0.14s | CompositeStrategyTest.testOperations {#4 
> seed=[E1320619EC8749DF:D489DFE728DFDAB2]}
>[junit4] OK  0.06s | CompositeStrategyTest.testOperations {#5 
> seed=[E1320619EC8749DF:45730CB8556397B2]}
>[junit4] OK  0.04s | CompositeStrategyTest.testOperations {#6 
> seed=[E1320619EC8749DF:7BAD683E475387B4]}
>[junit4] OK  0.06s | CompositeStrategyTest.testOperations {#7 
> seed=[E1320619EC8749DF:E71EF2446447131A]}
>[junit4] OK  0.03s | CompositeStrategyTest.testOperations {#8 
> seed=[E1320619EC8749DF:D5B2172A138C0440]}
>[junit4] OK  0.03s | CompositeStrategyTest.testOperations {#9 
> seed=[E1320619EC8749DF:239419077DB3312]}
>[junit4] OK  0.03s | CompositeStrategyTest.testOperations {#10 
> seed=[E1320619EC8749DF:F778A9CBA56711CA]}
>[junit4] OK  0.03s | CompositeStrategyTest.testOperations {#11 
> seed=[E1320619EC8749DF:7CDF650E21FAB003]}
>[junit4] OK  0.02s | CompositeStrategyTest.testOperations {#12 
> seed=[E1320619EC8749DF:1BECF0B7C48772F2]}
>[junit4] OK  0.04s | CompositeStrategyTest.testOperations {#13 
> seed=[E1320619EC8749DF:74A7D7A85812F382]}
>[junit4] OK  0.02s | CompositeStrategyTest.testOperations {#14 
> seed=[E1320619EC8749DF:2939D8308A63B5DB]}
>[junit4] OK  0.04s | CompositeStrategyTest.testOperations {#15 
> seed=[E1320619EC8749DF:4A8B353498E120EA]}
>[junit4] OK  0.02s | CompositeStrategyTest.testOperations {#16 
> seed=[E1320619EC8749DF:CC7092FD53E94B83]}
>[junit4] OK  0.03s | CompositeStrategyTest.testOperations {#17 
> seed=[E1320619EC8749DF:783F40E69FDC39F1]}
>[junit4] OK  0.04s | CompositeStrategyTest.testOperations {#18 
> seed=[E1320619EC8749DF:674B3FE8E349D6F3]}
>[junit4] OK  0.12s | CompositeStrategyTest.testOperations {#19 
> seed=[E1320619EC8749DF:6DDB4C0449A1905E]}
>[junit4]   2> NOTE: test params are: 

[jira] [Resolved] (LUCENE-6810) Upgrade to Spatial4j 0.5

[David Smiley (JIRA)]

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

David Smiley resolved LUCENE-6810.
--
Resolution: Fixed

> Upgrade to Spatial4j 0.5
> 
>
> Key: LUCENE-6810
> URL: https://issues.apache.org/jira/browse/LUCENE-6810
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 5.4
>
> Attachments: LUCENE-6810_Spatial4j_0_5.patch
>
>
> Spatial4j 0.5 was released a few days ago.  There are some bug fixes, most of 
> which were surfaced via the tests here.  It also publishes the test jar 
> (thanks [~nknize] for that one) and with that there are a couple test 
> utilities here I can remove.
> https://github.com/locationtech/spatial4j/blob/master/CHANGES.md



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

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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 54763 lines...]
BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:775: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:655: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:642: Source 
checkout is dirty after running tests!!! Offending files:
* ./solr/licenses/spatial4j-0.4.1.jar.sha1

Total time: 83 minutes 36 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS-EA] Lucene-Solr-5.3-Linux (64bit/jdk1.9.0-ea-b78) - Build # 230 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.3-Linux/230/
Java: 64bit/jdk1.9.0-ea-b78 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.schema.TestCloudManagedSchemaConcurrent

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

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


FAILED:  org.apache.solr.schema.TestCloudManagedSchemaConcurrent.test

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([8DB09D5EA6565D1E]:0)




Build Log:
[...truncated 11362 lines...]
   [junit4] Suite: org.apache.solr.schema.TestCloudManagedSchemaConcurrent
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-5.3-Linux/solr/build/solr-core/test/J2/temp/solr.schema.TestCloudManagedSchemaConcurrent_8DB09D5EA6565D1E-001/init-core-data-001
   [junit4]   2> 331719 INFO  
(SUITE-TestCloudManagedSchemaConcurrent-seed#[8DB09D5EA6565D1E]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false)
   [junit4]   2> 331719 INFO  
(SUITE-TestCloudManagedSchemaConcurrent-seed#[8DB09D5EA6565D1E]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 331721 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 331721 INFO  (Thread-1031) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 331721 INFO  (Thread-1031) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 331821 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.ZkTestServer start zk server on port:37050
   [junit4]   2> 331822 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 331822 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 331824 INFO  (zkCallback-557-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@4093a2d0 
name:ZooKeeperConnection Watcher:127.0.0.1:37050 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 331824 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 331824 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 331824 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 331825 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 331826 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 331826 INFO  (zkCallback-558-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@46dfff2a 
name:ZooKeeperConnection Watcher:127.0.0.1:37050/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 331826 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 331826 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 331827 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1
   [junit4]   2> 331827 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1/shards
   [junit4]   2> 331828 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection
   [junit4]   2> 331828 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection/shards
   [junit4]   2> 331829 INFO  
(TEST-TestCloudManagedSchemaConcurrent.test-seed#[8DB09D5EA6565D1E]) [] 
o.a.s.c.AbstractZkTestCase put 
/home/jenkins/workspace/Lucene-Solr-5.3-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-managed-schema.xml
 to /configs/conf1/solrconfig.xml
   

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

[Policeman Jenkins Server]

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

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

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([1DAD2B3DBD3D5246:9A2C9690B91D2842]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.lucene.TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler(TestMergeSchedulerExternal.java:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 694 lines...]
   [junit4] Suite: org.apache.lucene.TestMergeSchedulerExternal
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestMergeSchedulerExternal 
-Dtests.method=testSubclassConcurrentMergeScheduler 
-Dtests.seed=1DAD2B3DBD3D5246 -Dtests.slow=true -Dtests.locale=es_CO 
-Dtests.timezone=Etc/GMT+5 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.64s J1 | 
TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler <<<
   [junit4]> Throwable #1: java.lang.AssertionError
   [junit4]>at 

[jira] [Commented] (SOLR-7962) Passing additional arguments to solr.cmd using "-a" does not work on Windows

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-7962:


Thanks for helping Tim.  It turns out that the problem I experienced was 
related to having multiple space separated -X options in my -a:
{{bin/solr -e techproducts  -a "-Xdebug 
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"}}
Granted in this particular case, -Xdebug is legacy and it can be removed.  Do 
we still have a bug to fix?

FYI I quickly got running despite this snag with help from the output of 
setting up the example that shows how to run it without the -e -- and I was 
able to add my -a to that despite the space/multi-arg.

+1 to pass through -X like -D as you suggest.

> Passing additional arguments to solr.cmd using "-a" does not work on Windows
> 
>
> Key: SOLR-7962
> URL: https://issues.apache.org/jira/browse/SOLR-7962
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Dawid Weiss
>




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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5149/
Java: 32bit/jdk1.8.0_60 -client -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.lucene.rangetree.TestRangeTree.testMultiValued

Error Message:
this IndexWriter is closed

Stack Trace:
org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
at 
__randomizedtesting.SeedInfo.seed([577A3E1A95E0C772:835A5A285B22873A]:0)
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:719)
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:733)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1471)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1254)
at 
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:173)
at 
org.apache.lucene.rangetree.TestRangeTree.testMultiValued(TestRangeTree.java:136)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.AssertionError: 
dir=.\temp\RangeTreeWriter361935816584395448 still has 
file=.\temp\RangeTreeWriter361935816584395448\size9362.1772657332124877601
at 
org.apache.lucene.rangetree.RangeTreeWriter.directoryIsEmpty(RangeTreeWriter.java:403)
at 

[jira] [Updated] (SOLR-8082) float query bug when indexed="false" docValues="true" multiValued="false"

[Hoss Man (JIRA)]

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

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

the attached patch demonstrates the breadth of the problems i've found with 
queries against _negative_ values in both float and double based docvalues 
(only) fields -- ie: queries in which DocValuesRangeQuery is used instead of 
the inverted index (via NumericRangeQuery)

I'm still not really clear what the root bug / fix is, but best i can tell this 
is ultimately about a disconnect between how the DocValuesRangeQuery objects 
are built at query time (using NumericUtils.floatToSortableInt and 
NumericUtils.doubleToSortableLong) vs how the NumericDocValuesField objects are 
build at index time (using Float.floatToIntBits and Double.doubleToLongBits)

My bare bones understanding is that both places should be using 
NumericUtils.floatToSortableInt and NumericUtils.doubleToSortableLong -- but 
(besides being a back compat break on how the values are written to disk) if 
that's the case then why does sorting work for negative float values today? 
(see DocValuesTest.testDocValuesSorting2, which -- in addition to many faceting 
tests -- broke when i experimented with using NumericUtils.floatToSortableInt 
and NumericUtils.doubleToSortableLong to build the NumericDocValuesField in 
TrieField.createFields)

Can anyone explain to me:
* when/why floatToIntBits & doubleToLongBits should be used instead of 
floatToSortableInt & doubleToSortableLong
* how to fix these tests so they pass and queries against negative float / 
double values will work?

> float query bug when indexed="false" docValues="true" multiValued="false"
> -
>
> Key: SOLR-8082
> URL: https://issues.apache.org/jira/browse/SOLR-8082
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8082.patch
>
>
> Haven't dug into this yet, but something is evidently wrong in how the 
> DocValues based queries get build for single valued flaot fields (may affect 
> other trie based fields?
> Steps to reproduce...
> {noformat}
> $ bin/solr -e schemaless -noprompt
> ...
> $ curl -X POST -H 'Content-type:application/json' --data-binary '{ 
> "add-field":{ "name":"f_dv_multi", "type":"tfloat", "stored":"true", 
> "indexed":"false", "docValues":"true", "multiValued":"true" }, "add-field":{ 
> "name":"f_dv_single", "type":"tfloat", "stored":"true", "indexed":"false", 
> "docValues":"true", "multiValued":"false" } }' 
> http://localhost:8983/solr/gettingstarted/schema
> {
>   "responseHeader":{
> "status":0,
> "QTime":84}}
> $ curl -X POST -H 'Content-type:application/json' --data-binary 
> '[{"id":"test", "f_dv_multi":-4.3, "f_dv_single":-4.3}]' 
> 'http://localhost:8983/solr/gettingstarted/update/json/docs?commit=true'
> {"responseHeader":{"status":0,"QTime":57}}
> $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:"-4.3;'
> {
>   "responseHeader":{
> "status":0,
> "QTime":5,
> "params":{
>   "q":"f_dv_multi:\"-4.3\""}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"test",
> "f_dv_multi":[-4.3],
> "f_dv_single":-4.3,
> "_version_":1512962117004689408}]
>   }}
> $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:"-4.3;'
> {
>   "responseHeader":{
> "status":0,
> "QTime":5,
> "params":{
>   "q":"f_dv_single:\"-4.3\""}},
>   "response":{"numFound":0,"start":0,"docs":[]
>   }}
> {noformat}
> Explicit range queries (which is how numeric "field" queries are implemented 
> under the cover) are equally problematic...
> {noformat}
> $ curl 
> 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:%5B-4.3+TO+-4.3%5D'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"f_dv_multi:[-4.3 TO -4.3]"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"test",
> "f_dv_multi":[-4.3],
> "f_dv_single":-4.3,
> "_version_":1512962117004689408}]
>   }}
> $ curl 
> 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:%5B-4.3+TO+-4.3%5D'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"f_dv_single:[-4.3 TO -4.3]"}},
>   "response":{"numFound":0,"start":0,"docs":[]
>   }}
> {noformat}



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14277/
Java: 64bit/jdk1.9.0-ea-b78 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest

Error Message:
Captured an uncaught exception in thread: Thread[id=9203, 
name=RecoveryThread-source_collection_shard1_replica1, state=RUNNABLE, 
group=TGRP-CdcrReplicationHandlerTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=9203, 
name=RecoveryThread-source_collection_shard1_replica1, state=RUNNABLE, 
group=TGRP-CdcrReplicationHandlerTest]
Caused by: org.apache.solr.common.cloud.ZooKeeperException: 
at __randomizedtesting.SeedInfo.seed([ABCE6E5ACD91100]:0)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:234)
Caused by: org.apache.solr.common.SolrException: java.io.FileNotFoundException: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_ABCE6E5ACD91100-001/jetty-002/cores/source_collection_shard1_replica1/data/tlog/tlog.008.1513059797781446656
 (No such file or directory)
at 
org.apache.solr.update.CdcrTransactionLog.reopenOutputStream(CdcrTransactionLog.java:244)
at 
org.apache.solr.update.CdcrTransactionLog.incref(CdcrTransactionLog.java:173)
at 
org.apache.solr.update.UpdateLog.getRecentUpdates(UpdateLog.java:1079)
at 
org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1579)
at 
org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1610)
at org.apache.solr.core.SolrCore.seedVersionBuckets(SolrCore.java:877)
at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:526)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:227)
Caused by: java.io.FileNotFoundException: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_ABCE6E5ACD91100-001/jetty-002/cores/source_collection_shard1_replica1/data/tlog/tlog.008.1513059797781446656
 (No such file or directory)
at java.io.RandomAccessFile.open0(Native Method)
at java.io.RandomAccessFile.open(RandomAccessFile.java:327)
at java.io.RandomAccessFile.(RandomAccessFile.java:243)
at 
org.apache.solr.update.CdcrTransactionLog.reopenOutputStream(CdcrTransactionLog.java:236)
... 7 more




Build Log:
[...truncated 10753 lines...]
   [junit4] Suite: org.apache.solr.cloud.CdcrReplicationHandlerTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_ABCE6E5ACD91100-001/init-core-data-001
   [junit4]   2> 981013 INFO  
(SUITE-CdcrReplicationHandlerTest-seed#[ABCE6E5ACD91100]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false)
   [junit4]   2> 981013 INFO  
(SUITE-CdcrReplicationHandlerTest-seed#[ABCE6E5ACD91100]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: 
/sj_bz/z
   [junit4]   2> 981014 INFO  
(TEST-CdcrReplicationHandlerTest.doTest-seed#[ABCE6E5ACD91100]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 981014 INFO  (Thread-3890) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 981014 INFO  (Thread-3890) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 981114 INFO  
(TEST-CdcrReplicationHandlerTest.doTest-seed#[ABCE6E5ACD91100]) [] 
o.a.s.c.ZkTestServer start zk server on port:57374
   [junit4]   2> 981114 INFO  
(TEST-CdcrReplicationHandlerTest.doTest-seed#[ABCE6E5ACD91100]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 981115 INFO  
(TEST-CdcrReplicationHandlerTest.doTest-seed#[ABCE6E5ACD91100]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 981117 INFO  (zkCallback-942-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@27ef7c25 
name:ZooKeeperConnection Watcher:127.0.0.1:57374 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 981117 INFO  
(TEST-CdcrReplicationHandlerTest.doTest-seed#[ABCE6E5ACD91100]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 981117 INFO  
(TEST-CdcrReplicationHandlerTest.doTest-seed#[ABCE6E5ACD91100]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 981117 INFO  
(TEST-CdcrReplicationHandlerTest.doTest-seed#[ABCE6E5ACD91100]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 981118 INFO  
(TEST-CdcrReplicationHandlerTest.doTest-seed#[ABCE6E5ACD91100]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 981118 INFO  

[jira] [Commented] (SOLR-8081) When creating a collection, we need a way to utilize multiple disks available on a node.

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-8081:
--

Thanks [~noble.paul] ... I think that should work as well as the main concern 
is to utilize all disks available. I suppose this is not something that needs 
to have an API since you'll need to make sure the mount points for the disks 
have the correct perms.

I'd like Solr to be smart about assigning replicas to available disks vs. using 
maxReplicasPerDisk, such as if we need to allocate 3 replicas on 2 disks, pick 
the disk to put the 3rd replica on based on disk capacity.

> When creating a collection, we need a way to utilize multiple disks available 
> on a node.
> 
>
> Key: SOLR-8081
> URL: https://issues.apache.org/jira/browse/SOLR-8081
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Timothy Potter
>
> Currently, if I want to change the dataDir for a core (such as to utilize 
> multiple disks on a Solr node), I need to either setup a symlink or change 
> the dataDir property in core.properties and restart the Solr node. For 
> instance, if I have a 4-node SolrCloud cluster and want to create a 
> collection with 4 shards with rf=2, then 8 Solr cores will be created across 
> the cluster, 2 per node. If I want to have each core use a separate disk, 
> then I have to do that after the fact. I'm aware that I could create the 
> collection with rf=1 and then use AddReplica to add additional replicas with 
> a different dataDir set, but that feels cumbersome as well.
> What would be nice is to have a way for me to specify available disks and 
> have Solr use that information when provisioning cores on the node. 
> [~anshumg] mentioned this might be best accomplished with a replica placement 
> strategy.



--
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-8069) Ensure that only the valid ZooKeeper registered leader can put a replica into Leader Initiated Recovery.

[Gregory Chanan (JIRA)]

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

Gregory Chanan commented on SOLR-8069:
--

Most of this seems like just adding defensive checks, which seem reasonable.

{code}List ops = new ArrayList<>(2);{code}
nit: this should be 3 in two places.

{code}
+  ops.add(Op.check(new 
org.apache.hadoop.fs.Path(((ShardLeaderElectionContextBase)context).leaderPath).getParent().toString(),
 leaderZkNodeParentVersion));
   ops.add(Op.setData(znodePath, znodeData, -1));
{code}
What happens if the leaderZkNodeParentVersion doesn't match?  Presumably that's 
a possibility or else why add the check.  We don't want to loop and see if we 
get an updated version in electionContexts?  I'm certainly not well versed in 
this area of the code but checking isLeader seems a little roundabount -- isn't 
the leaderZkNodeParentVersion what we actually care about?  What happens if we 
think we are the leader but the version doesn't match?  What does that mean?  
Certainly we can optimistically try whatever we pulled out of electionContexts 
the first time, as you've done here to avoid a zk trip.

> Ensure that only the valid ZooKeeper registered leader can put a replica into 
> Leader Initiated Recovery.
> 
>
> Key: SOLR-8069
> URL: https://issues.apache.org/jira/browse/SOLR-8069
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Critical
> Attachments: SOLR-8069.patch, SOLR-8069.patch
>
>
> I've seen this twice now. Need to work on a test.
> When some issues hit all the replicas at once, you can end up in a situation 
> where the rightful leader was put or put itself into LIR. Even on restart, 
> this rightful leader won't take leadership and you have to manually clear the 
> LIR nodes.
> It seems that if all the replicas participate in election on startup, LIR 
> should just be cleared.



--
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-7986) JDBC Driver for SQL Interface

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-7986:
-

Hi Joel,

I added locally 3 bad connection string tests. Please let me know your opinion 
before I provide a patch
a) The first below test "testConnectionStringWithMissingZKHost" throws 
SolrException than SQLException. Is that right behaviour. Just wanted to 
confirm.
b) Is it okay to add more public multiple tests method OR have one test method 
and calling various private test methods inside it. Any preference since I see 
the later is more common .
c) The test  "testConnectionStringWithWrongCollection" goes thru various 
retries before it fails. Below the console messages. Is that right behavior. 

Thanks,
Susheel



  @Test
  public void testConnectionStringWithMissingZKHost() throws Exception  {
   //should throw Solr exception as per current design
exception.expect(SolrException.class);
String zkHost = zkServer.getZkAddress();
Properties props = new Properties();
//bad connection string: missing zkHost
   Connection con = DriverManager.getConnection("jdbc:solr://"  + 
"?collection=collection1", props);
  }
  
  @Test
  public void testConnectionStringJumbled() throws Exception  {
//should throw SQL exception
 exception.expect(SQLException.class);
 Properties props = new Properties();
 String zkHost = zkServer.getZkAddress();
 //Bad connection string: string jumbled   
 Connection con = DriverManager.getConnection("solr:jdbc://" + zkHost + 
"?collection=collection1", props);
   }
  
  @Test
  public void testConnectionStringWithWrongCollection() throws Exception  {
 //should throw SQL exception
 exception.expect(SQLException.class);
 Properties props = new Properties();
 String zkHost = zkServer.getZkAddress();
 //Bad connection string: wrong collection name   
 Connection con = DriverManager.getConnection("jdbc:solr://" + zkHost + 
"?collection=mycollection", props);
 Statement stmt = con.createStatement();
 ResultSet rs = stmt.executeQuery("select id, a_i, a_s, a_f from 
mycollection order by a_i desc limit 2");

   } 

testConnectionStringWithWrongCollection console messages.
-
Sep 22, 2015 5:26:28 PM com.carrotsearch.randomizedtesting.ThreadLeakControl 
checkThreadLeaks
WARNING: Will linger awaiting termination of 6 leaked thread(s).
95116 WARN  
(TEST-JdbcTest.testConnectionStringWithWrongCollection-seed#[8ED3B3162E3AB02D]-SendThread(127.0.0.1:55137))
 [n:127.0.0.1:55092_cb_i%2Fof c:collection1 s:shard1 r:core_node4 
x:collection1] o.a.z.ClientCnxn Session 0x14ff6f24fcf0012 for server null, 
unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
96786 WARN  
(TEST-JdbcTest.testConnectionStringWithWrongCollection-seed#[8ED3B3162E3AB02D]-SendThread(127.0.0.1:55137))
 [n:127.0.0.1:55092_cb_i%2Fof c:collection1 s:shard1 r:core_node4 
x:collection1] o.a.z.ClientCnxn Session 0x14ff6f24fcf0012 for server null, 
unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
98838 WARN  
(TEST-JdbcTest.testConnectionStringWithWrongCollection-seed#[8ED3B3162E3AB02D]-SendThread(127.0.0.1:55137))
 [n:127.0.0.1:55092_cb_i%2Fof c:collection1 s:shard1 r:core_node4 
x:collection1] o.a.z.ClientCnxn Session 0x14ff6f24fcf0012 for server null, 
unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
100696 WARN  
(TEST-JdbcTest.testConnectionStringWithWrongCollection-seed#[8ED3B3162E3AB02D]-SendThread(127.0.0.1:55137))
 [n:127.0.0.1:55092_cb_i%2Fof c:collection1 s:shard1 r:core_node4 
x:collection1] o.a.z.ClientCnxn Session 0x14ff6f24fcf0012 for server null, 
unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection refused

[jira] [Updated] (SOLR-8082) can't query against negative float or double values when indexed="false" docValues="true" multiValued="false"

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-8082:
---
Description: 
Haven't dug into this yet, but something is evidently wrong in how the 
DocValues based queries get build for single valued float or double fields when 
negative numbers are involved.

Steps to reproduce...

{noformat}
$ bin/solr -e schemaless -noprompt
...
$ curl -X POST -H 'Content-type:application/json' --data-binary '{ 
"add-field":{ "name":"f_dv_multi", "type":"tfloat", "stored":"true", 
"indexed":"false", "docValues":"true", "multiValued":"true" }, "add-field":{ 
"name":"f_dv_single", "type":"tfloat", "stored":"true", "indexed":"false", 
"docValues":"true", "multiValued":"false" } }' 
http://localhost:8983/solr/gettingstarted/schema
{
  "responseHeader":{
"status":0,
"QTime":84}}
$ curl -X POST -H 'Content-type:application/json' --data-binary '[{"id":"test", 
"f_dv_multi":-4.3, "f_dv_single":-4.3}]' 
'http://localhost:8983/solr/gettingstarted/update/json/docs?commit=true'
{"responseHeader":{"status":0,"QTime":57}}
$ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:"-4.3;'
{
  "responseHeader":{
"status":0,
"QTime":5,
"params":{
  "q":"f_dv_multi:\"-4.3\""}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"id":"test",
"f_dv_multi":[-4.3],
"f_dv_single":-4.3,
"_version_":1512962117004689408}]
  }}
$ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:"-4.3;'
{
  "responseHeader":{
"status":0,
"QTime":5,
"params":{
  "q":"f_dv_single:\"-4.3\""}},
  "response":{"numFound":0,"start":0,"docs":[]
  }}
{noformat}

Explicit range queries (which is how numeric "field" queries are implemented 
under the cover) are equally problematic...

{noformat}
$ curl 
'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:%5B-4.3+TO+-4.3%5D'
{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"f_dv_multi:[-4.3 TO -4.3]"}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"id":"test",
"f_dv_multi":[-4.3],
"f_dv_single":-4.3,
"_version_":1512962117004689408}]
  }}
$ curl 
'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:%5B-4.3+TO+-4.3%5D'
{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"f_dv_single:[-4.3 TO -4.3]"}},
  "response":{"numFound":0,"start":0,"docs":[]
  }}
{noformat}

  was:
Haven't dug into this yet, but something is evidently wrong in how the 
DocValues based queries get build for single valued flaot fields (may affect 
other trie based fields?

Steps to reproduce...

{noformat}
$ bin/solr -e schemaless -noprompt
...
$ curl -X POST -H 'Content-type:application/json' --data-binary '{ 
"add-field":{ "name":"f_dv_multi", "type":"tfloat", "stored":"true", 
"indexed":"false", "docValues":"true", "multiValued":"true" }, "add-field":{ 
"name":"f_dv_single", "type":"tfloat", "stored":"true", "indexed":"false", 
"docValues":"true", "multiValued":"false" } }' 
http://localhost:8983/solr/gettingstarted/schema
{
  "responseHeader":{
"status":0,
"QTime":84}}
$ curl -X POST -H 'Content-type:application/json' --data-binary '[{"id":"test", 
"f_dv_multi":-4.3, "f_dv_single":-4.3}]' 
'http://localhost:8983/solr/gettingstarted/update/json/docs?commit=true'
{"responseHeader":{"status":0,"QTime":57}}
$ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:"-4.3;'
{
  "responseHeader":{
"status":0,
"QTime":5,
"params":{
  "q":"f_dv_multi:\"-4.3\""}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"id":"test",
"f_dv_multi":[-4.3],
"f_dv_single":-4.3,
"_version_":1512962117004689408}]
  }}
$ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:"-4.3;'
{
  "responseHeader":{
"status":0,
"QTime":5,
"params":{
  "q":"f_dv_single:\"-4.3\""}},
  "response":{"numFound":0,"start":0,"docs":[]
  }}
{noformat}

Explicit range queries (which is how numeric "field" queries are implemented 
under the cover) are equally problematic...

{noformat}
$ curl 
'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:%5B-4.3+TO+-4.3%5D'
{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"f_dv_multi:[-4.3 TO -4.3]"}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"id":"test",
"f_dv_multi":[-4.3],
"f_dv_single":-4.3,
"_version_":1512962117004689408}]
  }}
$ curl 
'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:%5B-4.3+TO+-4.3%5D'
{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"f_dv_single:[-4.3 TO -4.3]"}},
  "response":{"numFound":0,"start":0,"docs":[]
  }}
{noformat}

Summary: can't query against negative float or double values when 
indexed="false" docValues="true" multiValued="false"  (was: float 

[jira] [Commented] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8068:


Let's leave this issue as is right now and not commit anything here specially 
considering the fact that we have figured out why it happened. We haven't even 
really other users report this.

I'll leave this open for us to come back, in case this happens again but for 
now, let's move on with the 5.3.1 release.

What do you guys think?

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch, 
> solr-core-5.3.0-SNAPSHOT.jar
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {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-8068) NPE in SolrDispatchFilter.authenticateRequest

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8068:
-

I marked the other linked issue as a blocker (for windows), so perhaps solving 
that will also solve this.

The latest hint on the other issue was that something in the init sequence 
treats relative path differently from the absolute path, though - unhelpfully - 
all the log messages are identical.

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch, 
> solr-core-5.3.0-SNAPSHOT.jar
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {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-8068) NPE in SolrDispatchFilter.authenticateRequest

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8068:


[~anshumg] Please feel free to disregard, but my preference would be to commit 
either of the patches to 5.3.1, since it is a good to have safety check anyway.

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch, 
> solr-core-5.3.0-SNAPSHOT.jar
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {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

Re: [CI] Lucene 5x Linux 64 Test Only - Build # 64501 - Failure!

[Michael McCandless]

This was a test bug, I committed a fix:
https://issues.apache.org/jira/browse/LUCENE-6734

But unfortunately it looks like ES Jenkins build failures still require
moderation ... I'll dig.

Mike McCandless

On Fri, Sep 18, 2015 at 3:10 PM,  wrote:

> *BUILD FAILURE*
> Build URL
> http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/64501/
> 
> Project:lucene_linux_java8_64_test_only Randomization: 
> JDKEA8,network,heap[578m],-server
> +UseConcMarkSweepGC -UseCompressedOops +AggressiveOpts,sec manager on Date
> of build:Fri, 18 Sep 2015 21:02:55 +0200 Build duration:7 min 29 sec
> *CHANGES* No Changes
> *BUILD ARTIFACTS*
> -
> checkout/lucene/build/codecs/test/temp/junit4-J0-20150918_210929_793.events
> 
> -
> checkout/lucene/build/codecs/test/temp/junit4-J1-20150918_210929_793.events
> 
> -
> checkout/lucene/build/codecs/test/temp/junit4-J2-20150918_210929_793.events
> 
> -
> checkout/lucene/build/codecs/test/temp/junit4-J3-20150918_210929_793.events
> 
> -
> checkout/lucene/build/codecs/test/temp/junit4-J4-20150918_210929_794.events
> 
> -
> checkout/lucene/build/codecs/test/temp/junit4-J5-20150918_210929_794.events
> 
> -
> checkout/lucene/build/codecs/test/temp/junit4-J6-20150918_210929_794.events
> 

[jira] [Commented] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8068:


[~ichattopadhyaya] we _shouldn't_ hit this situation at all and if cores is 
null, at some point, the request should fail fast, before it even gets to that 
line. Adding that line there only transforms the Exception from NPE to 
SolrException for the user, which is a better experience but not correct.
Unless we know when/why would this happen, I'm against masking the error.

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch, 
> solr-core-5.3.0-SNAPSHOT.jar
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[jira] [Updated] (SOLR-8084) Original UI: Plugins/Stats "refresh values" link has problems in Chrome and Microsoft browsers

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) updated SOLR-8084:

Attachment: SOLR-8084.patch

using {{return false;}} disables the browser default handling of a link 
(actually switching to the referenced url in {{href}} - therefore just 
executing the {{window.location.reload}} which will stay on the current url. 
and not switch (back) to the dashboard as described in the original report from 
Lorenzo.

> Original UI: Plugins/Stats "refresh values" link has problems in Chrome and 
> Microsoft browsers
> --
>
> Key: SOLR-8084
> URL: https://issues.apache.org/jira/browse/SOLR-8084
> Project: Solr
>  Issue Type: Bug
>  Components: UI, web gui
>Affects Versions: 5.3
>Reporter: Shawn Heisey
> Attachments: SOLR-8084.patch
>
>
> On the "Plugins/Stats" page, there is a "Refresh Values" link.
> A user on the mailing list was having problems with this link going to the 
> dashboard.
> My testing on Windows 10 with 5.3.0 on the current UI showed Firefox working 
> properly, but Chrome and Microsoft browsers have problems.  Edge and Chrome 
> return to the dashboard as the user noticed.  IE11 throws up an error that 
> says "404 Not Found get".  When that popup is dismissed, the right pane of 
> the window is empty except for a constant spinning icon saying "Loading ...".
> The Angular UI shows no problems in all four browsers.  I did not test with 
> any others.



--
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: [CI] Lucene 5x Linux 64 Test Only - Build # 64501 - Failure!

[Chris Hostetter]

Mike: please forward me the entire email (from jenkins) that you recieved 
with all headers.

I don't believe this email ever made it to the dev@lucene moderation queue 
at all (i can't find a record of it at first glace, but because of how the 
moderation queue uses attachments it's a pain to check w/o fully qualified 
date headers and the sender info) ... i suspect the copy you got was just 
because it was sent to some internal @elastic list (not avert being 
moderated on dev@lucene)



: Date: Tue, 22 Sep 2015 12:01:47 -0400
: From: Michael McCandless 
: Reply-To: dev@lucene.apache.org
: To: Dev Elasticsearch 
: Cc: "dev@lucene.apache.org" ,
: "sim...@apache.org" 
: Subject: Re: [CI] Lucene 5x Linux 64 Test Only - Build # 64501 - Failure!
: 
: This was a test bug, I committed a fix:
: https://issues.apache.org/jira/browse/LUCENE-6734
: 
: But unfortunately it looks like ES Jenkins build failures still require
: moderation ... I'll dig.
: 
: Mike McCandless
: 
: On Fri, Sep 18, 2015 at 3:10 PM,  wrote:
: 
: > *BUILD FAILURE*
: > Build URL
: > http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/64501/
: > 

: > Project:lucene_linux_java8_64_test_only Randomization: 
JDKEA8,network,heap[578m],-server
: > +UseConcMarkSweepGC -UseCompressedOops +AggressiveOpts,sec manager on Date
: > of build:Fri, 18 Sep 2015 21:02:55 +0200 Build duration:7 min 29 sec
: > *CHANGES* No Changes
: > *BUILD ARTIFACTS*
: > -
: > checkout/lucene/build/codecs/test/temp/junit4-J0-20150918_210929_793.events
: > 

: > -
: > checkout/lucene/build/codecs/test/temp/junit4-J1-20150918_210929_793.events
: > 

: > -
: > checkout/lucene/build/codecs/test/temp/junit4-J2-20150918_210929_793.events
: > 

: > -
: > checkout/lucene/build/codecs/test/temp/junit4-J3-20150918_210929_793.events
: > 

: > -
: > checkout/lucene/build/codecs/test/temp/junit4-J4-20150918_210929_794.events
: > 

[jira] [Created] (SOLR-8085) ChaosMonkey Safe Leader Test fail with shard inconsistency.

[Mark Miller (JIRA)]

Mark Miller created SOLR-8085:
-

 Summary: ChaosMonkey Safe Leader Test fail with shard 
inconsistency.
 Key: SOLR-8085
 URL: https://issues.apache.org/jira/browse/SOLR-8085
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller


I've been discussing this fail I found with Yonik.

The problem seems to be that a replica tries to recover and publishes 
recovering - the attempt then fails, but docs are now coming in from the 
leader. The replica tries to recover again and has gotten enough docs to pass 
peery sync.

I'm trying a possible solution now where we won't allow peer sync after a 
recovery that is not successful.



--
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-8068) NPE in SolrDispatchFilter.authenticateRequest

[Markus Jelsma (JIRA)]

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

Markus Jelsma updated SOLR-8068:

Attachment: solr-core-5.3.0-SNAPSHOT.jar

This is our solr-core.jar, taken directly from one of the affected locations. 
It has SOLR-4137, SOLR-5149 and SOLR-7968 patched over the original 5.3.0 
sources but the Solr's having the role of the affected machines do not use it.

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch, 
> solr-core-5.3.0-SNAPSHOT.jar
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {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] [Comment Edited] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-8068 at 9/22/15 8:19 AM:
---

As it is a patched version of Solr, it is hard to verify the lines. 

Is it possible to test with the upcoming version of Solr 
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.1-RC3-rev1703449/solr/

comparing with the decompiled class it looks like you have authentication 
enabled. Can you also share the security.json from your ZK ?


was (Author: noble.paul):
As it is a patched version of Solr, it is hard to verify the lines. 

Is it possible to test with the upcoming version of Solr 
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.1-RC3-rev1703449/solr/

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch, 
> solr-core-5.3.0-SNAPSHOT.jar
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {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] [Comment Edited] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-8068 at 9/22/15 8:20 AM:
---

As it is a patched version of Solr, it is hard to verify the lines. 

Is it possible to test with the upcoming version of Solr 
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.1-RC3-rev1703449/solr/

comparing with the decompiled class it looks like you have authentication 
enabled. Can you also share the security.json from your ZK ?(please mask the 
irrelevant pieces. I just need to know if it is enabled or not)


was (Author: noble.paul):
As it is a patched version of Solr, it is hard to verify the lines. 

Is it possible to test with the upcoming version of Solr 
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.1-RC3-rev1703449/solr/

comparing with the decompiled class it looks like you have authentication 
enabled. Can you also share the security.json from your ZK ?

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch, 
> solr-core-5.3.0-SNAPSHOT.jar
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {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-8068) NPE in SolrDispatchFilter.authenticateRequest

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-8068:
-

Hello - We do not have security enabled, also the security.json is quite empty.

version0
aversion0
children_count0
ctimeThu Sep 10 14:48:15 UTC 2015 (1441896495665)
cversion0
czxid4294968678
ephemeralOwner0
mtimeThu Sep 10 14:48:15 UTC 2015 (1441896495665)
mzxid4294968678
pzxid4294968678
dataLength2
{}

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch, 
> solr-core-5.3.0-SNAPSHOT.jar
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 327 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/327/

No tests ran.

Build Log:
[...truncated 14463 lines...]
package-src-tgz:
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/README.txt
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/simpletext
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/simpletext/TestSimpleTextCompoundFormat.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/simpletext/TestSimpleTextDocValuesFormat.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/simpletext/TestSimpleTextPostingsFormat.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/simpletext/TestSimpleTextStoredFieldsFormat.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/simpletext/TestSimpleTextTermVectorsFormat.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/simpletext/TestSimpleTextNormsFormat.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/simpletext/TestSimpleTextSegmentInfoFormat.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/simpletext/TestSimpleTextFieldInfoFormat.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/blocktreeords
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/blocktreeords/TestOrdsBlockTree.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/blockterms
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/blockterms/TestVarGapFixedIntervalPostingsFormat.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/blockterms/TestFixedGapPostingsFormat.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/blockterms/TestVarGapDocFreqIntervalPostingsFormat.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/autoprefix
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/autoprefix/TestAutoPrefixTerms.java
 [exec] A
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/solr/build/solr/svn-export/lucene/codecs/src/test/org/apache/lucene/codecs/autoprefix/TestAutoPrefixPostingsFormat.java

[jira] [Commented] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8068:
--

[~markus17] can you post your {{solr-core-x.y.x.jar}} in that node here. I can 
cross verify it locally

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {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-8068) NPE in SolrDispatchFilter.authenticateRequest

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8068:
--

As it is a patched version of Solr, it is hard to verify the lines. 

Is it possible to test with the upcoming version of Solr 
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.1-RC3-rev1703449/solr/

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch, 
> solr-core-5.3.0-SNAPSHOT.jar
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {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-7858) Make Angular UI default

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-7858:
-

Thanks [~hossman_luc...@fucit.org] for your rich perspective.

Firstly, to answer your question: yes, the new UI has been in trunk/5x since 
5.2. As to whether it has been functional, there are a lot less bugs than there 
were, although you are right to observe that it needs usage.

= o =
URLs:

In your comments you were concerned about how a user would be able to find out 
which UI they are using and what the purpose of the change is. I've added links 
at the top right of the old, and new UIs to switch between them, and a (?) link 
that points to a wiki page explaining further. I hope this does sufficient in 
terms of messaging - although your suggestion of a banner saying "this is the 
old UI, go try the new one-->" seems like a good idea.

Personally, I'd support a redirect from http://localhost:8983/ and 
http://localhost:8983/solr/ to http://localhost:8983/solr/admin/ and host the 
entire UI there. You mention the risk of URL overlap, but we already have that 
issue, in more dangerous ways, with files in the UI using the URL space that 
end-users access. At least if we switched to /admin/, we would only be in 
conflict with ourselves, in which case it is infinitely more manageable. And, 
it is already pretty much a given that 'admin' wouldn't work as a collection 
name.

I would, however, suggest we keep this for trunk/6.0. As a code change, it is 
small. As a usability one, it is much bigger.

= o =

Based upon your suggestions, my release proposal and schedule would be:
 * 5x already has links between old/new UIs so users of 5.4 will be able to get 
to the new one easily
 * There is also a ? link that points to a wiki page explaining the change and 
asking for bug reports
 * Add a banner saying "go try the new UI" on the old one, both in trunk and 5x
 * Change URLs in trunk straight away so that the new UI is the default (old 
one as /original-ui.html)
 * Add a note in CHANGES.txt for 5.4 stating clearly that it will become 
default in 5.5.
 * Assuming no major clangers, for 5.5, change the URLs to make the new default 
(old one is /original-ui.html)
 * For trunk, change the UI to serve from /admin/. Files remain in the same 
location.


> Make Angular UI default
> ---
>
> Key: SOLR-7858
> URL: https://issues.apache.org/jira/browse/SOLR-7858
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Reporter: Upayavira
>Assignee: Upayavira
>Priority: Minor
> Attachments: SOLR-7858.patch, new ui link.png, original UI link.png
>
>
> Angular UI is very close to feature complete. Once SOLR-7856 is dealt with, 
> it should function well in most cases. I propose that, as soon as 5.3 has 
> been released, we make the Angular UI default, ready for the 5.4 release. We 
> can then fix any more bugs as they are found, but more importantly start 
> working on the features that were the reason for doing this work in the first 
> place.



--
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-8068) NPE in SolrDispatchFilter.authenticateRequest

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8068:
--

[~markus17] it is not useful to provide a stacktrace for a snapshot build. We 
can't really figure out what the issue is unless we have the exact source code 
with us. 

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch, 
> solr-core-5.3.0-SNAPSHOT.jar
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b78) - Build # 14271 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14271/
Java: 32bit/jdk1.9.0-ea-b78 -client -XX:+UseParallelGC

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=9519, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java: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=9517, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)3) Thread[id=9521, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java: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=9518, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java: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=9520, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java: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.SaslZkACLProviderTest: 
   1) Thread[id=9519, name=ou=system.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 

[jira] [Commented] (SOLR-8080) 'bin/solr start' should print informative errors when the JVM version is insufficient

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8080:


That must've been accidental (keyboard shortcut). But, I was actually thinking 
of removing that as it still affects only 5.3 and might be fixed with 5.4.

That's been my interpretation of the affected versions field, but I could be 
wrong there. I generally only add already released versions in the list of 
'affected versions'.

I'll add that back and if this gets fixed in time for 5.4, we could always 
remove 5.4 from there again.

> 'bin/solr start' should print informative errors when the JVM version is 
> insufficient
> -
>
> Key: SOLR-8080
> URL: https://issues.apache.org/jira/browse/SOLR-8080
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.3, Trunk
>Reporter: Steve Rowe
>Priority: Minor
>
> From the unpacked 5.3.0 distribution, with Java6 set in {{$JAVA_HOME}} and 
> the {{$PATH}}, there is some indication that there is a problem (Java7 is 
> minimum supported JVM version) - bin/solr times out waiting for Solr to start 
> up - but no info is printed about what the problem might be:
> {noformat}
> $ echo $JAVA_HOME
> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> $ java -version
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
> $ bin/solr start
> Waiting up to 30 seconds to see Solr running on port 8983 [\]  Still not 
> seeing Solr listening on 8983 after 30 seconds!
> tail:~/temp/solr-5.3.0/server/logs/solr.log: No such file or directory
> {noformat}
> On trunk (built via {{ant server}} with Java8), the situation is worse - 
> although Solr started, it's not in a usable state, and there is no indication 
> given that there is a problem:
> {noformat}
> $ java -version
> java version "1.7.0_71"
> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
> $ echo $JAVA_HOME
> /Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home
> sarowe@smb [2048]$ bin/solr start
> Waiting up to 30 seconds to see Solr running on port 8983 [/]  
> Started Solr server on port 8983 (pid=50551). Happy searching!
> {noformat}
> From {{server/logs/solr.log}}:
> {noformat}
> 2015-09-21 17:15:28.991 WARN  (main) [   ] o.e.j.u.c.AbstractLifeCycle FAILED 
> So
> lrRequestFilter: java.lang.UnsupportedClassVersionError: 
> org/apache/solr/servlet
> /SolrDispatchFilter : Unsupported major.minor version 52.0
> java.lang.UnsupportedClassVersionError: 
> org/apache/solr/servlet/SolrDispatchFilt
> er : Unsupported major.minor version 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:14
> 2)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> [...]
> 2015-09-21 17:15:29.020 INFO  (main) [   ] o.e.j.s.ServerConnector Started 
> ServerConnector@24d25ddc{HTTP/1.1}{0.0.0.0:8983}
> 2015-09-21 17:15:29.020 INFO  (main) [   ] o.e.j.s.Server Started @1237ms
> {noformat}



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

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

[jira] [Commented] (SOLR-8078) Data driven solrconfig spellchecker refers to a non-existent field

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-8078:
-

bq. But pragmatically, I think switching to _text_ for data driven spell 
checking is a reasonable fix to allow data driven to work out of the box with 
spell checking.

Would this work or were you hinting at something else?

{code}
curl http://localhost:8983/solr/gettingstarted/config -H 
'Content-type:application/json'  -d '
{
"add-searchcomponent": {
"name": "myspellcheck",
"class": "solr.SpellCheckComponent",
"queryAnalyzerFieldType": "text_general",
"spellchecker": {
"name": "default",
"field": "_text_",
"classname": "solr.DirectSolrSpellChecker"
}
}
}'
{code}

> Data driven solrconfig spellchecker refers to a non-existent field
> --
>
> Key: SOLR-8078
> URL: https://issues.apache.org/jira/browse/SOLR-8078
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>
> In the data driven solrconfig.xml file, the "default" spellchecker refers to 
> a field called "text" which doesn't exist in the schema.
> Even the "wordbreak" spellchecker refers to a field called "name" which does 
> not exist. 
> So when you run this query 
> {{http://localhost:8983/solr/gettingstarted/spell?q=*}} Solr will throw an 
> error. 
> I guess the field name should be {{\_text\_}} ?



--
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: [JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 316 - Failure

[Michael McCandless]

Thank you for finding it and fixing it Dawid!

Mike McCandless

http://blog.mikemccandless.com


On Tue, Sep 22, 2015 at 7:03 AM, Dawid Weiss  wrote:
> This was a bug, Mike. Thanks for being so diligent and noticing this.
>
> Dawid
>
> On Thu, Sep 10, 2015 at 12:26 AM, Michael McCandless
>  wrote:
>> OK thanks for the analysis Dawid.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Wed, Sep 9, 2015 at 5:58 PM, Dawid Weiss  wrote:
>>> Hi Mike.
>>>
>>> I know what caused it. It's a "test suite" timeout, but the runner
>>> still attempts to execute any remaining tests, even after the timeout
>>> watchdog killed the test that hung. It's a bug in the runner in other
>>> words (but it doesn't change the fact that the original test did
>>> hang).
>>>
>>> Dawid
>>>
>>>
>>> On Wed, Sep 9, 2015 at 12:07 PM, Dawid Weiss  wrote:
 This does look suspicious, Mike. Looks like interrupt() on
 testLiveMaxMergeCount somehow escaped and the next test started...
 I'll have to take a look at the code to see how (and if) this is
 possible. It shouldn't be.

 D.

 On Wed, Sep 9, 2015 at 12:02 PM, Michael McCandless
  wrote:
> Spooky failure in TestConcurrentMergeScheduler.testLiveMaxMergeCount:
> it seems like IW.forceMerge failed to notice that in fact all merges
> had completed, so the calling thread waited forever for it to
> finish...
>
> But, in the "interrupting leaked threads", why is there a "still
> running" thread from a different test case (testTotalBytesSize)?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Sep 9, 2015 at 3:07 AM, Apache Jenkins Server
>  wrote:
>> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/316/
>>
>> No tests ran.
>>
>> Build Log:
>> [...truncated 53196 lines...]
>> prepare-release-no-sign:
>> [mkdir] Created dir: 
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
>>  [copy] Copying 461 files to 
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
>>  [copy] Copying 245 files to 
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
>>[smoker] Java 1.7 
>> JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
>>[smoker] Java 1.8 
>> JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
>>[smoker] NOTE: output encoding is UTF-8
>>[smoker]
>>[smoker] Load release URL 
>> "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/"...
>>[smoker]
>>[smoker] Test Lucene...
>>[smoker]   test basics...
>>[smoker]   get KEYS
>>[smoker] 0.1 MB in 0.01 sec (11.6 MB/sec)
>>[smoker]   check changes HTML...
>>[smoker]   download lucene-5.4.0-src.tgz...
>>[smoker] 28.5 MB in 0.04 sec (753.0 MB/sec)
>>[smoker] verify md5/sha1 digests
>>[smoker]   download lucene-5.4.0.tgz...
>>[smoker] 65.9 MB in 0.09 sec (741.7 MB/sec)
>>[smoker] verify md5/sha1 digests
>>[smoker]   download lucene-5.4.0.zip...
>>[smoker] 76.2 MB in 0.10 sec (763.7 MB/sec)
>>[smoker] verify md5/sha1 digests
>>[smoker]   unpack lucene-5.4.0.tgz...
>>[smoker] verify JAR metadata/identity/no javax.* or java.* 
>> classes...
>>[smoker] test demo with 1.7...
>>[smoker]   got 6104 hits for query "lucene"
>>[smoker] checkindex with 1.7...
>>[smoker] test demo with 1.8...
>>[smoker]   got 6104 hits for query "lucene"
>>[smoker] checkindex with 1.8...
>>[smoker] check Lucene's javadoc JAR
>>[smoker]   unpack lucene-5.4.0.zip...
>>[smoker] verify JAR metadata/identity/no javax.* or java.* 
>> classes...
>>[smoker] test demo with 1.7...
>>[smoker]   got 6104 hits for query "lucene"
>>[smoker] checkindex with 1.7...
>>[smoker] test demo with 1.8...
>>[smoker]   got 6104 hits for query "lucene"
>>[smoker] checkindex with 1.8...
>>[smoker] check Lucene's javadoc JAR
>>[smoker]   unpack lucene-5.4.0-src.tgz...
>>[smoker] make sure no JARs/WARs in src dist...
>>[smoker] run "ant validate"
>>[smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
>>[smoker] test demo with 1.7...
>>[smoker]   got 212 hits for query "lucene"
>>[smoker] checkindex with 1.7...

[jira] [Created] (SOLR-8083) Convert the ZookeeperInfoServlet to an handler at /admin/zookeeper

[Noble Paul (JIRA)]

Noble Paul created SOLR-8083:


 Summary: Convert the ZookeeperInfoServlet to an handler at 
/admin/zookeeper 
 Key: SOLR-8083
 URL: https://issues.apache.org/jira/browse/SOLR-8083
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul


There is no need to have an extra servlet for this purpose 

By keeping this outside of Solr we cannot even secure it properly using the 
security framework



--
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-8083) Convert the ZookeeperInfoServlet to an handler at /admin/zookeeper

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-8083:
-
Description: 
There is no need to have an extra servlet for this purpose 

By keeping this outside of Solr we cannot even secure it properly using the 
security framework and now we have taken up a top level name called zookeeper 
which cannot be used as a collection name

  was:
There is no need to have an extra servlet for this purpose 

By keeping this outside of Solr we cannot even secure it properly using the 
security framework


> Convert the ZookeeperInfoServlet to an handler at /admin/zookeeper 
> ---
>
> Key: SOLR-8083
> URL: https://issues.apache.org/jira/browse/SOLR-8083
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> There is no need to have an extra servlet for this purpose 
> By keeping this outside of Solr we cannot even secure it properly using the 
> security framework and now we have taken up a top level name called zookeeper 
> which cannot be used as a collection name



--
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-7962) Passing additional arguments to solr.cmd using "-a" does not work on Windows

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-7962:


I ran into this issue, and I'm on a Mac (not Windows).  I think we can re-title 
this issue to "solr CLI -e example doesn't honor some other CLI options".  I 
tried to pass -f which was ignored, and I tried -a to run in debug mode and it 
barfed with the error {{Failed to parse command-line arguments due to: 
Unrecognized option: 
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"}}.  

So it's not immediately clear how I'm going to get past this... maybe I'll 
observe the SolrCLI invocation when I run the script with "sh -ex" and hack 
that to include the debug options I want.

> Passing additional arguments to solr.cmd using "-a" does not work on Windows
> 
>
> Key: SOLR-7962
> URL: https://issues.apache.org/jira/browse/SOLR-7962
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Dawid Weiss
>




--
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=14902304#comment-14902304
 ] 

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

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

LUCENE-6780: factor out base geo point test class

> 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-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=14902313#comment-14902313
 ] 

Michael McCandless commented on LUCENE-6780:


I factored out a common test base class, for TestBKDTree and TestGeoPointQuery, 
and in the process found a test bug in 
{{TestGeoPointQuery.bboxQueryCanBeWrong}} where it was being way too lenient in 
returning {{true}}.

I fixed that to instead check whether {{GeoUtils.compare}} returns 0.0 for any 
of the rect's boundaries, but now there are new test failures, e.g.:

{noformat}
   [junit4] Started J0 PID(11346@localhost).
   [junit4] Suite: org.apache.lucene.search.TestGeoPointQuery
   [junit4]   1> 
TEST-TestGeoPointQuery.testMultiValued-seed#[880EAE9C08D4DB54]: id=4591 
docID=4591 should not match but did
   [junit4]   1>   rect=GeoRect(lon=-153.18749899012866 TO -152.61749242472143 
lat=33.44312055800268 TO 33.95438073558091)
   [junit4]   1>   lat=32.553960682161375 lon=-154.2675789624302
   [junit4]   1>   lat=33.95438025524065 lon=-152.86846841320704
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeoPointQuery 
-Dtests.method=testMultiValued -Dtests.seed=880EAE9C08D4DB54 -Dtests.slow=true 
-Dtests.linedocsfile=/lucenedata/hudson.enwiki.random.lines.txt.fixed 
-Dtests.locale=nl_BE -Dtests.timezone=Europe/Tallinn -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 10.7s | TestGeoPointQuery.testMultiValued <<<
   [junit4]> Throwable #1: java.lang.AssertionError: some hits were wrong
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([880EAE9C08D4DB54:5C2ECAAEC6169B1C]:0)
   [junit4]>at 
org.apache.lucene.util.BaseGeoPointTestCase.testMultiValued(BaseGeoPointTestCase.java:280)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene53): 
{id=PostingsFormat(name=LuceneVarGapFixedInterval), 
point=PostingsFormat(name=Asserting)}, 
docValues:{point=DocValuesFormat(name=Asserting)}, sim=ClassicSimilarity, 
locale=nl_BE, timezone=Europe/Tallinn
   [junit4]   2> NOTE: Linux 3.13.0-61-generic amd64/Oracle Corporation 
1.8.0_40 (64-bit)/cpus=8,threads=1,free=366930072,total=501219328
   [junit4]   2> NOTE: All tests run in this JVM: [TestGeoPointQuery]
   [junit4] Completed [1/1] in 11.10s, 1 test, 1 failure <<< FAILURES!
{noformat}

The failure is clearly a boundary case, so maybe we just need a better "is 
boundary case" check?

It's also entirely possible I created new exciting test bugs in the refactoring 
:)

And we still have the test failures for both BKD and GeoPoint distance queries 
when distance is biggish...

> 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-8081) When creating a collection, we need a way to utilize multiple disks available on a node.

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8081:
--

The replica placement strategy will help you if you have multiple nodes running 
in the same host pointing to different disks. If you have a single node running 
in a host and you still want different cores to point to different disks , it's 
not possible

> When creating a collection, we need a way to utilize multiple disks available 
> on a node.
> 
>
> Key: SOLR-8081
> URL: https://issues.apache.org/jira/browse/SOLR-8081
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Timothy Potter
>
> Currently, if I want to change the dataDir for a core (such as to utilize 
> multiple disks on a Solr node), I need to either setup a symlink or change 
> the dataDir property in core.properties and restart the Solr node. For 
> instance, if I have a 4-node SolrCloud cluster and want to create a 
> collection with 4 shards with rf=2, then 8 Solr cores will be created across 
> the cluster, 2 per node. If I want to have each core use a separate disk, 
> then I have to do that after the fact. I'm aware that I could create the 
> collection with rf=1 and then use AddReplica to add additional replicas with 
> a different dataDir set, but that feels cumbersome as well.
> What would be nice is to have a way for me to specify available disks and 
> have Solr use that information when provisioning cores on the node. 
> [~anshumg] mentioned this might be best accomplished with a replica placement 
> strategy.



--
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: [JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 316 - Failure

[Dawid Weiss]

This was a bug, Mike. Thanks for being so diligent and noticing this.

Dawid

On Thu, Sep 10, 2015 at 12:26 AM, Michael McCandless
 wrote:
> OK thanks for the analysis Dawid.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Sep 9, 2015 at 5:58 PM, Dawid Weiss  wrote:
>> Hi Mike.
>>
>> I know what caused it. It's a "test suite" timeout, but the runner
>> still attempts to execute any remaining tests, even after the timeout
>> watchdog killed the test that hung. It's a bug in the runner in other
>> words (but it doesn't change the fact that the original test did
>> hang).
>>
>> Dawid
>>
>>
>> On Wed, Sep 9, 2015 at 12:07 PM, Dawid Weiss  wrote:
>>> This does look suspicious, Mike. Looks like interrupt() on
>>> testLiveMaxMergeCount somehow escaped and the next test started...
>>> I'll have to take a look at the code to see how (and if) this is
>>> possible. It shouldn't be.
>>>
>>> D.
>>>
>>> On Wed, Sep 9, 2015 at 12:02 PM, Michael McCandless
>>>  wrote:
 Spooky failure in TestConcurrentMergeScheduler.testLiveMaxMergeCount:
 it seems like IW.forceMerge failed to notice that in fact all merges
 had completed, so the calling thread waited forever for it to
 finish...

 But, in the "interrupting leaked threads", why is there a "still
 running" thread from a different test case (testTotalBytesSize)?

 Mike McCandless

 http://blog.mikemccandless.com


 On Wed, Sep 9, 2015 at 3:07 AM, Apache Jenkins Server
  wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/316/
>
> No tests ran.
>
> Build Log:
> [...truncated 53196 lines...]
> prepare-release-no-sign:
> [mkdir] Created dir: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
>  [copy] Copying 461 files to 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
>  [copy] Copying 245 files to 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
>[smoker] Java 1.7 
> JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
>[smoker] Java 1.8 
> JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
>[smoker] NOTE: output encoding is UTF-8
>[smoker]
>[smoker] Load release URL 
> "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/"...
>[smoker]
>[smoker] Test Lucene...
>[smoker]   test basics...
>[smoker]   get KEYS
>[smoker] 0.1 MB in 0.01 sec (11.6 MB/sec)
>[smoker]   check changes HTML...
>[smoker]   download lucene-5.4.0-src.tgz...
>[smoker] 28.5 MB in 0.04 sec (753.0 MB/sec)
>[smoker] verify md5/sha1 digests
>[smoker]   download lucene-5.4.0.tgz...
>[smoker] 65.9 MB in 0.09 sec (741.7 MB/sec)
>[smoker] verify md5/sha1 digests
>[smoker]   download lucene-5.4.0.zip...
>[smoker] 76.2 MB in 0.10 sec (763.7 MB/sec)
>[smoker] verify md5/sha1 digests
>[smoker]   unpack lucene-5.4.0.tgz...
>[smoker] verify JAR metadata/identity/no javax.* or java.* 
> classes...
>[smoker] test demo with 1.7...
>[smoker]   got 6104 hits for query "lucene"
>[smoker] checkindex with 1.7...
>[smoker] test demo with 1.8...
>[smoker]   got 6104 hits for query "lucene"
>[smoker] checkindex with 1.8...
>[smoker] check Lucene's javadoc JAR
>[smoker]   unpack lucene-5.4.0.zip...
>[smoker] verify JAR metadata/identity/no javax.* or java.* 
> classes...
>[smoker] test demo with 1.7...
>[smoker]   got 6104 hits for query "lucene"
>[smoker] checkindex with 1.7...
>[smoker] test demo with 1.8...
>[smoker]   got 6104 hits for query "lucene"
>[smoker] checkindex with 1.8...
>[smoker] check Lucene's javadoc JAR
>[smoker]   unpack lucene-5.4.0-src.tgz...
>[smoker] make sure no JARs/WARs in src dist...
>[smoker] run "ant validate"
>[smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
>[smoker] test demo with 1.7...
>[smoker]   got 212 hits for query "lucene"
>[smoker] checkindex with 1.7...
>[smoker] generate javadocs w/ Java 7...
>[smoker]
>[smoker] Crawl/parse...
>[smoker]
>[smoker] Verify...
>[smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
>[smoker]
>[smoker] command "export 
> 

[jira] [Commented] (SOLR-8081) When creating a collection, we need a way to utilize multiple disks available on a node.

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8081:
--

I would recommend adding the list of available disks for a solr node in 
solr.xml as follows

{code:xml}

  
  
/mount/point/disk1/data/dir
/mount/point/disk2/data/dir


{code}


and use something like {{maxReplicasPerDisk=n}} while creating a collection. So 
the node can decide where the datadir for the core would live

> When creating a collection, we need a way to utilize multiple disks available 
> on a node.
> 
>
> Key: SOLR-8081
> URL: https://issues.apache.org/jira/browse/SOLR-8081
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Timothy Potter
>
> Currently, if I want to change the dataDir for a core (such as to utilize 
> multiple disks on a Solr node), I need to either setup a symlink or change 
> the dataDir property in core.properties and restart the Solr node. For 
> instance, if I have a 4-node SolrCloud cluster and want to create a 
> collection with 4 shards with rf=2, then 8 Solr cores will be created across 
> the cluster, 2 per node. If I want to have each core use a separate disk, 
> then I have to do that after the fact. I'm aware that I could create the 
> collection with rf=1 and then use AddReplica to add additional replicas with 
> a different dataDir set, but that feels cumbersome as well.
> What would be nice is to have a way for me to specify available disks and 
> have Solr use that information when provisioning cores on the node. 
> [~anshumg] mentioned this might be best accomplished with a replica placement 
> strategy.



--
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-6812) Upgrade RandomizedTesting to 2.1.17

[Dawid Weiss (JIRA)]

Dawid Weiss created LUCENE-6812:
---

 Summary: Upgrade RandomizedTesting to 2.1.17
 Key: LUCENE-6812
 URL: https://issues.apache.org/jira/browse/LUCENE-6812
 Project: Lucene - Core
  Issue Type: Task
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Fix For: Trunk






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

[Suggester Component] Duplicate suggestions

[Alessandro Benedetti]

I am wondering why the Suggester component should return duplicate
suggestions.

Taking as an example a Suggester configured over fieldA with
the AnalyzingInfixLookupFactory, I will see in my results the entire stored
content for that field for all the documents, which means the possibility
of duplicates :

eg.

"Region":{
  "co":{
"numFound":10,
"suggestions":[{
"term":"Costa Blanca",
"weight":0,
"payload":""},
  {
"term":"Costa Blanca",
"weight":0,
"payload":""},
  {
"term":"Costa Smeralda",
"weight":0,
"payload":""},
  {
"term":"Costa Smeralda",
"weight":0,
"payload":""},

...


This sounds to me as redundant data, because when talking about
suggestions we are actually showing only the term ( so we have lost
any other attribute of the original document).

It's true we have the weight and payload that possibly could
differentiate the suggestions ( basically in the sorting or if any
payload present for term).

I am just curious what are the benefit of this duplication when we
could return a set of suggestions and avoid the client to do the extra
step of filtering duplicates ( usually you don't want to show
duplicates suggestion , that basically will produce the same search
when clicked.


Cheers

-- 
--

Benedetti Alessandro
Visiting card : http://about.me/alessandro_benedetti

"Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?"

William Blake - Songs of Experience -1794 England

[jira] [Commented] (SOLR-8078) Data driven solrconfig spellchecker refers to a non-existent field

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-8078:
-

Thinking aloud can merge the techproducts and data driven config sets?

- To use the {{techproducts}} example , the startup script can post the 
necessary fields using the schema APIs . So the example config has 
ManagedSchemaFactory 
- To use the {{schemaless}} example, the startup script can make sure that the 
{{add-unknown-fields-to-the-schema}} update chain is used. 
- We don't need a minimal config set , since all the extra fields in tech 
products is been added by the startup script and is not present otherwise.

[~steve_rowe] what do you think?

> Data driven solrconfig spellchecker refers to a non-existent field
> --
>
> Key: SOLR-8078
> URL: https://issues.apache.org/jira/browse/SOLR-8078
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>
> In the data driven solrconfig.xml file, the "default" spellchecker refers to 
> a field called "text" which doesn't exist in the schema.
> Even the "wordbreak" spellchecker refers to a field called "name" which does 
> not exist. 
> So when you run this query 
> {{http://localhost:8983/solr/gettingstarted/spell?q=*}} Solr will throw an 
> error. 
> I guess the field name should be {{\_text\_}} ?



--
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-8068) NPE in SolrDispatchFilter.authenticateRequest

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-8068:
-

I know, but it is vanilla 5.3.0 with and three patches are just concerned with 
facetting, highlighting and the querycomponent, i don't see how they can cause 
this. By the way, i cannot reproduce it anymore, not with the patched 5.3.0 or 
the vanilla 5.3.0, which i have tried just now.

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch, 
> solr-core-5.3.0-SNAPSHOT.jar
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {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-8068) NPE in SolrDispatchFilter.authenticateRequest

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8068:
--

I decompiled the class files from your jar and it does not really match with 
the 5.2.1 or 5.3.0 release line numbers. That's why I requested you if it is 
possible to reproduce it with one of the releases or an upcoming release.
Thanks for your patience

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch, 
> solr-core-5.3.0-SNAPSHOT.jar
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {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] [Created] (SOLR-8084) Original UI: Plugins/Stats "refresh values" link has problems in Microsoft browsers

[Shawn Heisey (JIRA)]

Shawn Heisey created SOLR-8084:
--

 Summary: Original UI: Plugins/Stats "refresh values" link has 
problems in Microsoft browsers
 Key: SOLR-8084
 URL: https://issues.apache.org/jira/browse/SOLR-8084
 Project: Solr
  Issue Type: Bug
  Components: UI, web gui
Affects Versions: 5.3
Reporter: Shawn Heisey


On the "Plugins/Stats" page, there is a "Refresh Values" link.

A user on the mailing list was having problems with this link going to the 
dashboard.

My testing on Windows 10 with 5.3.0 on the current UI showed Chrome and Firefox 
working properly.  That testing revealed problems in Microsoft browsers.  Edge 
returns to the dashboard as the user noticed.  IE11 throws up an error that 
says "404 Not Found get".  When that popup is dismissed, the right pane of the 
window is empty except for a constant spinning icon saying "Loading ...".

The Angular UI shows no problems in all four browsers.  I did not test with any 
others.




--
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-8084) Original UI: Plugins/Stats "refresh values" link has problems in Microsoft browsers

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-8084:
---
Description: 
On the "Plugins/Stats" page, there is a "Refresh Values" link.

A user on the mailing list was having problems with this link going to the 
dashboard.

My testing on Windows 10 with 5.3.0 on the current UI showed Firefox working 
properly, but Chrome and Microsoft browsers have problems.  Edge and Chrome 
return to the dashboard as the user noticed.  IE11 throws up an error that says 
"404 Not Found get".  When that popup is dismissed, the right pane of the 
window is empty except for a constant spinning icon saying "Loading ...".

The Angular UI shows no problems in all four browsers.  I did not test with any 
others.


  was:
On the "Plugins/Stats" page, there is a "Refresh Values" link.

A user on the mailing list was having problems with this link going to the 
dashboard.

My testing on Windows 10 with 5.3.0 on the current UI showed Chrome and Firefox 
working properly.  That testing revealed problems in Microsoft browsers.  Edge 
returns to the dashboard as the user noticed.  IE11 throws up an error that 
says "404 Not Found get".  When that popup is dismissed, the right pane of the 
window is empty except for a constant spinning icon saying "Loading ...".

The Angular UI shows no problems in all four browsers.  I did not test with any 
others.



> Original UI: Plugins/Stats "refresh values" link has problems in Microsoft 
> browsers
> ---
>
> Key: SOLR-8084
> URL: https://issues.apache.org/jira/browse/SOLR-8084
> Project: Solr
>  Issue Type: Bug
>  Components: UI, web gui
>Affects Versions: 5.3
>Reporter: Shawn Heisey
>
> On the "Plugins/Stats" page, there is a "Refresh Values" link.
> A user on the mailing list was having problems with this link going to the 
> dashboard.
> My testing on Windows 10 with 5.3.0 on the current UI showed Firefox working 
> properly, but Chrome and Microsoft browsers have problems.  Edge and Chrome 
> return to the dashboard as the user noticed.  IE11 throws up an error that 
> says "404 Not Found get".  When that popup is dismissed, the right pane of 
> the window is empty except for a constant spinning icon saying "Loading ...".
> The Angular UI shows no problems in all four browsers.  I did not test with 
> any others.



--
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-8084) Original UI: Plugins/Stats "refresh values" link has problems in Chrome and Microsoft browsers

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-8084:
---
Summary: Original UI: Plugins/Stats "refresh values" link has problems in 
Chrome and Microsoft browsers  (was: Original UI: Plugins/Stats "refresh 
values" link has problems in Microsoft browsers)

> Original UI: Plugins/Stats "refresh values" link has problems in Chrome and 
> Microsoft browsers
> --
>
> Key: SOLR-8084
> URL: https://issues.apache.org/jira/browse/SOLR-8084
> Project: Solr
>  Issue Type: Bug
>  Components: UI, web gui
>Affects Versions: 5.3
>Reporter: Shawn Heisey
>
> On the "Plugins/Stats" page, there is a "Refresh Values" link.
> A user on the mailing list was having problems with this link going to the 
> dashboard.
> My testing on Windows 10 with 5.3.0 on the current UI showed Firefox working 
> properly, but Chrome and Microsoft browsers have problems.  Edge and Chrome 
> return to the dashboard as the user noticed.  IE11 throws up an error that 
> says "404 Not Found get".  When that popup is dismissed, the right pane of 
> the window is empty except for a constant spinning icon saying "Loading ...".
> The Angular UI shows no problems in all four browsers.  I did not test with 
> any others.



--
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-6734) TestAutoPrefixTerms.testBinaryNumericRanges failure

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6734:


This failed again recently ... I'll fix.  I think it's a test bug.

> TestAutoPrefixTerms.testBinaryNumericRanges failure
> ---
>
> Key: LUCENE-6734
> URL: https://issues.apache.org/jira/browse/LUCENE-6734
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 5.3, Trunk, 5.4
>Reporter: Steve Rowe
>Assignee: Michael McCandless
>
> My Jenkins found the following seed on lucene_solr_5_3, but it also 
> reproduces on trunk and branch_5x: 
> {noformat}
>[junit4] Suite: org.apache.lucene.codecs.autoprefix.TestAutoPrefixTerms
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestAutoPrefixTerms -Dtests.method=testBinaryNumericRanges 
> -Dtests.seed=3B0E81E508A4A9 -Dtests.slow=true -Dtests.locale=es 
> -Dtests.timezone=Kwajalein -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 1.46s | TestAutoPrefixTerms.testBinaryNumericRanges <<<
>[junit4]> Throwable #1: java.lang.AssertionError: totTermCount=17 is > 
> allowedMaxTerms=16
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3B0E81E508A4A9:AE5C77E440454DBB]:0)
>[junit4]>  at 
> org.apache.lucene.codecs.autoprefix.TestAutoPrefixTerms$VerifyAutoPrefixTerms.finish(TestAutoPrefixTerms.java:577)
>[junit4]>  at 
> org.apache.lucene.codecs.autoprefix.TestAutoPrefixTerms.testBinaryNumericRanges(TestAutoPrefixTerms.java:318)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene53): {}, 
> docValues:{}, sim=RandomSimilarityProvider(queryNorm=true,coord=crazy): {}, 
> locale=es, timezone=Kwajalein
>[junit4]   2> NOTE: Mac OS X 10.10.4 x86_64/Oracle Corporation 1.8.0_20 
> (64-bit)/cpus=8,threads=1,free=207523744,total=257425408
>[junit4]   2> NOTE: All tests run in this JVM: [TestAutoPrefixTerms]
>[junit4] Completed [1/1] in 2.00s, 1 test, 1 failure <<< FAILURES!
> {noformat}



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

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

[jira] [Assigned] (LUCENE-6734) TestAutoPrefixTerms.testBinaryNumericRanges failure

[Michael McCandless (JIRA)]

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

Michael McCandless reassigned LUCENE-6734:
--

Assignee: Michael McCandless

> TestAutoPrefixTerms.testBinaryNumericRanges failure
> ---
>
> Key: LUCENE-6734
> URL: https://issues.apache.org/jira/browse/LUCENE-6734
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 5.3, Trunk, 5.4
>Reporter: Steve Rowe
>Assignee: Michael McCandless
>
> My Jenkins found the following seed on lucene_solr_5_3, but it also 
> reproduces on trunk and branch_5x: 
> {noformat}
>[junit4] Suite: org.apache.lucene.codecs.autoprefix.TestAutoPrefixTerms
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestAutoPrefixTerms -Dtests.method=testBinaryNumericRanges 
> -Dtests.seed=3B0E81E508A4A9 -Dtests.slow=true -Dtests.locale=es 
> -Dtests.timezone=Kwajalein -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 1.46s | TestAutoPrefixTerms.testBinaryNumericRanges <<<
>[junit4]> Throwable #1: java.lang.AssertionError: totTermCount=17 is > 
> allowedMaxTerms=16
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3B0E81E508A4A9:AE5C77E440454DBB]:0)
>[junit4]>  at 
> org.apache.lucene.codecs.autoprefix.TestAutoPrefixTerms$VerifyAutoPrefixTerms.finish(TestAutoPrefixTerms.java:577)
>[junit4]>  at 
> org.apache.lucene.codecs.autoprefix.TestAutoPrefixTerms.testBinaryNumericRanges(TestAutoPrefixTerms.java:318)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene53): {}, 
> docValues:{}, sim=RandomSimilarityProvider(queryNorm=true,coord=crazy): {}, 
> locale=es, timezone=Kwajalein
>[junit4]   2> NOTE: Mac OS X 10.10.4 x86_64/Oracle Corporation 1.8.0_20 
> (64-bit)/cpus=8,threads=1,free=207523744,total=257425408
>[junit4]   2> NOTE: All tests run in this JVM: [TestAutoPrefixTerms]
>[junit4] Completed [1/1] in 2.00s, 1 test, 1 failure <<< FAILURES!
> {noformat}



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

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

[jira] [Updated] (SOLR-8083) Convert the ZookeeperInfoServlet to a handler at /admin/zookeeper

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-8083:
-
Summary: Convert the ZookeeperInfoServlet to a handler at /admin/zookeeper  
 (was: Convert the ZookeeperInfoServlet to an handler at /admin/zookeeper )

> Convert the ZookeeperInfoServlet to a handler at /admin/zookeeper 
> --
>
> Key: SOLR-8083
> URL: https://issues.apache.org/jira/browse/SOLR-8083
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> There is no need to have an extra servlet for this purpose 
> By keeping this outside of Solr we cannot even secure it properly using the 
> security framework and now we have taken up a top level name called zookeeper 
> which cannot be used as a collection name



--
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-8078) Data driven solrconfig spellchecker refers to a non-existent field

[Erik Hatcher (JIRA)]

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

Erik Hatcher edited comment on SOLR-8078 at 9/22/15 12:47 PM:
--

I look forward to the day that we have the APIs complete enough to be able to 
have a minimal Solr starting "config" (it'd really be without config) and be 
able to script up to the data driven, tech products, example/files, 
example/films, etc.  I think that's the ideal goal here.

But pragmatically, I think switching to {{\_text\_}} for data driven spell 
checking is a reasonable fix to allow data driven to work out of the box with 
spell checking.


was (Author: ehatcher):
I look forward to the day that we have the APIs complete enough to be able to 
have a minimal Solr starting "config" (it'd really be without config) and be 
able to script up to the data driven, tech products, example/files, 
example/films, etc.  I think that's the ideal goal here.

But pragmatically, I think switching to `_text_` for data driven spell checking 
is a reasonable fix to allow data driven to work out of the box with spell 
checking.

> Data driven solrconfig spellchecker refers to a non-existent field
> --
>
> Key: SOLR-8078
> URL: https://issues.apache.org/jira/browse/SOLR-8078
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>
> In the data driven solrconfig.xml file, the "default" spellchecker refers to 
> a field called "text" which doesn't exist in the schema.
> Even the "wordbreak" spellchecker refers to a field called "name" which does 
> not exist. 
> So when you run this query 
> {{http://localhost:8983/solr/gettingstarted/spell?q=*}} Solr will throw an 
> error. 
> I guess the field name should be {{\_text\_}} ?



--
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-8078) Data driven solrconfig spellchecker refers to a non-existent field

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8078:
--

bq. But pragmatically, I think switching to {{\_text\_}} for data driven spell 
checking is a reasonable fix to allow data driven to work out of the box with 
spell checking.

+1

> Data driven solrconfig spellchecker refers to a non-existent field
> --
>
> Key: SOLR-8078
> URL: https://issues.apache.org/jira/browse/SOLR-8078
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>
> In the data driven solrconfig.xml file, the "default" spellchecker refers to 
> a field called "text" which doesn't exist in the schema.
> Even the "wordbreak" spellchecker refers to a field called "name" which does 
> not exist. 
> So when you run this query 
> {{http://localhost:8983/solr/gettingstarted/spell?q=*}} Solr will throw an 
> error. 
> I guess the field name should be {{\_text\_}} ?



--
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-6812) Upgrade RandomizedTesting to 2.1.17

[ASF subversion and git services (JIRA)]

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

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

Commit 1704600 from [~dawidweiss] in branch 'dev/trunk'
[ https://svn.apache.org/r1704600 ]

LUCENE-6812: Upgrade RandomizedTesting to 2.1.17

> Upgrade RandomizedTesting to 2.1.17
> ---
>
> Key: LUCENE-6812
> URL: https://issues.apache.org/jira/browse/LUCENE-6812
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: Trunk, 5.4
>
>




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