[jira] [Created] (SOLR-8403) EmbeddedSolrServer has broken sorting with functions and non-alphanumeric symbols in field names

[Vasiliy Bout (JIRA)]

Vasiliy Bout created SOLR-8403:
--

 Summary: EmbeddedSolrServer has broken sorting with functions and 
non-alphanumeric symbols in field names
 Key: SOLR-8403
 URL: https://issues.apache.org/jira/browse/SOLR-8403
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3.1
Reporter: Vasiliy Bout


We are trying to use EmbeddedSolrServer to test our Java code, that sends 
queries to Solr server.

We have a number of non-alphanumeric characters in field names in our schema, 
and such field names work fine for searching and sorting on both real Solr 
server (via HttpSolrClient) and on EmbeddedSolrServer.

But when we make search query that has functions in sort clause, real server 
handles these queries correctly while EmbeddedSolrServer throws exception.

Suppose, we have a field with name {{foo:bar}}. The following query works fine 
with both real server and EmbeddedSolrServer:
{code}
solrClient.query(new SolrQuery("*:*").addSort("foo:bar", SolrQuery.ORDER.desc));
{code}

But when we try to use functions in sort clause, exception is thrown by 
EmbeddedSolrServer (real server works correctly). For the following code:
{code}
solrClient.query(new SolrQuery("*:*").addSort("def(foo:bar,0)", 
SolrQuery.ORDER.desc));
{code}
we get the following exception:
{noformat}
org.apache.solr.common.SolrException: sort param could not be parsed as a 
query, and is not a field that exists in the index: def(foo:bar,0)
at 
org.apache.solr.search.QueryParsing.parseSortSpec(QueryParsing.java:348)
at org.apache.solr.search.QParser.getSort(QParser.java:247)
at 
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:185)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:251)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
at 
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:179)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
...
{noformat}

If we have a space character between function arguments:
{code}
solrClient.query(new SolrQuery("*:*").addSort("def(foo:bar, 0)", 
SolrQuery.ORDER.desc));
{code}
we get different exception:
{noformat}
org.apache.solr.common.SolrException: Can't determine a Sort Order (asc or 
desc) in sort spec 'def(foo:bar, 0) desc', pos=12
at 
org.apache.solr.search.QueryParsing.parseSortSpec(QueryParsing.java:329)
at org.apache.solr.search.QParser.getSort(QParser.java:247)
at 
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:185)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:251)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
at 
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:179)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
...
{noformat}

Anyway, we have our tests failing with correctly written code that works on 
real server. Please, make EmbeddedSolrServer to behave the same way as the real 
Solr server.



--
This message was sent by Atlassian 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-6629) Random 7200 seconds build timeouts / infinite loops in Lucene tests?

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6629:


Again?  http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/75411/

{noformat}
 [junit4] Suite: org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3
   [junit4]   2> 12? 11, 2015 2:18:40 ?? 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
   [junit4]   2> WARNING: Suite execution timed out: 
org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3
   [junit4]   2>1) Thread[id=11, 
name=TEST-TestBlockPostingsFormat3.test-seed#[45106F11E17A4109], 
state=RUNNABLE, group=TGRP-TestBlockPostingsFormat3]
   [junit4]   2> at 
org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next(SegmentTermsEnum.java:894)
   [junit4]   2> at 
org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.assertTermsSeeking(TestBlockPostingsFormat3.java:211)
   [junit4]   2> at 
org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.assertTerms(TestBlockPostingsFormat3.java:180)
   [junit4]   2> at 
org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.verify(TestBlockPostingsFormat3.java:153)
   [junit4]   2> at 
org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.test(TestBlockPostingsFormat3.java:145)
   [junit4]   2> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
   [junit4]   2> at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   [junit4]   2> at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]   2> at java.lang.reflect.Method.invoke(Method.java:606)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
   [junit4]   2> at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
   [junit4]   2> at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4]   2> at 

[jira] [Resolved] (SOLR-8305) replace LatLonType.getValueSource's QParser use

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-8305.
---
   Resolution: Fixed
Fix Version/s: 5.5
   Trunk

> replace LatLonType.getValueSource's QParser use
> ---
>
> Key: SOLR-8305
> URL: https://issues.apache.org/jira/browse/SOLR-8305
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: Trunk, 5.5
>
> Attachments: SOLR-8305.patch, SOLR-8305.patch
>
>
> Question with patch against trunk. Context is that elsewhere in the classes 
> the {{IndexSchema}} member is used instead of the {{QParser}} method 
> parameter and would the resulting schema not be the same when using the 
> member instead of the parameter? Motivation here is potential removal of the 
> QParser argument from the {{getValueSource}} signature.



--
This message was sent by Atlassian 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-8404) tweak SolrQueryResponse.getToLogAsString(String logid)

[Christine Poerschke (JIRA)]

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

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

> tweak SolrQueryResponse.getToLogAsString(String logid)
> --
>
> Key: SOLR-8404
> URL: https://issues.apache.org/jira/browse/SOLR-8404
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8404.patch
>
>
> Whilst extending {{TestSolrQueryResponse}} in SOLR-8388 I noticed that 
> {{getToLogAsString(String logid)}} returns {{"logidname1=value1 name2=value2 
> ... "}} instead of the {{"logid name1=value1 name2=value2 ..."}} indicated by 
> its comment.
> summary of changes in patch against trunk:
> * Added space separator between {{logid}} and {{toLog}} values.
> * Removed trailing space at the end.
> * Added {{TestSolrQueryResponse.testToLog}} test case.
> * Reviewed callers of the method and adjusted call arg for two of them.



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

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

[jira] [Updated] (SOLR-8402) Authentication Setting in admin UI interface

[Nisha (JIRA)]

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

Nisha updated SOLR-8402:

Summary: Authentication Setting in admin UI interface  (was: Authtication 
Setting in admin UI interface)

> Authentication Setting in admin UI interface
> 
>
> Key: SOLR-8402
> URL: https://issues.apache.org/jira/browse/SOLR-8402
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - php
>Affects Versions: 5.3
> Environment: linux
>Reporter: Nisha
>
> Hi,
> I have installed solr 5.3 version. I want to add authentication to my admin 
> UI interface.
> I am not getting any way to add this authetication.
> P.S: My solr is not on cloud.
> Thanks,
> Nisha



--
This message was sent by Atlassian 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-8383) SolrCore.java + QParserPlugin.java container initialCapacity tweaks

[ASF subversion and git services (JIRA)]

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

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

Commit 1719342 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1719342 ]

SOLR-8383: SolrCore.java + QParserPlugin.java container initialCapacity tweaks

> SolrCore.java + QParserPlugin.java container initialCapacity tweaks
> ---
>
> Key: SOLR-8383
> URL: https://issues.apache.org/jira/browse/SOLR-8383
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8383.patch, SOLR-8383.patch
>
>
> patch against trunk to follow



--
This message was sent by Atlassian 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 # 75411 - Failure!

[Michael McCandless]

Looks like the crazy random 7200 second test time bug again ... I'll add
this to https://issues.apache.org/jira/browse/LUCENE-6629

Mike McCandless

On Thu, Dec 10, 2015 at 9:19 PM,  wrote:

> *BUILD FAILURE*
> Build URL
> http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/75411/
> Project:lucene_linux_java8_64_test_only Randomization: 
> JDKO7,local,heap[572m],-server
> +UseConcMarkSweepGC +UseCompressedOops,sec manager on Date of build:Fri,
> 11 Dec 2015 01:18:22 +0100 Build duration:2 hr 0 min
> *CHANGES* No Changes
> *BUILD ARTIFACTS*
> -
> checkout/lucene/build/core/test/temp/junit4-J0-20151211_011840_040.events
> 
> -
> checkout/lucene/build/core/test/temp/junit4-J1-20151211_011840_040.events
> 
> -
> checkout/lucene/build/core/test/temp/junit4-J2-20151211_011840_041.events
> 
> -
> checkout/lucene/build/core/test/temp/junit4-J3-20151211_011840_042.events
> 
> -
> checkout/lucene/build/core/test/temp/junit4-J4-20151211_011840_041.events
> 
> -
> checkout/lucene/build/core/test/temp/junit4-J5-20151211_011840_041.events
> 
> -
> checkout/lucene/build/core/test/temp/junit4-J6-20151211_011840_042.events
> 
> -
> checkout/lucene/build/core/test/temp/junit4-J7-20151211_011840_042.events
> 
> *FAILED JUNIT TESTS* Name: junit.framework Failed: 1 test(s), Passed: 0
> test(s), Skipped: 0 test(s), Total: 1 test(s)
> *- Failed:
> junit.framework.TestSuite.org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3
> * Name: org.apache.lucene.codecs.lucene50 Failed: 1 test(s), Passed: 144
> test(s), Skipped: 2 test(s), Total: 147 test(s)
> *- Failed: org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.test
> *
> *CONSOLE OUTPUT* [...truncated 2095 lines...] [junit4] -
> org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.test [junit4]
> - org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3 (suite) [junit4]
> [junit4] [junit4] JVM J0: 0.47 .. 121.57 = 121.10s [junit4] JVM J1: 0.60
> .. 121.51 = 120.92s [junit4] JVM J2: 0.54 .. 119.73 = 119.20s [junit4]
> JVM J3: 0.58 .. 126.21 = 125.63s [junit4] JVM J4: 0.51 .. 121.58 = 121.08s 
> [junit4]
> JVM J5: 0.47 .. 120.19 = 119.71s [junit4] JVM J6: 0.50 .. 7224.53 =
> 7224.03s [junit4] JVM J7: 0.63 .. 123.99 = 123.36s [junit4] Execution
> time total: 2 hours 24 seconds [junit4] Tests summary: 414 suites (1
> ignored), 3344 tests, 1 suite-level error, 1 error, 202 ignored (43
> assumptions) BUILD FAILED 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:50:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1456:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1010:
> There were test failures: 414 suites (1 ignored), 3344 tests, 1 suite-level
> error, 1 error, 202 ignored (43 assumptions) [seed: 45106F11E17A4109] Total
> time: 120 minutes 33 seconds Build step 'Invoke Ant' marked build as
> failure Archiving artifacts Recording test results [description-setter]
> Description set: JDKO7,local,heap[572m],-server +UseConcMarkSweepGC
> +UseCompressedOops,sec manager on Email was triggered for: Failure - 1st 
> Trigger
> Failure - Any was overridden by another trigger and will not send an email. 
> Trigger
> Failure - Still was overridden by another trigger and will not send an
> email. Sending email for trigger: Failure - 1st
>

[jira] [Resolved] (SOLR-8402) Authentication Setting in admin UI interface

[Upayavira (JIRA)]

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

Upayavira resolved SOLR-8402.
-
Resolution: Not A Problem

Nisha, please ask this question on the solr-user mailing list. JIRA is for bug 
reports or improvements, not for support (see here for details of solr-user 
http://lucene.apache.org/solr/resources.html). If after that you have found a 
bug or feature enhancement, please create a JIRA ticket.

Thanks!

> Authentication Setting in admin UI interface
> 
>
> Key: SOLR-8402
> URL: https://issues.apache.org/jira/browse/SOLR-8402
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - php
>Affects Versions: 5.3
> Environment: linux
>Reporter: Nisha
>
> Hi,
> I have installed solr 5.3 version. I want to add authentication to my admin 
> UI interface.
> I am not getting any way to add this authetication.
> P.S: My solr is not on cloud.
> Thanks,
> Nisha



--
This message was sent by Atlassian 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-Linux (64bit/jdk1.8.0_66) - Build # 14869 - Failure!

[Policeman Jenkins Server]

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

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

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

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


FAILED:  org.apache.solr.cloud.HttpPartitionTest.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([F45E6C56963748CF]:0)




Build Log:
[...truncated 11615 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.HttpPartitionTest_F45E6C56963748CF-001/init-core-data-001
   [junit4]   2> 1114936 INFO  
(SUITE-HttpPartitionTest-seed#[F45E6C56963748CF]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /ut/nh
   [junit4]   2> 1114938 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1114938 INFO  (Thread-4115) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1114938 INFO  (Thread-4115) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1115038 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.ZkTestServer start zk server on port:43506
   [junit4]   2> 1115038 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1115038 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1115040 INFO  (zkCallback-1458-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@25905523 
name:ZooKeeperConnection Watcher:127.0.0.1:43506 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 1115040 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1115040 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 1115040 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 1115042 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1115044 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1115044 INFO  (zkCallback-1459-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@69a2d954 
name:ZooKeeperConnection Watcher:127.0.0.1:43506/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 1115044 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1115044 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 1115044 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1
   [junit4]   2> 1115045 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1/shards
   [junit4]   2> 1115045 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection
   [junit4]   2> 1115046 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection/shards
   [junit4]   2> 1115046 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.AbstractZkTestCase put 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 1115046 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.c.SolrZkClient makePath: /configs/conf1/solrconfig.xml
   [junit4]   2> 1115047 INFO  
(TEST-HttpPartitionTest.test-seed#[F45E6C56963748CF]) [] 
o.a.s.c.AbstractZkTestCase put 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/test-files/solr/collection1/conf/schema.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 1115047 INFO  

[jira] [Created] (SOLR-8402) Authtication Setting in admin UI interface

[Nisha (JIRA)]

Nisha created SOLR-8402:
---

 Summary: Authtication Setting in admin UI interface
 Key: SOLR-8402
 URL: https://issues.apache.org/jira/browse/SOLR-8402
 Project: Solr
  Issue Type: Improvement
  Components: clients - php
Affects Versions: 5.3
 Environment: linux
Reporter: Nisha


Hi,

I have installed solr 5.3 version. I want to add authentication to my admin UI 
interface.

I am not getting any way to add this authetication.

P.S: My solr is not on cloud.

Thanks,
Nisha



--
This message was sent by Atlassian 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-8404) tweak SolrQueryResponse.getToLogAsString(String logid)

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-8404:
-

 Summary: tweak SolrQueryResponse.getToLogAsString(String logid)
 Key: SOLR-8404
 URL: https://issues.apache.org/jira/browse/SOLR-8404
 Project: Solr
  Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor


Whilst extending {{TestSolrQueryResponse}} in SOLR-8388 I noticed that 
{{getToLogAsString(String logid)}} returns {{"logidname1=value1 name2=value2 
... "}} instead of the {{"logid name1=value1 name2=value2 ..."}} indicated by 
its comment.

summary of changes in patch against trunk:
* Added space separator between {{logid}} and {{toLog}} values.
* Removed trailing space at the end.
* Added {{TestSolrQueryResponse.testToLog}} test case.
* Reviewed callers of the method and adjusted call arg for two of them.



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

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

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

[Apache Jenkins Server]

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

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

Error Message:
expected:<[{indexVersion=1449825644507,generation=2,filelist=[_2njz.fdt, 
_2njz.fdx, _2njz.fnm, _2njz.nvd, _2njz.nvm, _2njz.si, _2njz_MockRandom_0.doc, 
_2njz_MockRandom_0.sd, _2njz_MockRandom_0.tbk, _2njz_MockRandom_0.tix, 
_2nve.cfe, _2nve.cfs, _2nve.si, _2nvh.fdt, _2nvh.fdx, _2nvh.fnm, _2nvh.nvd, 
_2nvh.nvm, _2nvh.si, _2nvh_MockRandom_0.doc, _2nvh_MockRandom_0.sd, 
_2nvh_MockRandom_0.tib, _2nvh_MockRandom_0.tii, _2nvn.cfe, _2nvn.cfs, _2nvn.si, 
_2nvp.fdt, _2nvp.fdx, _2nvp.fnm, _2nvp.nvd, _2nvp.nvm, _2nvp.si, 
_2nvp_MockRandom_0.doc, _2nvp_MockRandom_0.sd, _2nvp_MockRandom_0.tim, 
_2nvp_MockRandom_0.tip, _2nvq.cfe, _2nvq.cfs, _2nvq.si, _2nvr.fdt, _2nvr.fdx, 
_2nvr.fnm, _2nvr.nvd, _2nvr.nvm, _2nvr.si, _2nvr_MockRandom_0.doc, 
_2nvr_MockRandom_0.sd, _2nvr_MockRandom_0.tbk, _2nvr_MockRandom_0.tix, 
_2nwm.fdt, _2nwm.fdx, _2nwm.fnm, _2nwm.nvd, _2nwm.nvm, _2nwm.si, 
_2nwm_MockRandom_0.doc, _2nwm_MockRandom_0.sd, _2nwm_MockRandom_0.tmp, 
_2nwp.cfe, _2nwp.cfs, _2nwp.si, _2nwq.fdt, _2nwq.fdx, _2nwq.fnm, _2nwq.nvd, 
_2nwq.nvm, _2nwq.si, _2nwq_MockRandom_0.doc, _2nwq_MockRandom_0.sd, 
_2nwq_MockRandom_0.tbk, _2nwq_MockRandom_0.tix, _2nwr.fdt, _2nwr.fdx, 
_2nwr.fnm, _2nwr.nvd, _2nwr.nvm, _2nwr.si, _2nwr_MockRandom_0.doc, 
_2nwr_MockRandom_0.sd, _2nwr_MockRandom_0.tio, _2nwr_MockRandom_0.tipo, 
_2nws.fdt, _2nws.fdx, _2nws.fnm, _2nws.nvd, _2nws.nvm, _2nws.si, 
_2nws_MockRandom_0.doc, _2nws_MockRandom_0.sd, _2nws_MockRandom_0.tio, 
_2nws_MockRandom_0.tipo, _2nwu.fdt, _2nwu.fdx, _2nwu.fnm, _2nwu.nvd, _2nwu.nvm, 
_2nwu.si, _2nwu_MockRandom_0.doc, _2nwu_MockRandom_0.sd, 
_2nwu_MockRandom_0.tim, _2nwu_MockRandom_0.tip, _2nwx.fdt, _2nwx.fdx, 
_2nwx.fnm, _2nwx.nvd, _2nwx.nvm, _2nwx.si, _2nwx_MockRandom_0.doc, 
_2nwx_MockRandom_0.sd, _2nwx_MockRandom_0.tio, _2nwx_MockRandom_0.tipo, 
_2nx1.fdt, _2nx1.fdx, _2nx1.fnm, _2nx1.nvd, _2nx1.nvm, _2nx1.si, 
_2nx1_MockRandom_0.doc, _2nx1_MockRandom_0.sd, _2nx1_MockRandom_0.tmp, 
_2nx2.fdt, _2nx2.fdx, _2nx2.fnm, _2nx2.nvd, _2nx2.nvm, _2nx2.si, 
_2nx2_MockRandom_0.doc, _2nx2_MockRandom_0.sd, _2nx2_MockRandom_0.tib, 
_2nx2_MockRandom_0.tiv, _2nx3.cfe, _2nx3.cfs, _2nx3.si, _2nx4.fdt, _2nx4.fdx, 
_2nx4.fnm, _2nx4.nvd, _2nx4.nvm, _2nx4.si, _2nx4_MockRandom_0.doc, 
_2nx4_MockRandom_0.sd, _2nx4_MockRandom_0.tbk, _2nx4_MockRandom_0.tix, 
_2nx5.fdt, _2nx5.fdx, _2nx5.fnm, _2nx5.nvd, _2nx5.nvm, _2nx5.si, 
_2nx5_MockRandom_0.doc, _2nx5_MockRandom_0.sd, _2nx5_MockRandom_0.tmp, 
_2nx6.fdt, _2nx6.fdx, _2nx6.fnm, _2nx6.nvd, _2nx6.nvm, _2nx6.si, 
_2nx6_MockRandom_0.doc, _2nx6_MockRandom_0.sd, _2nx6_MockRandom_0.tib, 
_2nx6_MockRandom_0.tii, _2nx7.fdt, _2nx7.fdx, _2nx7.fnm, _2nx7.nvd, _2nx7.nvm, 
_2nx7.si, _2nx7_MockRandom_0.doc, _2nx7_MockRandom_0.sd, 
_2nx7_MockRandom_0.tbk, _2nx7_MockRandom_0.tix, _2nx8.fdt, _2nx8.fdx, 
_2nx8.fnm, _2nx8.nvd, _2nx8.nvm, _2nx8.si, _2nx8_MockRandom_0.doc, 
_2nx8_MockRandom_0.sd, _2nx8_MockRandom_0.tbk, _2nx8_MockRandom_0.tix, 
_2nx9.cfe, _2nx9.cfs, _2nx9.si, _2nxa.fdt, _2nxa.fdx, _2nxa.fnm, _2nxa.nvd, 
_2nxa.nvm, _2nxa.si, _2nxa_MockRandom_0.doc, _2nxa_MockRandom_0.sd, 
_2nxa_MockRandom_0.tio, _2nxa_MockRandom_0.tipo, _2nxb.fdt, _2nxb.fdx, 
_2nxb.fnm, _2nxb.nvd, _2nxb.nvm, _2nxb.si, _2nxb_MockRandom_0.doc, 
_2nxb_MockRandom_0.sd, _2nxb_MockRandom_0.tmp, _2nxc.fdt, _2nxc.fdx, _2nxc.fnm, 
_2nxc.nvd, _2nxc.nvm, _2nxc.si, _2nxc_MockRandom_0.doc, _2nxc_MockRandom_0.sd, 
_2nxc_MockRandom_0.tio, _2nxc_MockRandom_0.tipo, _2nxd.fdt, _2nxd.fdx, 
_2nxd.fnm, _2nxd.nvd, _2nxd.nvm, _2nxd.si, _2nxd_MockRandom_0.doc, 
_2nxd_MockRandom_0.sd, _2nxd_MockRandom_0.tim, _2nxd_MockRandom_0.tip, 
_2nxe.fdt, _2nxe.fdx, _2nxe.fnm, _2nxe.nvd, _2nxe.nvm, _2nxe.si, 
_2nxe_MockRandom_0.doc, _2nxe_MockRandom_0.sd, _2nxe_MockRandom_0.tbk, 
_2nxe_MockRandom_0.tix, _2nxf.fdt, _2nxf.fdx, _2nxf.fnm, _2nxf.nvd, _2nxf.nvm, 
_2nxf.si, _2nxf_MockRandom_0.doc, _2nxf_MockRandom_0.sd, 
_2nxf_MockRandom_0.tmp, _2nxh.fdt, _2nxh.fdx, _2nxh.fnm, _2nxh.nvd, _2nxh.nvm, 
_2nxh.si, _2nxh_MockRandom_0.doc, _2nxh_MockRandom_0.sd, 
_2nxh_MockRandom_0.tim, _2nxh_MockRandom_0.tip, _2nxi.fdt, _2nxi.fdx, 
_2nxi.fnm, _2nxi.nvd, _2nxi.nvm, _2nxi.si, _2nxi_MockRandom_0.doc, 
_2nxi_MockRandom_0.sd, _2nxi_MockRandom_0.tim, _2nxi_MockRandom_0.tip, 
_2nxj.fdt, _2nxj.fdx, _2nxj.fnm, _2nxj.nvd, _2nxj.nvm, _2nxj.si, 
_2nxj_MockRandom_0.doc, _2nxj_MockRandom_0.sd, _2nxj_MockRandom_0.tib, 
_2nxj_MockRandom_0.tii, _2nxk.fdt, _2nxk.fdx, _2nxk.fnm, _2nxk.nvd, _2nxk.nvm, 
_2nxk.si, _2nxk_MockRandom_0.doc, _2nxk_MockRandom_0.sd, 
_2nxk_MockRandom_0.tim, _2nxk_MockRandom_0.tip, segments_2]}]> but 
was:<[{indexVersion=1449825644507,generation=2,filelist=[_2njz.fdt, _2njz.fdx, 
_2njz.fnm, _2njz.nvd, _2njz.nvm, _2njz.si, _2njz_MockRandom_0.doc, 
_2njz_MockRandom_0.sd, _2njz_MockRandom_0.tbk, _2njz_MockRandom_0.tix, 
_2nve.cfe, _2nve.cfs, _2nve.si, _2nvh.fdt, 

[jira] [Comment Edited] (SOLR-7904) Make FacetStream Expressible

[Dennis Gove (JIRA)]

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

Dennis Gove edited comment on SOLR-7904 at 12/11/15 2:15 PM:
-

Alright. The expression parsing is similar to CloudSolrStream whereby some 
named parameters are required (buckets, bucketSorts, bucketSizeLimit) but the 
others are just passed down to the QueryRequest and are not considered 
explicitly. If fl and sort are not required then it'd just be a change in the 
documentation and not an implementation change (since the expression parsing 
doesn't explicitly look to ensure those were provided).


was (Author: dpgove):
Alright. The expression parsing in similar to CloudSolrStream whereby some 
named parameters are required (buckets, bucketSorts, bucketSizeLimit) but the 
others are just passed down to the QueryRequest and are not considered 
explicitly. If fl and sort are not required then it'd just be a change in the 
documentation and not an implementation change (since the expression parsing 
doesn't explicitly look to ensure those were provided).

> Make FacetStream Expressible
> 
>
> Key: SOLR-7904
> URL: https://issues.apache.org/jira/browse/SOLR-7904
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Joel Bernstein
> Fix For: Trunk
>
>
> This ticket makes the FacetStream (SOLR-7903) expressible, so it can be used 
> as a Streaming Expression.



--
This message was sent by Atlassian 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-7904) Make FacetStream Expressible

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-7904:
--

Yeah, the FacetStream flattens out the hierarchical params of the JSON facet 
API. This works pretty well for SQL group by queries. But not nearly as 
expressive as the JSON facet API. But I think it's OK for version 1. 

> Make FacetStream Expressible
> 
>
> Key: SOLR-7904
> URL: https://issues.apache.org/jira/browse/SOLR-7904
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Joel Bernstein
> Fix For: Trunk
>
>
> This ticket makes the FacetStream (SOLR-7903) expressible, so it can be used 
> as a Streaming Expression.



--
This message was sent by Atlassian 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-7904) Make FacetStream Expressible

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-7904:
---

I did consider an alternative format that would put the bucket options together 
and allow for different things in each bucket but steered away from it because 
it would require larger changes to the FacetStream implementation and may not 
have a usecase

{code}
facet(
  collection1,
  q="*:*",
  fl="a_s,b_s,a_i,a_f",
  sort="a_s asc",
  bucket("a_s", sort="sum(a_i) asc", limit=5, sum(a_i), avg(a_i), count(*)),
  bucket("b_s", sort="max(a_i) desc, min(a_i) desc", limit=20, sum(a_i), 
min(a_i), max(a_i)),
)
{code}

> Make FacetStream Expressible
> 
>
> Key: SOLR-7904
> URL: https://issues.apache.org/jira/browse/SOLR-7904
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Joel Bernstein
> Fix For: Trunk
>
>
> This ticket makes the FacetStream (SOLR-7903) expressible, so it can be used 
> as a Streaming Expression.



--
This message was sent by Atlassian 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-7904) Make FacetStream Expressible

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-7904:
--

I'll take a look again at the FacetStream impl. I think the *fl* and *sort* 
parameters are not needed. The StreamingTests have these params, but I think 
they were just pasted from another test. So this should work:

{code}
facet(
  collection1,
  q="*:*",
  buckets="a_s",
  bucketSorts="sum(a_i) asc",
  bucketSizeLimit=10,
  sum(a_i), sum(a_f),
  min(a_i), min(a_f),
  max(a_i), max(a_f),
  avg(a_i), avg(a_f),
  count(*),
  zkHost="url:port"
)

{code}

> Make FacetStream Expressible
> 
>
> Key: SOLR-7904
> URL: https://issues.apache.org/jira/browse/SOLR-7904
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Joel Bernstein
> Fix For: Trunk
>
>
> This ticket makes the FacetStream (SOLR-7903) expressible, so it can be used 
> as a Streaming Expression.



--
This message was sent by Atlassian 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-8403) EmbeddedSolrServer has broken sorting with functions and non-alphanumeric symbols in field names

[Shawn Heisey (JIRA)]

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

Shawn Heisey closed SOLR-8403.
--
Resolution: Not A Problem

This is not considered a bug.  We see your schema as badly configured.  I am 
closing this issue.  The following has been the official recommendation 
regarding field names for quite some time:

bq. field names should consist of alphanumeric or underscore characters only 
and not start with a digit. This is not currently strictly enforced, but other 
field names will not have first class support from all components and back 
compatibility is not guaranteed.

Future plans for Solr include enforcing these restrictions, which will cause 
Solr to fail when it tries to load your schema configuration.  See SOLR-8110.

> EmbeddedSolrServer has broken sorting with functions and non-alphanumeric 
> symbols in field names
> 
>
> Key: SOLR-8403
> URL: https://issues.apache.org/jira/browse/SOLR-8403
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3.1
>Reporter: Vasiliy Bout
>  Labels: embedded, sorting
>
> We are trying to use EmbeddedSolrServer to test our Java code, that sends 
> queries to Solr server.
> We have a number of non-alphanumeric characters in field names in our schema, 
> and such field names work fine for searching and sorting on both real Solr 
> server (via HttpSolrClient) and on EmbeddedSolrServer.
> But when we make search query that has functions in sort clause, real server 
> handles these queries correctly while EmbeddedSolrServer throws exception.
> Suppose, we have a field with name {{foo:bar}}. The following query works 
> fine with both real server and EmbeddedSolrServer:
> {code}
> solrClient.query(new SolrQuery("*:*").addSort("foo:bar", 
> SolrQuery.ORDER.desc));
> {code}
> But when we try to use functions in sort clause, exception is thrown by 
> EmbeddedSolrServer (real server works correctly). For the following code:
> {code}
> solrClient.query(new SolrQuery("*:*").addSort("def(foo:bar,0)", 
> SolrQuery.ORDER.desc));
> {code}
> we get the following exception:
> {noformat}
> org.apache.solr.common.SolrException: sort param could not be parsed as a 
> query, and is not a field that exists in the index: def(foo:bar,0)
>   at 
> org.apache.solr.search.QueryParsing.parseSortSpec(QueryParsing.java:348)
>   at org.apache.solr.search.QParser.getSort(QParser.java:247)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:185)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:251)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
>   at 
> org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:179)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
>   at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
>   at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
>   ...
> {noformat}
> If we have a space character between function arguments:
> {code}
> solrClient.query(new SolrQuery("*:*").addSort("def(foo:bar, 0)", 
> SolrQuery.ORDER.desc));
> {code}
> we get different exception:
> {noformat}
> org.apache.solr.common.SolrException: Can't determine a Sort Order (asc or 
> desc) in sort spec 'def(foo:bar, 0) desc', pos=12
>   at 
> org.apache.solr.search.QueryParsing.parseSortSpec(QueryParsing.java:329)
>   at org.apache.solr.search.QParser.getSort(QParser.java:247)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:185)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:251)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
>   at 
> org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:179)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
>   at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
>   at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
>   ...
> {noformat}
> Anyway, we have our tests failing with correctly written code that works on 
> real server. Please, make EmbeddedSolrServer to behave the same way as the 
> real Solr server.



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

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

[jira] [Commented] (SOLR-7904) Make FacetStream Expressible

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-7904:
---

Alright. The expression parsing in similar to CloudSolrStream whereby some 
named parameters are required (buckets, bucketSorts, bucketSizeLimit) but the 
others are just passed down to the QueryRequest and are not considered 
explicitly. If fl and sort are not required then it'd just be a change in the 
documentation and not an implementation change (since the expression parsing 
doesn't explicitly look to ensure those were provided).

> Make FacetStream Expressible
> 
>
> Key: SOLR-7904
> URL: https://issues.apache.org/jira/browse/SOLR-7904
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Joel Bernstein
> Fix For: Trunk
>
>
> This ticket makes the FacetStream (SOLR-7903) expressible, so it can be used 
> as a Streaming Expression.



--
This message was sent by Atlassian 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-7904) Make FacetStream Expressible

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-7904:
--

Also the result set is flattened to mimic the results of a SQL group by query. 

> Make FacetStream Expressible
> 
>
> Key: SOLR-7904
> URL: https://issues.apache.org/jira/browse/SOLR-7904
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Joel Bernstein
> Fix For: Trunk
>
>
> This ticket makes the FacetStream (SOLR-7903) expressible, so it can be used 
> as a Streaming Expression.



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

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

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

[Policeman Jenkins Server]

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

11 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.CollectionReloadTest

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

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


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

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 30 
seconds
at 
__randomizedtesting.SeedInfo.seed([5A66718C5175F0:880E59AB22AD1808]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:175)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:837)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1393)
at 
org.apache.solr.cloud.AliasIntegrationTest.test(AliasIntegrationTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-6925) add (test-framework) [Random]ForceMergePolicy classes

[ASF subversion and git services (JIRA)]

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

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

Commit 1719471 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1719471 ]

LUCENE-6925: add ForceMergePolicy class in lucene test-framework and 
RandomForceMergePolicy class in solr test-framework, plus 
Test[Random]ForceMergePolicy test classes. (merge in revision 1719449 from 
trunk)

> add (test-framework) [Random]ForceMergePolicy classes
> -
>
> Key: LUCENE-6925
> URL: https://issues.apache.org/jira/browse/LUCENE-6925
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: LUCENE-6925.patch
>
>
> lucene changes:
>  * {{ForceMergePolicy}} for disallowing background segment merges but 
> permitting optimize/forceMerge segment merges
>  * {{TestForceMergePolicy}}
> solr changes:
>  * {{RandomForceMergePolicy}} extending {{RandomMergePolicy}}
>  * {{TestRandomForceMergePolicy}}
> motivation:
>  * test cases e.g. for SOLR-5730 may wish to distinguish before-merge and 
> after-merge query results or behaviour



--
This message was sent by Atlassian 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/jdk-9-ea+95) - Build # 15168 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15168/
Java: 64bit/jdk-9-ea+95 -XX:+UseCompressedOops -XX:+UseG1GC -XX:-CompactStrings

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest: 1) Thread[id=6255, 
name=zkCallback-624-thread-2, state=TIMED_WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1082)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)2) Thread[id=5994, 
name=TEST-CollectionsAPIDistributedZkTest.test-seed#[6205300F47685E50]-EventThread,
 state=WAITING, group=TGRP-CollectionsAPIDistributedZkTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:178) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2061)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:494)
3) Thread[id=5995, name=zkCallback-624-thread-1, state=TIMED_WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1082)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)4) Thread[id=5993, 
name=TEST-CollectionsAPIDistributedZkTest.test-seed#[6205300F47685E50]-SendThread(127.0.0.1:36385),
 state=TIMED_WAITING, group=TGRP-CollectionsAPIDistributedZkTest] at 
java.lang.Thread.sleep(Native Method) at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:994)5) 
Thread[id=6256, name=zkCallback-624-thread-3, state=TIMED_WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1082)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.CollectionsAPIDistributedZkTest: 
   1) Thread[id=6255, name=zkCallback-624-thread-2, state=TIMED_WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest]
at jdk.internal.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218)
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:461)
at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1082)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632)
at java.lang.Thread.run(Thread.java:747)
   2) Thread[id=5994, 

[jira] [Commented] (LUCENE-6815) Should DisjunctionScorer advance more lazily?

[ASF subversion and git services (JIRA)]

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

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

Commit 1719470 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1719470 ]

LUCENE-6815: Make DisjunctionScorer advance lazily.

> Should DisjunctionScorer advance more lazily?
> -
>
> Key: LUCENE-6815
> URL: https://issues.apache.org/jira/browse/LUCENE-6815
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6815.patch, LUCENE-6815.patch, LUCENE-6815.patch
>
>
> Today if you call DisjunctionScorer.advance(X), it will try to advance all 
> sub scorers to X. However, if DisjunctionScorer is being intersected with 
> another scorer (which is almost always the case as we use BooleanScorer for 
> top-level disjunctions), we could stop as soon as we find one matching sub 
> scorer, and only advance the remaining sub scorers when freq() or score() is 
> called. 



--
This message was sent by Atlassian 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-6925) add (test-framework) [Random]ForceMergePolicy classes

[ASF subversion and git services (JIRA)]

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

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

Commit 1719449 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1719449 ]

LUCENE-6925: add ForceMergePolicy class in lucene test-framework and 
RandomForceMergePolicy class in solr test-framework, plus 
Test[Random]ForceMergePolicy test classes.

> add (test-framework) [Random]ForceMergePolicy classes
> -
>
> Key: LUCENE-6925
> URL: https://issues.apache.org/jira/browse/LUCENE-6925
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: LUCENE-6925.patch
>
>
> lucene changes:
>  * {{ForceMergePolicy}} for disallowing background segment merges but 
> permitting optimize/forceMerge segment merges
>  * {{TestForceMergePolicy}}
> solr changes:
>  * {{RandomForceMergePolicy}} extending {{RandomMergePolicy}}
>  * {{TestRandomForceMergePolicy}}
> motivation:
>  * test cases e.g. for SOLR-5730 may wish to distinguish before-merge and 
> after-merge query results or behaviour



--
This message was sent by Atlassian 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_66) - Build # 5334 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5334/
Java: 32bit/jdk1.8.0_66 -server -XX:+UseParallelGC

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

Error Message:
Error from server at http://127.0.0.1:54407/_wfd/awholynewcollection_0: 
Expected mime type application/octet-stream but got text/html.   
 
Error 500HTTP ERROR: 500 Problem 
accessing /_wfd/awholynewcollection_0/select. Reason: {msg=Error 
trying to proxy request for url: 
http://127.0.0.1:54325/_wfd/awholynewcollection_0/select,trace=org.apache.solr.common.SolrException:
 Error trying to proxy request for url: 
http://127.0.0.1:54325/_wfd/awholynewcollection_0/select  at 
org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:591)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:441)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:222)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:110)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
  at 
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)  
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)  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.session.SessionHandler.doHandle(SessionHandler.java:221)
  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.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) 
 at java.lang.Thread.run(Thread.java:745) Caused by: 
org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for 
connection from pool  at 
org.apache.http.impl.conn.PoolingClientConnectionManager.leaseConnection(PoolingClientConnectionManager.java:226)
  at 
org.apache.http.impl.conn.PoolingClientConnectionManager$1.getConnection(PoolingClientConnectionManager.java:195)
  at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:423)
  at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
  at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
  at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
  at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
  at org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:558)  
... 24 more ,code=500} Powered by 
Jetty://   

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:54407/_wfd/awholynewcollection_0: Expected mime 
type application/octet-stream but got text/html. 


Error 500 


HTTP ERROR: 500
Problem accessing /_wfd/awholynewcollection_0/select. Reason:
{msg=Error trying to proxy request for url: 
http://127.0.0.1:54325/_wfd/awholynewcollection_0/select,trace=org.apache.solr.common.SolrException:
 Error trying to proxy request for url: 
http://127.0.0.1:54325/_wfd/awholynewcollection_0/select
at 
org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:591)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:441)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:222)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:110)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 

Re: Nested document query with wrong numFound value

[Yago Riveiro]

When do you say that I have duplicates, what do you mean? 


If I have duplicate documents is not intentional, each document must be unique.


Running a query for each id:





- Parent :  3181426982318142698228

- Child_1 : 31814269823181426982280

- Child_2 : 31814269823181426982281




The result is one document for each …





responseHeader: 
{
status: 0,



QTime: 3,



params: 
{
q: "id:3181426982318142698228",



fl: "id",



q.op: "AND"



}


},



response: 
{
numFound: 1,



start: 0,



maxScore: 11.017976,



docs: 
[

{
id: "3181426982318142698228"


}

]


}







responseHeader: 
{
status: 0,



QTime: 3,



params: 
{
q: "id:31814269823181426982280",



fl: "id",



q.op: "AND"



}


},



response: 
{
numFound: 1,



start: 0,



maxScore: 9.919363,



docs: 
[

{
id: "31814269823181426982280"


}

]


}






responseHeader: 
{
status: 0,



QTime: 3,



params: 
{
q: "id:31814269823181426982281",



fl: "id",



q.op: "AND"



}


},



response: 
{
numFound: 1,



start: 0,



maxScore: 9.919363,



docs: 
[

{
id: "31814269823181426982281"


}

]


}










—/Yago Riveiro





Ok. I got it. SolrCloud relies on uniqueKey (id) for merging shard results,

but in your examples it doesn't work, because nested documents disables

this. And you have duplicates, which make merge heap mad:


false}

},response={numFound=11,start=0,maxScore=1.0,docs=[SolrDocument{id=31814269823181426982280,

score=1.0}, SolrDocument{id=31814269823181426982280, score=1.0},

SolrDocument{id=31814269823181426982280, score=1.0},

SolrDocument{id=31814269823181426982280, score=1.0},

SolrDocument{id=31814269823181426982280, score=1.0},

SolrDocument{id=31814269823181426982281, score=1.0},

SolrDocument{id=31814269823181426982281, score=1.0},

SolrDocument{id=31814269823181426982281, score=1.0},

SolrDocument{id=31814269823181426982281, score=1.0},


Yago, you encounter a quite curious fact. Congratulation!

You can only retrieve parent document with SolrCloud, hence use {!parent

..}.. of fq=type:parent.


ccing Devs:

Shouldn't it prosecute ID dupes explicitly? Is it a known feature?



On Fri, Dec 11, 2015 at 5:08 PM, Yago Riveiro 

wrote:


> This:

>

>

>

>

>

> {

>

>

> responseHeader: {

>

>

> status: 0,

>

>

> QTime: 10,

>

>

> params: {

>

>

> q: "id:3181426982318142698228*",

>

>

> debugQuery: "true"

>

>

> }

>

>

> },

>

>

> response: {

>

>

> numFound: 3,

>

>

> start: 0,

>

>

> maxScore: 1,

>

>

> docs: [{

>

>

> id: "31814269823181426982280",

>

>

> child_type: "ecommerce_product",

>

>

> qty: 1,

>

>

> product_price: 49.99

>

>

> }, {

>

>

> id: "31814269823181426982281",

>

>

> child_type: "ecommerce_product",

>

>

> qty: 1,

>

>

> product_price: 139.9

>

>

> }]

>

>

> },

>

>

> debug: {

>

>

> track: {

>

>

> rid:

> "node-01-ecommerce-15_shard1_replica2-1449842438070-0",

>

>

> EXECUTE_QUERY: {

>

>

> http:

> //node-17:8983/solr/ecommerce-15_shard2_replica1/: {

>

>

> QTime: "0",

>

>

> ElapsedTime: "2",

>

>

> RequestPurpose: "GET_TOP_IDS",

>

>

> NumFound: "0",

>

>

> Response:

> "{responseHeader={status=0,QTime=0,params={df=_text_,distrib=false,debug=[false,

> timing, track],qt=/query,fl=[id,

> score],shards.purpose=4,start=0,fsv=true,shard.url=

> http://node-17:8983/solr/ecommerce-15_shard2_replica1/,rid=node-01-ecommerce-15_shard1_replica2-1449842438070-0,rows=10,version=2,q=id:3181426982318142698228*,requestPurpose=GET_TOP_IDS,NOW=1449842438070,isShard=true,wt=javabin,debugQuery=false}

> },response={numFound=0,start=0,maxScore=0.0,docs=[]},sort_values={},debug={timing={time=0.0,prepare={time=0.0,query={time=0.0},facet={time=0.0},facet_module={time=0.0},mlt={time=0.0},highlight={time=0.0},stats={time=0.0},expand={time=0.0},debug={time=0.0}},process={time=0.0,query={time=0.0},facet={time=0.0},facet_module={time=0.0},mlt={time=0.0},highlight={time=0.0},stats={time=0.0},expand={time=0.0},debug={time=0.0}"

>

>

> },

>

>

> 

[jira] [Created] (SOLR-8407) We log an error during normal recovery PeerSync now.

[Mark Miller (JIRA)]

Mark Miller created SOLR-8407:
-

 Summary: We log an error during normal recovery PeerSync now.
 Key: SOLR-8407
 URL: https://issues.apache.org/jira/browse/SOLR-8407
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller


{noformat}
  // TODO: does it ever make sense to allow sync when buffering or applying 
buffered? Someone might request that we
  // do it...
  if (!(ulog.getState() == UpdateLog.State.ACTIVE || ulog.getState() == 
UpdateLog.State.REPLAYING)) {
log.error(msg() + "ERROR, update log not in ACTIVE or REPLAY state. " + 
ulog);
// return false;
  }
{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-8406) AddSchemaFieldsUpdateProcessorFactory should handle list fields better

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8406:


A better way to put that might be...

{panel}
If you are using AddSchemaFieldsUpdateProcessorFactory, and there is a mapping 
X such that:
* The fieldType refered to by X is multiValued="false"
* A SolrInputDocument contains multiple values for a field which (currently) 
matches the mapping X

Then, one of the following 2 things should happen:
* The "newField" call made by AddSchemaFieldsUpdateProcessorFactory should 
explicitly include multiValued="true" when adding the field using the type 
specified by X
* The X mapping should be ignored since the _cardinality_ of values in the doc 
vs the multivalued-ness of the fieldType don't align.
{panel}

I'm a proponent of the later choice, because it means you could have fieldtypes 
like this..

{code}


{code}
...and ordered valueType mappings like this...
{code}

  java.lang.Integer
  int 


  java.lang.Integer
  ints 

{code}

But we could just as easily support either option with a {{true}} option on the 
update processor.


> AddSchemaFieldsUpdateProcessorFactory should handle list fields better
> --
>
> Key: SOLR-8406
> URL: https://issues.apache.org/jira/browse/SOLR-8406
> Project: Solr
>  Issue Type: Improvement
>  Components: Data-driven Schema
>Reporter: Timothy Potter
>
> paraphrasing from offline discussion with Hossman:
> bq. when AddSchemaFieldsUpdateProcessorFactory mappings refer to fieldtypes 
> that are multivalued=false, it should either skip that mapping, or explicitly 
> specify multivalued=true, when a document with values matching that mapping 
> contains multiple values
> basically, I'm submitting a document with foo = [ "bar", "baz" ] and field 
> guessing doesn't figure out that foo is multi-valued unless my default is set 
> to strings ... 



--
This message was sent by Atlassian 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-trunk - Build # 359 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/359/

No tests ran.

Build Log:
[...truncated 52882 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (14.1 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.0.0-src.tgz...
   [smoker] 28.3 MB in 0.03 sec (833.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.tgz...
   [smoker] 65.5 MB in 0.08 sec (821.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.zip...
   [smoker] 76.0 MB in 0.10 sec (776.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5965 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5965 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 211 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   5.4.0
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1421, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1366, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1404, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, svnRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 588, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
svnRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 733, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1359, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/build.xml:536:
 exec returned: 1

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



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

[jira] [Resolved] (LUCENE-6919) Change the Scorer API to expose an iterator instead of extending DocIdSetIterator

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-6919.
--
   Resolution: Fixed
Fix Version/s: 5.5
   Trunk

> Change the Scorer API to expose an iterator instead of extending 
> DocIdSetIterator
> -
>
> Key: LUCENE-6919
> URL: https://issues.apache.org/jira/browse/LUCENE-6919
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: Trunk, 5.5
>
> Attachments: LUCENE-6919.patch, LUCENE-6919.patch, LUCENE-6919.patch
>
>
> I was working on trying to address the performance regression on LUCENE-6815 
> but this is hard to do without introducing specialization of 
> DisjunctionScorer which I'd like to avoid at all costs.
> I think the performance regression would be easy to address without 
> specialization if Scorers were changed to return an iterator instead of 
> extending DocIdSetIterator. So conceptually the API would move from
> {code}
> class Scorer extends DocIdSetIterator {
> }
> {code}
> to
> {code}
> class Scorer {
>   DocIdSetIterator iterator();
> }
> {code}
> This would help me because then if none of the sub clauses support two-phase 
> iteration, DisjunctionScorer could directly return the approximation as an 
> iterator instead of having to check if twoPhase == null at every iteration.
> Such an approach could also help remove some method calls. For instance 
> TermScorer.nextDoc calls PostingsEnum.nextDoc but with this change 
> TermScorer.iterator() could return the PostingsEnum and TermScorer would not 
> even appear in stack traces when scoring. I hacked a patch to see how much 
> that would help and luceneutil seems to like the change:
> {noformat}
> TaskQPS baseline  StdDev   QPS patch  StdDev  
>   Pct diff
>   Fuzzy1   88.54 (15.7%)   86.73 (16.6%)   
> -2.0% ( -29% -   35%)
>   AndHighLow  698.98  (4.1%)  691.11  (5.1%)   
> -1.1% (  -9% -8%)
>   Fuzzy2   26.47 (11.2%)   26.28 (10.3%)   
> -0.7% ( -19% -   23%)
>  MedSpanNear  141.03  (3.3%)  140.51  (3.2%)   
> -0.4% (  -6% -6%)
>   HighPhrase   60.66  (2.6%)   60.48  (3.3%)   
> -0.3% (  -5% -5%)
>  LowSpanNear   29.25  (2.4%)   29.21  (2.1%)   
> -0.1% (  -4% -4%)
>MedPhrase   28.32  (1.9%)   28.28  (2.0%)   
> -0.1% (  -3% -3%)
>LowPhrase   17.31  (2.1%)   17.29  (2.6%)   
> -0.1% (  -4% -4%)
> HighSloppyPhrase   10.93  (6.0%)   10.92  (6.0%)   
> -0.1% ( -11% -   12%)
>  MedSloppyPhrase   72.21  (2.2%)   72.27  (1.8%)
> 0.1% (  -3% -4%)
>  Respell   57.35  (3.2%)   57.41  (3.4%)
> 0.1% (  -6% -6%)
> HighSpanNear   26.71  (3.0%)   26.75  (2.5%)
> 0.1% (  -5% -5%)
> OrNotHighLow  803.46  (3.4%)  807.03  (4.2%)
> 0.4% (  -6% -8%)
>  LowSloppyPhrase   88.02  (3.4%)   88.77  (2.5%)
> 0.8% (  -4% -7%)
> OrNotHighMed  200.45  (2.7%)  203.83  (2.5%)
> 1.7% (  -3% -7%)
>   OrHighHigh   38.98  (7.9%)   40.30  (6.6%)
> 3.4% ( -10% -   19%)
> HighTerm   92.53  (5.3%)   95.94  (5.8%)
> 3.7% (  -7% -   15%)
>OrHighMed   53.80  (7.7%)   55.79  (6.6%)
> 3.7% (  -9% -   19%)
>   AndHighMed  266.69  (1.7%)  277.15  (2.5%)
> 3.9% (   0% -8%)
>  Prefix3   44.68  (5.4%)   46.60  (7.0%)
> 4.3% (  -7% -   17%)
>  MedTerm  261.52  (4.9%)  273.52  (5.4%)
> 4.6% (  -5% -   15%)
> Wildcard   42.39  (6.1%)   44.35  (7.8%)
> 4.6% (  -8% -   19%)
>   IntNRQ   10.46  (7.0%)   10.99  (9.5%)
> 5.0% ( -10% -   23%)
>OrNotHighHigh   67.15  (4.6%)   70.65  (4.5%)
> 5.2% (  -3% -   15%)
>OrHighNotHigh   43.07  (5.1%)   45.36  (5.4%)
> 5.3% (  -4% -   16%)
>OrHighLow   64.19  (6.4%)   67.72  (5.5%)
> 5.5% (  -6% -   18%)
>  AndHighHigh   64.17  (2.3%)   67.87  (2.1%)
> 5.8% (   1% -   10%)
>  LowTerm  642.94 (10.9%)  681.48  (8.5%)
> 6.0% ( -12% -   28%)
> 

[jira] [Commented] (SOLR-4449) Enable backup requests for the internal solr load balancer

[Jeff Wartes (JIRA)]

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

Jeff Wartes commented on SOLR-4449:
---

For what it's worth, if I were a solr committer, I probably wouldn't just merge 
this issue as-is. BackupRequestLBHttpSolrClient still has a certain amount of 
copy/paste code from the parent LBHttpSolrClient class that'd become extra 
long-term maintenance load. (As it will be every time I update this issue for a 
new solr version)

Instead, I'd do something like:
1. Pull the asynchronous ExecutorCompletionService-based query approach into 
the LBHttpSolrClient itself. This would be interesting and useful functionality 
in it's own right. 
2. Add the concept of a shardTimeout. (Distinct from timeAllowed)
3. Add extendable support for how to handle a shardTimeout. If a strategy ends 
up making a request to another server in the list, that request must be 
submitted to the same ExecutorCompletionService so that in all cases, 
LBHttpSolrClient would return the first response among the submitted requests. 
4. The backup-request functionality could still then be a class extending 
LBHttpSolrClient, but the only real code there would be defining the 
shardTimeout for a given request, and how to handle a shardTimeout if there was 
one.

I'd probably audit the access restrictions in LBHttpSolrClient while I was at 
it though, since solrconfig.xml provides such an easy way to use alternate 
implementations of that class. A lot of the existing code in 
BackupRequestLBHttpSolrClient is only necessary due to not having sufficient 
access to the parent class. (isTimeExceeded/getTimeAllowedInNanos seem 
generally useful to have, for example, and I'm not sure why doRequest is 
protected)


> Enable backup requests for the internal solr load balancer
> --
>
> Key: SOLR-4449
> URL: https://issues.apache.org/jira/browse/SOLR-4449
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: philip hoy
>Priority: Minor
> Attachments: SOLR-4449.patch, SOLR-4449.patch, SOLR-4449.patch, 
> patch-4449.txt, solr-back-request-lb-plugin.jar
>
>
> Add the ability to configure the built-in solr load balancer such that it 
> submits a backup request to the next server in the list if the initial 
> request takes too long. Employing such an algorithm could improve the latency 
> of the 9xth percentile albeit at the expense of increasing overall load due 
> to additional requests. 



--
This message was sent by Atlassian 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-8408) Basic Auth Plugin doesn't require any credentials, doesn't enforce authentication

[Hoss Man (JIRA)]

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

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

Incredibly trivial patch to the existing BasicAuthIntegrationTest demonstrating 
the problem.

> Basic Auth Plugin doesn't require any credentials, doesn't enforce 
> authentication
> -
>
> Key: SOLR-8408
> URL: https://issues.apache.org/jira/browse/SOLR-8408
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8408.patch
>
>
> as noted on solr-user by Kristine Jetzke, and trivially to reproduce...
> {noformat}
> # interactively launch solr cloud
> $ bin/solr -e cloud
> #   ... for simplicity of test, pick a single node, 1 shard, 1 replica
> # now upload security.json from wiki page...
> # https://cwiki.apache.org/confluence/display/solr/Basic+Authentication+Plugin
> $ server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd put 
> /security.json '{
> "authentication":{
>"class":"solr.BasicAuthPlugin",
>"credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= 
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
> },
> "authorization":{
>"class":"solr.RuleBasedAuthorizationPlugin",
>"permissions":[{"name":"security-edit",
>   "role":"admin"}],
>"user-role":{"solr":"admin"}
> }}'
> # now stop & restart the single node we are using...
> $ bin/solr stop -all
> $ bin/solr restart -c -p 8983 -s example/cloud/node1/solr
> # valid credentials are accepted...
> $ curl -u 'solr:SolrRocks' 
> 'http://localhost:8983/solr/gettingstarted/select?q=*%3A*=json=true'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"*:*",
>   "indent":"true",
>   "wt":"json"}},
>   "response":{"numFound":0,"start":0,"docs":[]
>   }}
> # invalid credentials are denied...
> $ curl -u 'solr:SolrBogus' 
> 'http://localhost:8983/solr/gettingstarted/select?q=*%3A*=json=true'
>  
> 
> 
> 
> Error 401 Bad credentials
> 
> HTTP ERROR 401
> Problem accessing /solr/gettingstarted/select. Reason:
> Bad credentialsPowered by 
> Jetty://
> 
> 
> # requests w/o credentials are accepted even though they should be denied...
> $ curl 
> 'http://localhost:8983/solr/gettingstarted/select?q=*%3A*=json=true'{
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"*:*",
>   "indent":"true",
>   "wt":"json"}},
>   "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

[jira] [Resolved] (LUCENE-6815) Should DisjunctionScorer advance more lazily?

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-6815.
--
   Resolution: Fixed
Fix Version/s: 5.5
   Trunk

> Should DisjunctionScorer advance more lazily?
> -
>
> Key: LUCENE-6815
> URL: https://issues.apache.org/jira/browse/LUCENE-6815
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: Trunk, 5.5
>
> Attachments: LUCENE-6815.patch, LUCENE-6815.patch, LUCENE-6815.patch
>
>
> Today if you call DisjunctionScorer.advance(X), it will try to advance all 
> sub scorers to X. However, if DisjunctionScorer is being intersected with 
> another scorer (which is almost always the case as we use BooleanScorer for 
> top-level disjunctions), we could stop as soon as we find one matching sub 
> scorer, and only advance the remaining sub scorers when freq() or score() is 
> called. 



--
This message was sent by Atlassian 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 # 879 - Still Failing

[Apache Jenkins Server]

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

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

Error Message:
Captured an uncaught exception in thread: Thread[id=41366, name=Thread-34986, 
state=RUNNABLE, group=TGRP-TestDistributedSearch]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=41366, name=Thread-34986, state=RUNNABLE, 
group=TGRP-TestDistributedSearch]
at 
__randomizedtesting.SeedInfo.seed([5782BE7325D8DB38:DFD681A98B24B6C0]:0)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:57114/ai/collection1: 
java.lang.NullPointerException
at 
org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:105)
at 
org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:746)
at 
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:729)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:406)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2070)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:222)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:111)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:45)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1158)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1090)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:437)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:119)
at org.eclipse.jetty.server.Server.handle(Server.java:517)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:242)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:261)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:75)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:213)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:147)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.lang.Thread.run(Thread.java:745)

at __randomizedtesting.SeedInfo.seed([5782BE7325D8DB38]: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.SolrRequest.process(SolrRequest.java:150)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.TestDistributedSearch$1.run(TestDistributedSearch.java:1115)


FAILED:  org.apache.solr.cloud.TestRequestForwarding.testMultiCollectionQuery

Error Message:
Could not create collection. 

[jira] [Commented] (LUCENE-6926) Take matchCost into account for MUST_NOT clauses

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-6926:
--

The patch uses only matchCost  of req and excl, but it might be better to also 
use their costs as a weight, just like a conjunction. The patch uses equal 
weights for req and excl.

Here the conjunction is (req and (not excl)), and for weighting their costs are 
req.cost() and (N - excl.cost()), with N as the number of docs in the segment.
This would boil down to normally using req first, as expected. Only when excl 
matches a lot of docs, its weighting cost would be lower.

Would it be worthwhile to use such weights here?
See also LUCENE-6894 where the number of docs in a segment is used much more.

> Take matchCost into account for MUST_NOT clauses
> 
>
> Key: LUCENE-6926
> URL: https://issues.apache.org/jira/browse/LUCENE-6926
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6926.patch
>
>
> ReqExclScorer potentially has two TwoPhaseIterators to check: the one for the 
> positive clause and the one for the negative clause. It should leverage the 
> match cost API to check the least costly one first.



--
This message was sent by Atlassian 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-EA] Lucene-Solr-5.4-Linux (32bit/jdk-9-ea+95) - Build # 370 - Failure!

[Uwe Schindler]

Now that 5.4 is released, I disabled the build.

Uwe

Am 11. Dezember 2015 21:54:58 MEZ, schrieb Policeman Jenkins Server 
:
>Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.4-Linux/370/
>Java: 32bit/jdk-9-ea+95 -server -XX:+UseSerialGC -XX:-CompactStrings
>
>3 tests failed.
>FAILED: 
>org.apache.solr.handler.dataimport.TestTikaEntityProcessor.testSkip
>
>Error Message:
>
>
>Stack Trace:
>java.lang.ExceptionInInitializerError
>   at
>__randomizedtesting.SeedInfo.seed([775AA979A34D1784:B13501EA93072D83]:0)
>   at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:146)
>   at
>org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:256)
>   at
>org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:256)
>   at
>org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:120)
>   at
>org.apache.solr.handler.dataimport.TikaEntityProcessor.nextRow(TikaEntityProcessor.java:159)
>   at
>org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:244)
>   at
>org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:476)
>   at
>org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:415)
>   at
>org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:330)
>   at
>org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:233)
>   at
>org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:417)
>   at
>org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:481)
>   at
>org.apache.solr.handler.dataimport.DataImportHandler.handleRequestBody(DataImportHandler.java:186)
>   at
>org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073)
>   at org.apache.solr.util.TestHarness.query(TestHarness.java:311)
>   at
>org.apache.solr.handler.dataimport.AbstractDataImportHandlerTestCase.runFullImport(AbstractDataImportHandlerTestCase.java:87)
>   at
>org.apache.solr.handler.dataimport.TestTikaEntityProcessor.testSkip(TestTikaEntityProcessor.java:118)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:520)
>   at
>com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
>   at
>com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
>   at
>com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
>   at
>com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
>   at
>com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at
>org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java: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:880)
>   at
>com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
>   at
>com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
>   at
>com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
>   at
>com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at
>com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at
>org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at
>com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at

[jira] [Commented] (SOLR-8407) We log an error during normal recovery PeerSync now.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8407:
---

We now start buffering before peersync in recovery, and so we are always in a 
BUFFERING state here and log this error.

> We log an error during normal recovery PeerSync now.
> 
>
> Key: SOLR-8407
> URL: https://issues.apache.org/jira/browse/SOLR-8407
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>
> {noformat}
>   // TODO: does it ever make sense to allow sync when buffering or 
> applying buffered? Someone might request that we
>   // do it...
>   if (!(ulog.getState() == UpdateLog.State.ACTIVE || ulog.getState() == 
> UpdateLog.State.REPLAYING)) {
> log.error(msg() + "ERROR, update log not in ACTIVE or REPLAY state. " 
> + ulog);
> // return false;
>   }
> {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

Re: [JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_66) - Build # 5464 - Failure!

[Michael McCandless]

I committed a fix for this already ... just needed to add a single
character to the source file: * ;)

Mike McCandless

http://blog.mikemccandless.com


On Fri, Dec 11, 2015 at 4:00 PM, Policeman Jenkins Server
 wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5464/
> Java: 64bit/jdk1.8.0_66 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC
>
> All tests passed
>
> Build Log:
> [...truncated 47409 lines...]
> -documentation-lint:
>  [echo] checking for broken html...
> [jtidy] Checking for broken html (such as invalid tags)...
>[delete] Deleting directory 
> C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\jtidy_tmp
>  [echo] Checking for broken links...
>  [exec]
>  [exec] Crawl/parse...
>  [exec]
>  [exec] Verify...
>  [echo] Checking for missing docs...
>  [exec]
>  [exec] 
> build/docs\test-framework\org\apache\lucene\index/package-summary.html
>  [exec]   missing: ForceMergePolicy
>  [exec]
>  [exec] Missing javadocs were found!
>
> BUILD FAILED
> C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:784: The 
> following error occurred while executing this line:
> C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:101: The 
> following error occurred while executing this line:
> C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:138:
>  The following error occurred while executing this line:
> C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:154:
>  The following error occurred while executing this line:
> C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:2508:
>  exec returned: 1
>
> Total time: 88 minutes 56 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

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

[jira] [Commented] (LUCENE-6917) Move NumericField out of core to backwards-codecs

[ASF subversion and git services (JIRA)]

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

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

Commit 1719562 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1719562 ]

LUCENE-6917: rename/deprecate numeric classes in favor of dimensional values

> Move NumericField out of core to backwards-codecs
> -
>
> Key: LUCENE-6917
> URL: https://issues.apache.org/jira/browse/LUCENE-6917
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.0
>
> Attachments: LUCENE-6917-broken-javadocs.patch, LUCENE-6917.patch, 
> LUCENE-6917.patch, LUCENE-6917.patch
>
>
> DimensionalValues seems to be better across the board (indexing time, 
> indexing size, search-speed, search-time heap required) than NumericField, at 
> least in my testing so far.
> I think for 6.0 we should move {{IntField}}, {{LongField}}, {{FloatField}}, 
> {{DoubleField}} and {{NumericRangeQuery}} to {{backward-codecs}}, and rename 
> with {{Legacy}} prefix?



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

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

[jira] [Updated] (LUCENE-6917) Deprecate and rename NumericField/RangeQuery to LegacyNumeric

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-6917:
---
Summary: Deprecate and rename NumericField/RangeQuery to LegacyNumeric  
(was: Move NumericField out of core to backwards-codecs)

> Deprecate and rename NumericField/RangeQuery to LegacyNumeric
> -
>
> Key: LUCENE-6917
> URL: https://issues.apache.org/jira/browse/LUCENE-6917
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.0
>
> Attachments: LUCENE-6917-broken-javadocs.patch, LUCENE-6917.patch, 
> LUCENE-6917.patch, LUCENE-6917.patch
>
>
> DimensionalValues seems to be better across the board (indexing time, 
> indexing size, search-speed, search-time heap required) than NumericField, at 
> least in my testing so far.
> I think for 6.0 we should move {{IntField}}, {{LongField}}, {{FloatField}}, 
> {{DoubleField}} and {{NumericRangeQuery}} to {{backward-codecs}}, and rename 
> with {{Legacy}} prefix?



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

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

[jira] [Resolved] (LUCENE-6917) Deprecate and rename NumericField/RangeQuery to LegacyNumeric

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-6917.

Resolution: Fixed

> Deprecate and rename NumericField/RangeQuery to LegacyNumeric
> -
>
> Key: LUCENE-6917
> URL: https://issues.apache.org/jira/browse/LUCENE-6917
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.0
>
> Attachments: LUCENE-6917-broken-javadocs.patch, LUCENE-6917.patch, 
> LUCENE-6917.patch, LUCENE-6917.patch
>
>
> DimensionalValues seems to be better across the board (indexing time, 
> indexing size, search-speed, search-time heap required) than NumericField, at 
> least in my testing so far.
> I think for 6.0 we should move {{IntField}}, {{LongField}}, {{FloatField}}, 
> {{DoubleField}} and {{NumericRangeQuery}} to {{backward-codecs}}, and rename 
> with {{Legacy}} prefix?



--
This message was sent by Atlassian 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-4449) Enable backup requests for the internal solr load balancer

[Jeff Wartes (JIRA)]

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

Jeff Wartes commented on SOLR-4449:
---

I looked around a bit, and unless I'm missing something, it looks like 
solr-core doesn't really use metrics-core. At the end of SOLR-1972, the 
necessary classes were just copy/pasted into the solr codeline. It sounds like 
this was mostly due to being nervous after encountering some problems in the 
metrics-core version at the time, and an aversion to a global registry 
approach. 

Unfortunately, this means that although requesthandlers have statistics, they 
cannot be attached to a metrics Reporter, and instead you have to develop 
something to interrogate JMX or some such. 

Solr does include metrics-core 3.0.1, but there's only a few places it actually 
gets used, and only in contrib modules.

I didn't have the negative experience with metrics-core. In fact, my 
experiences with 3.1.2 over the last year and a half has been universally 
positive. So when I added backup-percentile support to this issue I relied 
heavily on the global SharedMetricsRegistry and the assumption that the library 
was threadsafe in general. My scattershot code reviews of the metrics library 
have generally enforced my opinion that this is ok, and I'm using my version of 
this issue in production now. Initializing a well-known-named shared registry 
with an attached reporter in jetty.xml has yielded all kinds of great 
performance data.

This might be a useful point of information if anyone gets back to SOLR-4735. 
I'll mention here if I do encounter any metrics-core related issues in the 
future.

> Enable backup requests for the internal solr load balancer
> --
>
> Key: SOLR-4449
> URL: https://issues.apache.org/jira/browse/SOLR-4449
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: philip hoy
>Priority: Minor
> Attachments: SOLR-4449.patch, SOLR-4449.patch, SOLR-4449.patch, 
> patch-4449.txt, solr-back-request-lb-plugin.jar
>
>
> Add the ability to configure the built-in solr load balancer such that it 
> submits a backup request to the next server in the list if the initial 
> request takes too long. Employing such an algorithm could improve the latency 
> of the 9xth percentile albeit at the expense of increasing overall load due 
> to additional requests. 



--
This message was sent by Atlassian 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-8408) Basic Auth Plugin doesn't require any credentials, doesn't enforce authentication

[Hoss Man (JIRA)]

Hoss Man created SOLR-8408:
--

 Summary: Basic Auth Plugin doesn't require any credentials, 
doesn't enforce authentication
 Key: SOLR-8408
 URL: https://issues.apache.org/jira/browse/SOLR-8408
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man


as noted on solr-user by Kristine Jetzke, and trivially to reproduce...

{noformat}
# interactively launch solr cloud
$ bin/solr -e cloud
#   ... for simplicity of test, pick a single node, 1 shard, 1 replica
# now upload security.json from wiki page...
# https://cwiki.apache.org/confluence/display/solr/Basic+Authentication+Plugin
$ server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd put 
/security.json '{
"authentication":{
   "class":"solr.BasicAuthPlugin",
   "credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= 
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
},
"authorization":{
   "class":"solr.RuleBasedAuthorizationPlugin",
   "permissions":[{"name":"security-edit",
  "role":"admin"}],
   "user-role":{"solr":"admin"}
}}'
# now stop & restart the single node we are using...
$ bin/solr stop -all
$ bin/solr restart -c -p 8983 -s example/cloud/node1/solr
# valid credentials are accepted...
$ curl -u 'solr:SolrRocks' 
'http://localhost:8983/solr/gettingstarted/select?q=*%3A*=json=true'
{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"*:*",
  "indent":"true",
  "wt":"json"}},
  "response":{"numFound":0,"start":0,"docs":[]
  }}
# invalid credentials are denied...
$ curl -u 'solr:SolrBogus' 
'http://localhost:8983/solr/gettingstarted/select?q=*%3A*=json=true' 



Error 401 Bad credentials

HTTP ERROR 401
Problem accessing /solr/gettingstarted/select. Reason:
Bad credentialsPowered by 
Jetty://



# requests w/o credentials are accepted even though they should be denied...
$ curl 
'http://localhost:8983/solr/gettingstarted/select?q=*%3A*=json=true'{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"*:*",
  "indent":"true",
  "wt":"json"}},
  "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

[jira] [Commented] (SOLR-8409) Complex q param in Streaming Expression results in a bad query

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-8409:
---

It looks like this
{code}
presentTitles:\"chief executive officer\" AND age:[36 TO *]
{code}

I suspect that the \" is the culprit here because the streaming expression 
parser does not remove the \ before the quote. As such, and this is a hunch, I 
suspect that the query parser is seeing \" and not considering it a quote that 
is starting a phase but instead a quote that is just part of the string being 
searched.

{code}
chief executive officer
{code}

I believe this can be fixed by adding logic into the expression parser that 
will transform \" into " and in fact I've written that code (very simple) but 
my lack of ability to replicate in a unit test is preventing me from ensuring 
the issue is actually fixed.

> Complex q param in Streaming Expression results in a bad query
> --
>
> Key: SOLR-8409
> URL: https://issues.apache.org/jira/browse/SOLR-8409
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: Trunk, 6.0
>Reporter: Dennis Gove
>Priority: Minor
>  Labels: streaming, streaming_api
>
> When providing an expression like 
> {code}
> stream=search(people, fl="id,first", sort="first asc", 
> q="presentTitles:\"chief executive officer\" AND age:[36 TO *]")
> {code}
> the following error is seen.
> {code}
> no field name specified in query and no default specified via 'df' param
> {code}
> I believe the issue is related to the \" (escaped quotes) and the spaces in 
> the q field. If I remove the spaces then the query returns results as 
> expected (though I've yet to validate if those results are accurate).
> This requires some investigation to get down to the root cause. I would like 
> to fix it before Solr 6 is cut.



--
This message was sent by Atlassian 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-5959) Cloud scripts cannot be run out of the box

[Maxim Novikov (JIRA)]

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

Maxim Novikov commented on SOLR-5959:
-

[~elyograg] Thanks for the clarification.

> Cloud scripts cannot be run out of the box
> --
>
> Key: SOLR-5959
> URL: https://issues.apache.org/jira/browse/SOLR-5959
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 4.7.1
> Environment: CentOS 6.5 x64
>Reporter: Maxim Novikov
>
> Solr's cloud scripts ($solr/example/scripts/cloud-scripts/zkcli.sh) expect to 
> have the files from solr.war ($solr/example/webapps/solr.web) extracted to 
> $/solr/example/solr-webapp/webapp. While it is not done, Solr's ZK CLI fails 
> to run.
> Please note that in v.4.6 it was all set as expected out of the box and 
> worked without any additional extracting/copying, etc. We would expect that 
> it worked in 4.7 and all the following versions same way.



--
This message was sent by Atlassian 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-7904) Make FacetStream Expressible

[Dennis Gove (JIRA)]

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

Dennis Gove updated SOLR-7904:
--
Attachment: SOLR-7904.patch

Addes facet as a default function in the StreamHandler.

> Make FacetStream Expressible
> 
>
> Key: SOLR-7904
> URL: https://issues.apache.org/jira/browse/SOLR-7904
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Joel Bernstein
> Fix For: Trunk
>
> Attachments: SOLR-7904.patch, SOLR-7904.patch
>
>
> This ticket makes the FacetStream (SOLR-7903) expressible, so it can be used 
> as a Streaming Expression.



--
This message was sent by Atlassian 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-8409) Complex q param in Streaming Expression results in a bad query

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-8409:
---

I've been unable to replicate this in a unit test but have seen it in a fully 
packaged version of trunk. (ant package was run and then the tarball was 
unpacked).

Differences between unit test and packaged version:
* unit test is using dynamic fields while packaged version is using static 
fields
* unit test is not going through the StreamHandler

> Complex q param in Streaming Expression results in a bad query
> --
>
> Key: SOLR-8409
> URL: https://issues.apache.org/jira/browse/SOLR-8409
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: Trunk, 6.0
>Reporter: Dennis Gove
>Priority: Minor
>  Labels: streaming, streaming_api
>
> When providing an expression like 
> {code}
> stream=search(people, fl="id,first", sort="first asc", 
> q="presentTitles:\"chief executive officer\" AND age:[36 TO *]")
> {code}
> the following error is seen.
> {code}
> no field name specified in query and no default specified via 'df' param
> {code}
> I believe the issue is related to the \" (escaped quotes) and the spaces in 
> the q field. If I remove the spaces then the query returns results as 
> expected (though I've yet to validate if those results are accurate).
> This requires some investigation to get down to the root cause. I would like 
> to fix it before Solr 6 is cut.



--
This message was sent by Atlassian 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-8409) Complex q param in Streaming Expression results in a bad query

[Dennis Gove (JIRA)]

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

Dennis Gove updated SOLR-8409:
--
Description: 
When providing an expression like 
{code}
stream=search(people, fl="id,first", sort="first asc", q="presentTitles:\"chief 
executive officer\" AND age:[36 TO *]")
{code}
the following error is seen.
{code}
no field name specified in query and no default specified via 'df' param
{code}

I believe the issue is related to the \" (escaped quotes) and the spaces in the 
q field. If I remove the spaces then the query returns results as expected 
(though I've yet to validate if those results are accurate).

This requires some investigation to get down to the root cause. I would like to 
fix it before Solr 6 is cut.

  was:
When providing an expression like 
{code}
expression=search(people, fl="id,first", sort="first asc", 
q="presentTitles:\"chief executive officer\" AND age:[36 TO *]")
{code}
the following error is seen.
{code}
no field name specified in query and no default specified via 'df' param
{code}

I believe the issue is related to the \" (escaped quotes) and the spaces in the 
q field. If I remove the spaces then the query returns results as expected 
(though I've yet to validate if those results are accurate).

This requires some investigation to get down to the root cause. I would like to 
fix it before Solr 6 is cut.


> Complex q param in Streaming Expression results in a bad query
> --
>
> Key: SOLR-8409
> URL: https://issues.apache.org/jira/browse/SOLR-8409
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: Trunk, 6.0
>Reporter: Dennis Gove
>Priority: Minor
>  Labels: streaming, streaming_api
>
> When providing an expression like 
> {code}
> stream=search(people, fl="id,first", sort="first asc", 
> q="presentTitles:\"chief executive officer\" AND age:[36 TO *]")
> {code}
> the following error is seen.
> {code}
> no field name specified in query and no default specified via 'df' param
> {code}
> I believe the issue is related to the \" (escaped quotes) and the spaces in 
> the q field. If I remove the spaces then the query returns results as 
> expected (though I've yet to validate if those results are accurate).
> This requires some investigation to get down to the root cause. I would like 
> to fix it before Solr 6 is cut.



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

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

[JENKINS-EA] Lucene-Solr-5.x-Linux (32bit/jdk-9-ea+95) - Build # 14877 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14877/
Java: 32bit/jdk-9-ea+95 -client -XX:+UseConcMarkSweepGC -XX:-CompactStrings

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

Error Message:
[/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_FEA005ECC419C228-001/solr-instance-011/./collection1/data/index.20151212133511615,
 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_FEA005ECC419C228-001/solr-instance-011/./collection1/data/index.20151212133511488,
 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_FEA005ECC419C228-001/solr-instance-011/./collection1/data]
 expected:<2> but was:<3>

Stack Trace:
java.lang.AssertionError: 
[/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_FEA005ECC419C228-001/solr-instance-011/./collection1/data/index.20151212133511615,
 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_FEA005ECC419C228-001/solr-instance-011/./collection1/data/index.20151212133511488,
 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_FEA005ECC419C228-001/solr-instance-011/./collection1/data]
 expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([FEA005ECC419C228:9D3EBB402F16DCE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:815)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1245)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java: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:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)

[jira] [Updated] (SOLR-7904) Make FacetStream Expressible

[Dennis Gove (JIRA)]

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

Dennis Gove updated SOLR-7904:
--
Attachment: SOLR-7904.patch

Fully implemented. All relevant tests pass.

> Make FacetStream Expressible
> 
>
> Key: SOLR-7904
> URL: https://issues.apache.org/jira/browse/SOLR-7904
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Joel Bernstein
> Fix For: Trunk
>
> Attachments: SOLR-7904.patch
>
>
> This ticket makes the FacetStream (SOLR-7903) expressible, so it can be used 
> as a Streaming Expression.



--
This message was sent by Atlassian 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 # 252 - Still Failing!

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:38576/solr: collection already exists: 
testcollection

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:38576/solr: collection already exists: 
testcollection
at 
__randomizedtesting.SeedInfo.seed([7E421E356D5593BB:439AB01955BBCDCB]: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:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:416)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:400)
at 
org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:107)
at 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateSearchDelete(TestMiniSolrCloudCluster.java:141)
at 
org.apache.solr.cloud.TestAuthenticationFramework.testBasics(TestAuthenticationFramework.java:93)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java: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:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Assigned] (SOLR-8408) Basic Auth Plugin doesn't require any credentials, doesn't enforce authentication

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-8408:


Assignee: Noble Paul

> Basic Auth Plugin doesn't require any credentials, doesn't enforce 
> authentication
> -
>
> Key: SOLR-8408
> URL: https://issues.apache.org/jira/browse/SOLR-8408
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Noble Paul
> Attachments: SOLR-8408.patch
>
>
> as noted on solr-user by Kristine Jetzke, and trivially to reproduce...
> {noformat}
> # interactively launch solr cloud
> $ bin/solr -e cloud
> #   ... for simplicity of test, pick a single node, 1 shard, 1 replica
> # now upload security.json from wiki page...
> # https://cwiki.apache.org/confluence/display/solr/Basic+Authentication+Plugin
> $ server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd put 
> /security.json '{
> "authentication":{
>"class":"solr.BasicAuthPlugin",
>"credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= 
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
> },
> "authorization":{
>"class":"solr.RuleBasedAuthorizationPlugin",
>"permissions":[{"name":"security-edit",
>   "role":"admin"}],
>"user-role":{"solr":"admin"}
> }}'
> # now stop & restart the single node we are using...
> $ bin/solr stop -all
> $ bin/solr restart -c -p 8983 -s example/cloud/node1/solr
> # valid credentials are accepted...
> $ curl -u 'solr:SolrRocks' 
> 'http://localhost:8983/solr/gettingstarted/select?q=*%3A*=json=true'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"*:*",
>   "indent":"true",
>   "wt":"json"}},
>   "response":{"numFound":0,"start":0,"docs":[]
>   }}
> # invalid credentials are denied...
> $ curl -u 'solr:SolrBogus' 
> 'http://localhost:8983/solr/gettingstarted/select?q=*%3A*=json=true'
>  
> 
> 
> 
> Error 401 Bad credentials
> 
> HTTP ERROR 401
> Problem accessing /solr/gettingstarted/select. Reason:
> Bad credentialsPowered by 
> Jetty://
> 
> 
> # requests w/o credentials are accepted even though they should be denied...
> $ curl 
> 'http://localhost:8983/solr/gettingstarted/select?q=*%3A*=json=true'{
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"*:*",
>   "indent":"true",
>   "wt":"json"}},
>   "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

[jira] [Commented] (SOLR-8408) Basic Auth Plugin doesn't require any credentials, doesn't enforce authentication

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8408:
--

It works as designed.

In this case {{/select}} is not protected. So an unauthenticated request must 
be able to access {{/select}} path. authentication layer has no idea whether it 
is a protected resource or not. So, when no credentials headers are sent it 
sets the user principal as null and lets the request go through. Whereas in the 
case of wrong credentials, the choices are 1) fail the request or 2) forward 
the request as if the principal is null . #2 would be bad user experience 
because the Authorization layer would say principal is null (unauthenicated) 
and the user would not know that the credentials were wrong. 


> Basic Auth Plugin doesn't require any credentials, doesn't enforce 
> authentication
> -
>
> Key: SOLR-8408
> URL: https://issues.apache.org/jira/browse/SOLR-8408
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8408.patch
>
>
> as noted on solr-user by Kristine Jetzke, and trivially to reproduce...
> {noformat}
> # interactively launch solr cloud
> $ bin/solr -e cloud
> #   ... for simplicity of test, pick a single node, 1 shard, 1 replica
> # now upload security.json from wiki page...
> # https://cwiki.apache.org/confluence/display/solr/Basic+Authentication+Plugin
> $ server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd put 
> /security.json '{
> "authentication":{
>"class":"solr.BasicAuthPlugin",
>"credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= 
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
> },
> "authorization":{
>"class":"solr.RuleBasedAuthorizationPlugin",
>"permissions":[{"name":"security-edit",
>   "role":"admin"}],
>"user-role":{"solr":"admin"}
> }}'
> # now stop & restart the single node we are using...
> $ bin/solr stop -all
> $ bin/solr restart -c -p 8983 -s example/cloud/node1/solr
> # valid credentials are accepted...
> $ curl -u 'solr:SolrRocks' 
> 'http://localhost:8983/solr/gettingstarted/select?q=*%3A*=json=true'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"*:*",
>   "indent":"true",
>   "wt":"json"}},
>   "response":{"numFound":0,"start":0,"docs":[]
>   }}
> # invalid credentials are denied...
> $ curl -u 'solr:SolrBogus' 
> 'http://localhost:8983/solr/gettingstarted/select?q=*%3A*=json=true'
>  
> 
> 
> 
> Error 401 Bad credentials
> 
> HTTP ERROR 401
> Problem accessing /solr/gettingstarted/select. Reason:
> Bad credentialsPowered by 
> Jetty://
> 
> 
> # requests w/o credentials are accepted even though they should be denied...
> $ curl 
> 'http://localhost:8983/solr/gettingstarted/select?q=*%3A*=json=true'{
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"*:*",
>   "indent":"true",
>   "wt":"json"}},
>   "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

[jira] [Updated] (SOLR-7123) /update/json/docs should have nested document support

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-7123:
-
Description: 
It is the next logical step after SOLR-6304
For the example document given below where the /orgs belong to a nested 
document, 
{code}
{
"name": "Joe Smith",
"phone": 876876687
"orgs" :[ {" name" : "Microsoft",
  "city": "Seattle",
  "zip": 98052},
{"name": “Apple”,
 "city":”Cupertino”,
 "zip":"95014" }
  ]
} 
{code}
The extra mapping parameters would be
{noformat}
child.split=o:/org&
o.f=name&
o.f=city&
o.f=zip
{noformat}
* o is the short name for that child. It is possible to map multiple children 
with multiple shortnames
* In this example all the o.* paths are relative. It is possible to specify 
absolute path names such as o.f=/org/name 




  was:
It is the next logical step after SOLR-6304
For the example document given below where the /orgs belong to a nested 
document, 
{code}
{
"name": "Joe Smith",
"phone": 876876687
"orgs" :[ {" name" : "Microsoft",
  "city": "Seattle",
  "zip": 98052},
{"name": “Apple”,
 "city:”Cupertino”,
 "zip":"95014" }
  ]
} 
{code}
The extra mapping parameters would be
{noformat}
child.split=o:/org&
o.f=name&
o.f=city&
o.f=zip
{noformat}
* o is the short name for that child. It is possible to map multiple children 
with multiple shortnames
* In this example all the o.* paths are relative. It is possible to specify 
absolute path names such as o.f=/org/name 





> /update/json/docs should have nested document support
> -
>
> Key: SOLR-7123
> URL: https://issues.apache.org/jira/browse/SOLR-7123
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: EaseOfUse
> Attachments: SOLR-7123.patch
>
>
> It is the next logical step after SOLR-6304
> For the example document given below where the /orgs belong to a nested 
> document, 
> {code}
> {
> "name": "Joe Smith",
> "phone": 876876687
> "orgs" :[ {" name" : "Microsoft",
>   "city": "Seattle",
>   "zip": 98052},
> {"name": “Apple”,
>  "city":”Cupertino”,
>  "zip":"95014" }
>   ]
> } 
> {code}
> The extra mapping parameters would be
> {noformat}
> child.split=o:/org&
> o.f=name&
> o.f=city&
> o.f=zip
> {noformat}
> * o is the short name for that child. It is possible to map multiple children 
> with multiple shortnames
> * In this example all the o.* paths are relative. It is possible to specify 
> absolute path names such as o.f=/org/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

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

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50
at __randomizedtesting.SeedInfo.seed([F5625739FF6EEE5A]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:453)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:225)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


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

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

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


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

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

[jira] [Commented] (SOLR-8125) Umbrella ticket for Streaming and SQL issues

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-8125:
---

SOLR-8409 is a bug I'd like to get into Solr 6. I'd hate to see this go out in 
a major.

> Umbrella ticket for Streaming and SQL issues
> 
>
> Key: SOLR-8125
> URL: https://issues.apache.org/jira/browse/SOLR-8125
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Joel Bernstein
>
> This is an umbrella ticket for tracking issues around the *Streaming API*, 
> *Streaming Expressions* and *Parallel SQL*.
> Issues can be linked to this ticket and discussions about the road map can 
> also happen on this ticket.



--
This message was sent by Atlassian 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-8409) Complex q param in Streaming Expression results in a bad query

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-8409:
---

Backing up my hunch is that if I change the q to be 
{code}
presentTitles:\"chief\" AND age:[36 TO *]
{code}
I get results back but  a very small subset of the results I would expect to 
get back.

I've yet to visually verify the source data but I would guess that there is a 
record containing a field value
"chief"

I'll check for that the next time I'm looking into this (by Monday I suspect) 
but I'd wager that I'll find it. 

> Complex q param in Streaming Expression results in a bad query
> --
>
> Key: SOLR-8409
> URL: https://issues.apache.org/jira/browse/SOLR-8409
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: Trunk, 6.0
>Reporter: Dennis Gove
>Priority: Minor
>  Labels: streaming, streaming_api
>
> When providing an expression like 
> {code}
> stream=search(people, fl="id,first", sort="first asc", 
> q="presentTitles:\"chief executive officer\" AND age:[36 TO *]")
> {code}
> the following error is seen.
> {code}
> no field name specified in query and no default specified via 'df' param
> {code}
> I believe the issue is related to the \" (escaped quotes) and the spaces in 
> the q field. If I remove the spaces then the query returns results as 
> expected (though I've yet to validate if those results are accurate).
> This requires some investigation to get down to the root cause. I would like 
> to fix it before Solr 6 is cut.



--
This message was sent by Atlassian 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-8409) Complex q param in Streaming Expression results in a bad query

[Dennis Gove (JIRA)]

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

Dennis Gove updated SOLR-8409:
--
Affects Version/s: 6.0
   Trunk
   Labels: streaming streaming_api  (was: )
  Description: 
When providing an expression like 
{code}
expression=search(people, fl="id,first", sort="first asc", 
q="presentTitles:\"chief executive officer\" AND age:[36 TO *]")
{code}
the following error is seen.
{code}
no field name specified in query and no default specified via 'df' param
{code}

I believe the issue is related to the \" (escaped quotes) and the spaces in the 
q field. If I remove the spaces then the query returns results as expected 
(though I've yet to validate if those results are accurate).

This requires some investigation to get down to the root cause. I would like to 
fix it before Solr 6 is cut.

> Complex q param in Streaming Expression results in a bad query
> --
>
> Key: SOLR-8409
> URL: https://issues.apache.org/jira/browse/SOLR-8409
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: Trunk, 6.0
>Reporter: Dennis Gove
>Priority: Minor
>  Labels: streaming, streaming_api
>
> When providing an expression like 
> {code}
> expression=search(people, fl="id,first", sort="first asc", 
> q="presentTitles:\"chief executive officer\" AND age:[36 TO *]")
> {code}
> the following error is seen.
> {code}
> no field name specified in query and no default specified via 'df' param
> {code}
> I believe the issue is related to the \" (escaped quotes) and the spaces in 
> the q field. If I remove the spaces then the query returns results as 
> expected (though I've yet to validate if those results are accurate).
> This requires some investigation to get down to the root cause. I would like 
> to fix it before Solr 6 is cut.



--
This message was sent by Atlassian 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-8409) Complex q param in Streaming Expression results in a bad query

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8409:
--

What does the query look like after the Streaming Expression been's parsed?

> Complex q param in Streaming Expression results in a bad query
> --
>
> Key: SOLR-8409
> URL: https://issues.apache.org/jira/browse/SOLR-8409
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: Trunk, 6.0
>Reporter: Dennis Gove
>Priority: Minor
>  Labels: streaming, streaming_api
>
> When providing an expression like 
> {code}
> stream=search(people, fl="id,first", sort="first asc", 
> q="presentTitles:\"chief executive officer\" AND age:[36 TO *]")
> {code}
> the following error is seen.
> {code}
> no field name specified in query and no default specified via 'df' param
> {code}
> I believe the issue is related to the \" (escaped quotes) and the spaces in 
> the q field. If I remove the spaces then the query returns results as 
> expected (though I've yet to validate if those results are accurate).
> This requires some investigation to get down to the root cause. I would like 
> to fix it before Solr 6 is cut.



--
This message was sent by Atlassian 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-7904) Make FacetStream Expressible

[Dennis Gove (JIRA)]

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

Dennis Gove edited comment on SOLR-7904 at 12/12/15 1:18 AM:
-

Adds facet as a default function in the StreamHandler.


was (Author: dpgove):
Addes facet as a default function in the StreamHandler.

> Make FacetStream Expressible
> 
>
> Key: SOLR-7904
> URL: https://issues.apache.org/jira/browse/SOLR-7904
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Joel Bernstein
> Fix For: Trunk
>
> Attachments: SOLR-7904.patch, SOLR-7904.patch
>
>
> This ticket makes the FacetStream (SOLR-7903) expressible, so it can be used 
> as a Streaming Expression.



--
This message was sent by Atlassian 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-5959) Cloud scripts cannot be run out of the box

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-5959:


"Fixed" is used when a change is made to the source code specifically to fix 
the problem outlined in the issue.

For various reasons, in version 5.3.0 (SOLR-7227), the Solr package was changed 
so that the webapp is already extracted -- jetty no longer needs to unpack the 
war file.  The problem described by this issue no longer exists in the newest 
version of Solr.  All the jars necessary for cloud script operation are in the 
correct location as soon as you unzip or untar the binary Solr download.


> Cloud scripts cannot be run out of the box
> --
>
> Key: SOLR-5959
> URL: https://issues.apache.org/jira/browse/SOLR-5959
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 4.7.1
> Environment: CentOS 6.5 x64
>Reporter: Maxim Novikov
>
> Solr's cloud scripts ($solr/example/scripts/cloud-scripts/zkcli.sh) expect to 
> have the files from solr.war ($solr/example/webapps/solr.web) extracted to 
> $/solr/example/solr-webapp/webapp. While it is not done, Solr's ZK CLI fails 
> to run.
> Please note that in v.4.6 it was all set as expected out of the box and 
> worked without any additional extracting/copying, etc. We would expect that 
> it worked in 4.7 and all the following versions same way.



--
This message was sent by Atlassian 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 # 1044 - Still Failing

[Apache Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:41741/_v/vj: Could not load collection 
from ZK:halfcollectionblocker

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:41741/_v/vj: Could not load collection from 
ZK:halfcollectionblocker
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.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:295)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:412)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:162)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 

[jira] [Commented] (SOLR-3443) Optimize hunspell dictionary loading with multiple cores

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-3443:


Was working on something else and thinking about memory consistency when it 
occurred to me that this patch might need a couple of tweaks to the Dictionary 
class to ensure that it's loading *happens before* any look ups... unless there 
is some point in the overall solr initialization phase that ensures that 
request handling threads and the core initialization threads all lock and 
unlock the same monitor before requests are handled? Does that exist somewhere? 
Memory consistency seems like something that must have already been thought 
about...  Will think more and look at it tonight.

In any case this should not effect the general resource sharing patch in 
SOLR-8349 unless I decide to add further _caveat emptor_ warnings to the 
javadoc :).

> Optimize hunspell dictionary loading with multiple cores
> 
>
> Key: SOLR-3443
> URL: https://issues.apache.org/jira/browse/SOLR-3443
> Project: Solr
>  Issue Type: Improvement
>Reporter: Luca Cavanna
> Attachments: SOLR-3443.patch, Screen Shot 2015-11-29 at 9.52.06 AM.png
>
>
> The Hunspell dictionary is actually loaded into memory. Each core using 
> hunspell loads its own dictionary, no matter if all the cores are using the 
> same dictionary files. As a result, the same dictionary is loaded into memory 
> multiple times, once for each core. I think we should share those 
> dictionaries between all cores in order to optimize the memory usage. In 
> fact, let's say a dictionary takes 20MB into memory (this is what I 
> detected), if you have 20 cores you are going to use 400MB only for 
> dictionaries, which doesn't seem a good idea to me.



--
This message was sent by Atlassian 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-5.x-MacOSX (64bit/jdk1.8.0) - Build # 2877 - Still Failing!

[Adrien Grand]

I committed a fix.

Le ven. 11 déc. 2015 à 08:54, Policeman Jenkins Server 
a écrit :

> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2877/
> Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
>
> All tests passed
>
> Build Log:
> [...truncated 47711 lines...]
> -documentation-lint:
>  [echo] checking for broken html...
> [jtidy] Checking for broken html (such as invalid tags)...
>[delete] Deleting directory
> /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build/jtidy_tmp
>  [echo] Checking for broken links...
>  [exec]
>  [exec] Crawl/parse...
>  [exec]
>  [exec] Verify...
>  [exec]
>  [exec]
> file:///build/docs/queries/org/apache/lucene/queries/payloads/PayloadNearQuery.PayloadNearSpanScorer.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/queries.payloads.PayloadNearQuery.PayloadSpans.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/queries.payloads.PayloadNearQuery.PayloadSpans.html
>  [exec]
>  [exec] Broken javadocs links were found!
>
> BUILD FAILED
> /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:794: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:101: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build.xml:138: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build.xml:151: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:2581:
> exec returned: 1
>
> Total time: 90 minutes 17 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

accessing Lucene package members from Solr

[Mikhail Khludnev]

Good day!

While working on SOLR-5743, which nobody wants to comment, I face the
problem.
Collector from Solr codebase should call package visible member:
o.a.l.s.join.ToParentBlockJoinQuery.BlockJoinScorer.swapChildDocs(int[])

I see the following alternatives:
- straightforwardly, make BlockJoinScorer.swapChildDocs(int[]) public;
- trickily add public class, which allows to call swapChildDocs() into
o.a.l.s.join. and call this accessor from Solr.
- meanly put Solr class in Solr codebase into lucene package o.a.l.s.join.

The context is that so far it seems like an experimental feature at 5.5,
and I can imagine that it will be removed in 6.0.Thus, the first option
seems more doubtful to me.

Which one will be healthier for Lucene?

--
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics

[jira] [Commented] (SOLR-8404) tweak SolrQueryResponse.getToLogAsString(String logid)

[ASF subversion and git services (JIRA)]

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

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

Commit 1719515 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1719515 ]

SOLR-8404: tweak SolrQueryResponse.getToLogAsString, add 
TestSolrQueryResponse.testToLog (merge in revision 1719503 from trunk)

> tweak SolrQueryResponse.getToLogAsString(String logid)
> --
>
> Key: SOLR-8404
> URL: https://issues.apache.org/jira/browse/SOLR-8404
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8404.patch
>
>
> Whilst extending {{TestSolrQueryResponse}} in SOLR-8388 I noticed that 
> {{getToLogAsString(String logid)}} returns {{"logidname1=value1 name2=value2 
> ... "}} instead of the {{"logid name1=value1 name2=value2 ..."}} indicated by 
> its comment.
> summary of changes in patch against trunk:
> * Added space separator between {{logid}} and {{toLog}} values.
> * Removed trailing space at the end.
> * Added {{TestSolrQueryResponse.testToLog}} test case.
> * Reviewed callers of the method and adjusted call arg for two of them.



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:52171/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:52171/solr/collection1
at 
__randomizedtesting.SeedInfo.seed([9E0EE637498D0567:5FC63B71E8EBD4CE]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590)
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.SolrRequest.process(SolrRequest.java:150)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:107)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:72)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:86)
at 
org.apache.solr.client.solrj.TestLBHttpSolrClient.addDocs(TestLBHttpSolrClient.java:115)
at 
org.apache.solr.client.solrj.TestLBHttpSolrClient.setUp(TestLBHttpSolrClient.java:101)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:905)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java: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:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 

[jira] [Resolved] (SOLR-8404) tweak SolrQueryResponse.getToLogAsString(String logid)

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-8404.
---
   Resolution: Fixed
Fix Version/s: 5.5
   Trunk

> tweak SolrQueryResponse.getToLogAsString(String logid)
> --
>
> Key: SOLR-8404
> URL: https://issues.apache.org/jira/browse/SOLR-8404
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: Trunk, 5.5
>
> Attachments: SOLR-8404.patch
>
>
> Whilst extending {{TestSolrQueryResponse}} in SOLR-8388 I noticed that 
> {{getToLogAsString(String logid)}} returns {{"logidname1=value1 name2=value2 
> ... "}} instead of the {{"logid name1=value1 name2=value2 ..."}} indicated by 
> its comment.
> summary of changes in patch against trunk:
> * Added space separator between {{logid}} and {{toLog}} values.
> * Removed trailing space at the end.
> * Added {{TestSolrQueryResponse.testToLog}} test case.
> * Reviewed callers of the method and adjusted call arg for two of them.



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

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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 47060 lines...]
-documentation-lint:
 [echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
   [delete] Deleting directory 
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/lucene/build/jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [echo] Checking for missing docs...
 [exec] 
 [exec] 
build/docs/test-framework/org/apache/lucene/index/package-summary.html
 [exec]   missing: ForceMergePolicy
 [exec] 
 [exec] Missing javadocs were found!

BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/build.xml:784: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/build.xml:101: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/lucene/build.xml:138: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/lucene/build.xml:154: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/lucene/common-build.xml:2508:
 exec returned: 1

Total time: 87 minutes 39 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

[jira] [Resolved] (LUCENE-6925) add (test-framework) [Random]ForceMergePolicy classes

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved LUCENE-6925.
-
   Resolution: Fixed
Fix Version/s: 5.5
   Trunk

> add (test-framework) [Random]ForceMergePolicy classes
> -
>
> Key: LUCENE-6925
> URL: https://issues.apache.org/jira/browse/LUCENE-6925
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: Trunk, 5.5
>
> Attachments: LUCENE-6925.patch
>
>
> lucene changes:
>  * {{ForceMergePolicy}} for disallowing background segment merges but 
> permitting optimize/forceMerge segment merges
>  * {{TestForceMergePolicy}}
> solr changes:
>  * {{RandomForceMergePolicy}} extending {{RandomMergePolicy}}
>  * {{TestRandomForceMergePolicy}}
> motivation:
>  * test cases e.g. for SOLR-5730 may wish to distinguish before-merge and 
> after-merge query results or behaviour



--
This message was sent by Atlassian 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 # 250 - Failure!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic

Error Message:
127.0.0.1:60755 failed to respond

Stack Trace:
org.apache.http.NoHttpResponseException: 127.0.0.1:60755 failed to respond
at 
__randomizedtesting.SeedInfo.seed([36A923FBA4324DBE:9D533EEE7BEECB90]:0)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
at 
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.lucene.replicator.http.HttpClientBase.executeGET(HttpClientBase.java:159)
at 
org.apache.lucene.replicator.http.HttpReplicator.checkForUpdate(HttpReplicator.java:51)
at 
org.apache.lucene.replicator.ReplicationClient.doUpdate(ReplicationClient.java:196)
at 
org.apache.lucene.replicator.ReplicationClient.updateNow(ReplicationClient.java:402)
at 
org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic(HttpReplicatorTest.java:122)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.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:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Commented] (SOLR-8383) SolrCore.java + QParserPlugin.java container initialCapacity tweaks

[ASF subversion and git services (JIRA)]

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

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

Commit 1719404 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1719404 ]

SOLR-8383: SolrCore.java + QParserPlugin.java container initialCapacity tweaks 
(merge in revision 1719342 from trunk)

> SolrCore.java + QParserPlugin.java container initialCapacity tweaks
> ---
>
> Key: SOLR-8383
> URL: https://issues.apache.org/jira/browse/SOLR-8383
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8383.patch, SOLR-8383.patch
>
>
> patch against trunk to follow



--
This message was sent by Atlassian 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-8383) SolrCore.java + QParserPlugin.java container initialCapacity tweaks

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-8383.
---
   Resolution: Fixed
Fix Version/s: 5.5
   Trunk

> SolrCore.java + QParserPlugin.java container initialCapacity tweaks
> ---
>
> Key: SOLR-8383
> URL: https://issues.apache.org/jira/browse/SOLR-8383
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: Trunk, 5.5
>
> Attachments: SOLR-8383.patch, SOLR-8383.patch
>
>
> patch against trunk to follow



--
This message was sent by Atlassian 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-7904) Make FacetStream Expressible

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-7904:
---

I'm finalizing some of the tests but so far everything is passing fine. The 
expression format is as follows
{code}
facet(
  collection1,
  q="*:*",
  fl="a_s,a_i,a_f",
  sort="a_s asc",
  buckets="a_s",
  bucketSorts="sum(a_i) asc",
  bucketSizeLimit=10,
  sum(a_i), sum(a_f),
  min(a_i), min(a_f),
  max(a_i), max(a_f),
  avg(a_i), avg(a_f),
  count(*),
  zkHost="url:port"
)
{code}
It supports multiple buckets and multiple bucketSorts. All standard query 
properties (q, fl, sort, etc...) are also supported. The example above is only 
showing 3 of them. zkHost is optional.

> Make FacetStream Expressible
> 
>
> Key: SOLR-7904
> URL: https://issues.apache.org/jira/browse/SOLR-7904
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Joel Bernstein
> Fix For: Trunk
>
>
> This ticket makes the FacetStream (SOLR-7903) expressible, so it can be used 
> as a Streaming Expression.



--
This message was sent by Atlassian 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-8404) tweak SolrQueryResponse.getToLogAsString(String logid)

[ASF subversion and git services (JIRA)]

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

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

Commit 1719503 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1719503 ]

SOLR-8404: tweak SolrQueryResponse.getToLogAsString, add 
TestSolrQueryResponse.testToLog (Christine Poerschke)

> tweak SolrQueryResponse.getToLogAsString(String logid)
> --
>
> Key: SOLR-8404
> URL: https://issues.apache.org/jira/browse/SOLR-8404
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8404.patch
>
>
> Whilst extending {{TestSolrQueryResponse}} in SOLR-8388 I noticed that 
> {{getToLogAsString(String logid)}} returns {{"logidname1=value1 name2=value2 
> ... "}} instead of the {{"logid name1=value1 name2=value2 ..."}} indicated by 
> its comment.
> summary of changes in patch against trunk:
> * Added space separator between {{logid}} and {{toLog}} values.
> * Removed trailing space at the end.
> * Added {{TestSolrQueryResponse.testToLog}} test case.
> * Reviewed callers of the method and adjusted call arg for two of them.



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

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

[jira] [Created] (SOLR-8405) bin/solr (and its cmd sibling) should pass thru -X options as it does with -D

[Timothy Potter (JIRA)]

Timothy Potter created SOLR-8405:


 Summary: bin/solr (and its cmd sibling) should pass thru -X 
options as it does with -D
 Key: SOLR-8405
 URL: https://issues.apache.org/jira/browse/SOLR-8405
 Project: Solr
  Issue Type: Bug
  Components: scripts and tools
Affects Versions: 5.3, 5.2.1, 5.2, 5.1, 5.0, 5.4
 Environment: all
Reporter: Timothy Potter
Priority: Minor


Currently the bin/solr scripts pass any options that being with -D on to the 
JVM directly. It should to the same for -X vs. having to put -X inside of -a 



--
This message was sent by Atlassian 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-5743) Faceting with BlockJoin support

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-5743:
---
Attachment: SOLR-5743.patch

Revamped the patch [^SOLR-5743.patch]. Caveat, bitwise ticks! Now it provides 
both approaches:
* BlockJoinFacetComponent - enforces searching by NO_CHECK_QCACHE obtains child 
matches via BlockJoinScorer.swapChildDocs(int[]) see ChildTrackingCollector in 
the patch.
*  BlockJoinFacetDocSetComponent - it works more like Solr with toplevel doc 
sets
I think to include both components into 5.5 disabled by default to let users to 
experiment. 
remaining TODOs:
* exclude parent docs from faceting 
* now it hardcoded to mincount=1, either set to 0 or copypaste mincount params 
logic
* improve simple test to handle edge cases with fields and hits.

Any concerns? 

> Faceting with BlockJoin support
> ---
>
> Key: SOLR-5743
> URL: https://issues.apache.org/jira/browse/SOLR-5743
> Project: Solr
>  Issue Type: New Feature
>  Components: faceting
>Reporter: abipc
>Assignee: Mikhail Khludnev
>  Labels: features
> Fix For: 5.5
>
> Attachments: SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch
>
>
> For a sample inventory(note - nested documents) like this -   
>  
> 10
> parent
> Nike
> 
> 11
> Red
> XL
> 
> 
> 12
> Blue
> XL
> 
> 
> Faceting results must contain - 
> Red(1)
> XL(1) 
> Blue(1) 
> for a "q=*" query. 
> PS : The inventory example has been taken from this blog - 
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html



--
This message was sent by Atlassian 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-8406) AddSchemaFieldsUpdateProcessorFactory should handle list fields better

[Timothy Potter (JIRA)]

Timothy Potter created SOLR-8406:


 Summary: AddSchemaFieldsUpdateProcessorFactory should handle list 
fields better
 Key: SOLR-8406
 URL: https://issues.apache.org/jira/browse/SOLR-8406
 Project: Solr
  Issue Type: Improvement
  Components: Data-driven Schema
Reporter: Timothy Potter


paraphrasing from offline discussion with Hossman:

bq. when AddSchemaFieldsUpdateProcessorFactory mappings refer to fieldtypes 
that are multivalued=false, it should either skip that mapping, or explicitly 
specify multivalued=true, when a document with values matching that mapping 
contains multiple values

basically, I'm submitting a document with foo = [ "bar", "baz" ] and field 
guessing doesn't figure out that foo is multi-valued unless my default is set 
to strings ... 





--
This message was sent by Atlassian 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: Nested document query with wrong numFound value

[Mikhail Khludnev]

Ok. I got it. SolrCloud relies on uniqueKey (id) for merging shard results,
but in your examples it doesn't work, because nested documents disables
this. And you have duplicates, which make merge heap mad:

false}
},response={numFound=11,start=0,maxScore=1.0,docs=[SolrDocument{id=31814269823181426982280,
score=1.0}, SolrDocument{id=31814269823181426982280, score=1.0},
SolrDocument{id=31814269823181426982280, score=1.0},
SolrDocument{id=31814269823181426982280, score=1.0},
SolrDocument{id=31814269823181426982280, score=1.0},
SolrDocument{id=31814269823181426982281, score=1.0},
SolrDocument{id=31814269823181426982281, score=1.0},
SolrDocument{id=31814269823181426982281, score=1.0},
SolrDocument{id=31814269823181426982281, score=1.0},

Yago, you encounter a quite curious fact. Congratulation!
You can only retrieve parent document with SolrCloud, hence use {!parent
..}.. of fq=type:parent.

ccing Devs:
Shouldn't it prosecute ID dupes explicitly? Is it a known feature?


On Fri, Dec 11, 2015 at 5:08 PM, Yago Riveiro 
wrote:

> This:
>
>
>
>
>
> {
>
>
> responseHeader: {
>
>
> status: 0,
>
>
> QTime: 10,
>
>
> params: {
>
>
> q: "id:3181426982318142698228*",
>
>
> debugQuery: "true"
>
>
> }
>
>
> },
>
>
> response: {
>
>
> numFound: 3,
>
>
> start: 0,
>
>
> maxScore: 1,
>
>
> docs: [{
>
>
> id: "31814269823181426982280",
>
>
> child_type: "ecommerce_product",
>
>
> qty: 1,
>
>
> product_price: 49.99
>
>
> }, {
>
>
> id: "31814269823181426982281",
>
>
> child_type: "ecommerce_product",
>
>
> qty: 1,
>
>
> product_price: 139.9
>
>
> }]
>
>
> },
>
>
> debug: {
>
>
> track: {
>
>
> rid:
> "node-01-ecommerce-15_shard1_replica2-1449842438070-0",
>
>
> EXECUTE_QUERY: {
>
>
> http:
> //node-17:8983/solr/ecommerce-15_shard2_replica1/: {
>
>
> QTime: "0",
>
>
> ElapsedTime: "2",
>
>
> RequestPurpose: "GET_TOP_IDS",
>
>
> NumFound: "0",
>
>
> Response:
> "{responseHeader={status=0,QTime=0,params={df=_text_,distrib=false,debug=[false,
> timing, track],qt=/query,fl=[id,
> score],shards.purpose=4,start=0,fsv=true,shard.url=
> http://node-17:8983/solr/ecommerce-15_shard2_replica1/,rid=node-01-ecommerce-15_shard1_replica2-1449842438070-0,rows=10,version=2,q=id:3181426982318142698228*,requestPurpose=GET_TOP_IDS,NOW=1449842438070,isShard=true,wt=javabin,debugQuery=false}
> },response={numFound=0,start=0,maxScore=0.0,docs=[]},sort_values={},debug={timing={time=0.0,prepare={time=0.0,query={time=0.0},facet={time=0.0},facet_module={time=0.0},mlt={time=0.0},highlight={time=0.0},stats={time=0.0},expand={time=0.0},debug={time=0.0}},process={time=0.0,query={time=0.0},facet={time=0.0},facet_module={time=0.0},mlt={time=0.0},highlight={time=0.0},stats={time=0.0},expand={time=0.0},debug={time=0.0}"
>
>
> },
>
>
> http:
> //node-01:8983/solr/ecommerce-15_shard1_replica2/: {
>
>
> QTime: "0",
>
>
> ElapsedTime: "2",
>
>
> RequestPurpose: "GET_TOP_IDS",
>
>
> NumFound: "11",
>
>
> Response:
> "{responseHeader={status=0,QTime=0,params={df=_text_,distrib=false,debug=[false,
> timing, track],qt=/query,fl=[id,
> score],shards.purpose=4,start=0,fsv=true,shard.url=
> http://node-01:8983/solr/ecommerce-15_shard1_replica2/,rid=node-01-ecommerce-15_shard1_replica2-1449842438070-0,rows=10,version=2,q=id:3181426982318142698228*,requestPurpose=GET_TOP_IDS,NOW=1449842438070,isShard=true,wt=javabin,debugQuery=false}},response={numFound=11,start=0,maxScore=1.0,docs=[SolrDocument{id=31814269823181426982280,
> score=1.0}, SolrDocument{id=31814269823181426982280, score=1.0},
> SolrDocument{id=31814269823181426982280, score=1.0},
> SolrDocument{id=31814269823181426982280, score=1.0},
> SolrDocument{id=31814269823181426982280, score=1.0},
> SolrDocument{id=31814269823181426982281, score=1.0},
> SolrDocument{id=31814269823181426982281, score=1.0},
> SolrDocument{id=31814269823181426982281, score=1.0},
> 

[jira] [Commented] (LUCENE-6815) Should DisjunctionScorer advance more lazily?

[ASF subversion and git services (JIRA)]

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

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

Commit 1719490 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1719490 ]

LUCENE-6815: Make DisjunctionScorer advance lazily.

> Should DisjunctionScorer advance more lazily?
> -
>
> Key: LUCENE-6815
> URL: https://issues.apache.org/jira/browse/LUCENE-6815
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6815.patch, LUCENE-6815.patch, LUCENE-6815.patch
>
>
> Today if you call DisjunctionScorer.advance(X), it will try to advance all 
> sub scorers to X. However, if DisjunctionScorer is being intersected with 
> another scorer (which is almost always the case as we use BooleanScorer for 
> top-level disjunctions), we could stop as soon as we find one matching sub 
> scorer, and only advance the remaining sub scorers when freq() or score() is 
> called. 



--
This message was sent by Atlassian 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-8409) Complex q param in Streaming Expression results in a bad query

[Dennis Gove (JIRA)]

Dennis Gove created SOLR-8409:
-

 Summary: Complex q param in Streaming Expression results in a bad 
query
 Key: SOLR-8409
 URL: https://issues.apache.org/jira/browse/SOLR-8409
 Project: Solr
  Issue Type: Bug
  Components: SolrJ
Reporter: Dennis Gove
Priority: Minor






--
This message was sent by Atlassian 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-8125) Umbrella ticket for Streaming and SQL issues

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8125:
--

Sounds good. We've got a couple months for bug fixing and testing.

I'll probably be focused on testing and documentation mainly after wrapping up 
the last few issues I mentioned. 

> Umbrella ticket for Streaming and SQL issues
> 
>
> Key: SOLR-8125
> URL: https://issues.apache.org/jira/browse/SOLR-8125
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Joel Bernstein
>
> This is an umbrella ticket for tracking issues around the *Streaming API*, 
> *Streaming Expressions* and *Parallel SQL*.
> Issues can be linked to this ticket and discussions about the road map can 
> also happen on this ticket.



--
This message was sent by Atlassian 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 # 250 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/250/
Java: multiarch/jdk1.7.0 -d64 -XX:+UseCompressedOops -XX:+UseSerialGC

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

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

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node2:{"node_name":"127.0.0.1:57673_ksox%2Fcl","core":"c8n_1x3_lf_shard1_replica3","state":"active","base_url":"http://127.0.0.1:57673/ksox/cl","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={
  "maxShardsPerNode":"1",
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "node_name":"127.0.0.1:35892_ksox%2Fcl",
  "core":"c8n_1x3_lf_shard1_replica2",
  "state":"down",
  "base_url":"http://127.0.0.1:35892/ksox/cl"},
"core_node2":{
  "node_name":"127.0.0.1:57673_ksox%2Fcl",
  "core":"c8n_1x3_lf_shard1_replica3",
  "state":"active",
  "base_url":"http://127.0.0.1:57673/ksox/cl;,
  "leader":"true"},
"core_node3":{
  "state":"down",
  "base_url":"http://127.0.0.1:53194/ksox/cl;,
  "core":"c8n_1x3_lf_shard1_replica1",
  "node_name":"127.0.0.1:53194_ksox%2Fcl",
  "router":{"name":"compositeId"},
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([F705440E23529F77:7F517BD48DAEF28F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:171)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:56)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
  

[JENKINS-EA] Lucene-Solr-5.4-Linux (32bit/jdk-9-ea+95) - Build # 370 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.4-Linux/370/
Java: 32bit/jdk-9-ea+95 -server -XX:+UseSerialGC -XX:-CompactStrings

3 tests failed.
FAILED:  org.apache.solr.handler.dataimport.TestTikaEntityProcessor.testSkip

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([775AA979A34D1784:B13501EA93072D83]:0)
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:146)
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:256)
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:256)
at 
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:120)
at 
org.apache.solr.handler.dataimport.TikaEntityProcessor.nextRow(TikaEntityProcessor.java:159)
at 
org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:244)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:476)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:415)
at 
org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:330)
at 
org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:233)
at 
org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:417)
at 
org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:481)
at 
org.apache.solr.handler.dataimport.DataImportHandler.handleRequestBody(DataImportHandler.java:186)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073)
at org.apache.solr.util.TestHarness.query(TestHarness.java:311)
at 
org.apache.solr.handler.dataimport.AbstractDataImportHandlerTestCase.runFullImport(AbstractDataImportHandlerTestCase.java:87)
at 
org.apache.solr.handler.dataimport.TestTikaEntityProcessor.testSkip(TestTikaEntityProcessor.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java: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:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
   

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 47409 lines...]
-documentation-lint:
 [echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
   [delete] Deleting directory 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [echo] Checking for missing docs...
 [exec] 
 [exec] 
build/docs\test-framework\org\apache\lucene\index/package-summary.html
 [exec]   missing: ForceMergePolicy
 [exec] 
 [exec] Missing javadocs were found!

BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:784: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:101: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:138: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:154: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:2508:
 exec returned: 1

Total time: 88 minutes 56 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