[jira] [Commented] (SOLR-12322) Select specific field list for child documents using ChildDocTransformerFactory

2018-05-07 Thread Mikhail Khludnev (JIRA)

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

Mikhail Khludnev commented on SOLR-12322:
-

I don't really understand how [^doc_level_exaplantion.docx] answers my question 
(what can't be done with \[subquery]?). If it's returning parents without 
children, it can be done with {{fq}} on subquery level. Statements about 
termcount still is not clear, how the proposed patch address it?   

> Select specific field list for child documents using 
> ChildDocTransformerFactory
> ---
>
> Key: SOLR-12322
> URL: https://issues.apache.org/jira/browse/SOLR-12322
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers, search
>Affects Versions: 6.6
>Reporter: adeppa
>Priority: Minor
> Fix For: 6.6
>
> Attachments: SOLR-12322.patch, doc_level_exaplantion.docx
>
>
> With the current version of SOLR and nested indexing, when you are fetch a 
> parent record it returns all the fields of its children. This is increasing 
> the size of data being returned from SOLR and also hits our performance 
> sometime.
> This ticket will be used to update the ChildDocTransformerFactory class with 
> additional parameters to specify the list of fields to be pulled for child 
> documents.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12298) Index Full nested document Hierarchy For Queries (umbrella issue)

2018-05-07 Thread mosh (JIRA)

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

mosh commented on SOLR-12298:
-

David you have some really strong points.

Firstly,
While it is true __childDocument__ is not required, sometimes the JSON you get 
is not an array, but a child document, e.g.
{code:java}
{ "id": "X998_Y998", "from": { "name": "Peyton Manning", "id": "X18" }, 
"message": "Where's my contract?", "actions": [ { "name": "Comment", "link": 
"http://www.facebook.com/X998/posts/Y998; }, { "name": "Like", "link": 
"http://www.facebook.com/X998/posts/Y998; } ], "type": "status", 
"created_time": "2010-08-02T21:27:44+", "updated_time": 
"2010-08-02T21:27:44+" }
{code}
This is a sample Facebook API response. The array syntax will index the array 
as child documents, but it will not index the child document under the key 
"from"
{code:java}
 { "from": { "name": "Peyton Manning", "id": "X18" } } {code}
It would be nice if you could just index JSON as is, like you can in elastic 
search, moving the responsibility from the user to Solr itself.
This feature could also be added to the XML loader if needed, to enable feature 
equality. After this change the is introduced to the data loaders, the rest can 
be done using an URP, as long as the loaders add the needed metadata for the 
URP to add the required fields.

Afterwards, a new transformer could be introduced that rebuilds the whole JSON 
structure, including the full original hierarchy.

On the other hand, adding a SolrInputDocument as a supported field could be the 
better way to go, making most of the logic "hack" redundant and unneeded. 
Perhaps you are right, and this is the better choice in the long run.

> Index Full nested document Hierarchy For Queries (umbrella issue)
> -
>
> Key: SOLR-12298
> URL: https://issues.apache.org/jira/browse/SOLR-12298
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
>
> Solr ought to have the ability to index deeply nested objects, while storing 
> the original document hierarchy.
>  Currently the client has to index the child document's full path and level 
> to manually reconstruct the original document structure, since the children 
> are flattened and returned in the reserved "__childDocuments__" key.
> Ideally you could index a nested document, having Solr transparently add the 
> required fields while providing a document transformer to rebuild the 
> original document's hierarchy.
>  
> This issue is an umbrella issue for the particular tasks that will make it 
> all happen – either subtasks or issue linking.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk-9.0.4) - Build # 33 - Unstable!

2018-05-07 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/33/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.rest.TestManagedResourceStorage

Error Message:
SolrCore.getOpenCount()==2

Stack Trace:
java.lang.RuntimeException: SolrCore.getOpenCount()==2
at __randomizedtesting.SeedInfo.seed([E7AB18C3973B3046]:0)
at org.apache.solr.util.TestHarness.close(TestHarness.java:379)
at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:801)
at 
org.apache.solr.cloud.AbstractZkTestCase.azt_afterClass(AbstractZkTestCase.java:147)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:897)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
junit.framework.TestSuite.org.apache.solr.rest.TestManagedResourceStorage

Error Message:
4 threads leaked from SUITE scope at 
org.apache.solr.rest.TestManagedResourceStorage: 1) Thread[id=17721, 
name=Thread-3920, state=WAITING, group=TGRP-TestManagedResourceStorage] 
at java.base@9.0.4/java.lang.Object.wait(Native Method) at 
java.base@9.0.4/java.lang.Thread.join(Thread.java:1353) at 
java.base@9.0.4/java.lang.Thread.join(Thread.java:1427) at 
app//org.apache.zookeeper.server.NIOServerCnxnFactory.join(NIOServerCnxnFactory.java:313)
 at 
app//org.apache.solr.cloud.ZkTestServer$ZKServerMain.runFromConfig(ZkTestServer.java:313)
 at 
app//org.apache.solr.cloud.ZkTestServer$2.run(ZkTestServer.java:496)2) 
Thread[id=17723, name=SessionTracker, state=TIMED_WAITING, 
group=TGRP-TestManagedResourceStorage] at 
java.base@9.0.4/java.lang.Object.wait(Native Method) at 
app//org.apache.zookeeper.server.SessionTrackerImpl.run(SessionTrackerImpl.java:147)
3) Thread[id=17722, name=NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0, 
state=RUNNABLE, group=TGRP-TestManagedResourceStorage] at 
java.base@9.0.4/sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) 
at 
java.base@9.0.4/sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:265)   
  at 
java.base@9.0.4/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:92)
 at 
java.base@9.0.4/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)   
  at java.base@9.0.4/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)   
  at 
app//org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:196)
 at java.base@9.0.4/java.lang.Thread.run(Thread.java:844)4) 
Thread[id=17725, name=ProcessThread(sid:0 cport:36081):, state=WAITING, 
group=TGRP-TestManagedResourceStorage] at 
java.base@9.0.4/jdk.internal.misc.Unsafe.park(Native Method) at 

[JENKINS] Lucene-Solr-repro - Build # 590 - Unstable

2018-05-07 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-repro/590/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/214/consoleText

[repro] Revision: b72af046c5bd04eec4e84700a2ee20ab5a833e39

[repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9
[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testTrigger -Dtests.seed=BDC3D8125D4F03FD -Dtests.multiplier=2 
-Dtests.locale=mk -Dtests.timezone=Etc/GMT-13 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testSplitIntegration -Dtests.seed=BDC3D8125D4F03FD 
-Dtests.multiplier=2 -Dtests.locale=mk -Dtests.timezone=Etc/GMT-13 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testMergeIntegration -Dtests.seed=BDC3D8125D4F03FD 
-Dtests.multiplier=2 -Dtests.locale=mk -Dtests.timezone=Etc/GMT-13 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
08ee037ff8cc1edee87c14424d5a5a479ad2adf5
[repro] git fetch

[...truncated 2 lines...]
[repro] git checkout b72af046c5bd04eec4e84700a2ee20ab5a833e39

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   IndexSizeTriggerTest
[repro] ant compile-test

[...truncated 3316 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.IndexSizeTriggerTest" -Dtests.showOutput=onerror 
-DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 
-Dtests.seed=BDC3D8125D4F03FD -Dtests.multiplier=2 -Dtests.locale=mk 
-Dtests.timezone=Etc/GMT-13 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[...truncated 7658 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   4/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest
[repro] git checkout 08ee037ff8cc1edee87c14424d5a5a479ad2adf5

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 5 lines...]

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

[jira] [Commented] (SOLR-12321) Use of builtin java serialization for admin response breaks 7.3 compatibility

2018-05-07 Thread Mark Miller (JIRA)

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

Mark Miller commented on SOLR-12321:


Yeah, this should have been done by serializing the response map itself with 
JavaBin or something. There is always a better option than built in Java 
serialization. I actually reviewed this and put it in way back, so it's my 
fault. We should have pulled the map from the object and serialized that with 
JavaBin or stored it as JSON or or or.

> Use of builtin java serialization for admin response breaks 7.3 compatibility
> -
>
> Key: SOLR-12321
> URL: https://issues.apache.org/jira/browse/SOLR-12321
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3, 7.3.1
>Reporter: Will Currie
>Priority: Minor
>
> Premise: During an upgrade I should be able to run a 7.3 pull replica against 
> a 7.2 tlog leader. Or vice versa.
>  
> Adding a new method[1] to SolrResponse has broken binary compatibility. When 
> I try to register a new pull replica using the admin api[2] I get an HTTP 500 
> responseI see this error logged: java.io.InvalidClassException: 
> org.apache.solr.client.solrj.SolrResponse; local class incompatible: stream 
> classdesc serialVersionUID = 3945300637328478755, local class 
> serialVersionUID = -793110010336024264
>  
> The replica actually seems to register ok it just can't read the response 
> because the bytes from the 7.2 leader include a different serialVersionUID. 
>  
> Should SolrResponse include a serialVersionIUID? All subclasses too.
> [~markrmil...@gmail.com]'s advice is that the project should never use 
> builtin java serialization.
>  
> It looks like stock java serialization is only used for these admin 
> responses. Query responses use JavaBinCodec instead..
>  
> Full(ish) stack trace:
> {noformat}
> ERROR HttpSolrCall null:org.apache.solr.common.SolrException: 
> java.io.InvalidClassException: org.apache.solr.client.solrj.SolrResponse; 
> local class incompatible: st
> ream classdesc serialVersionUID = 3945300637328478755, local class 
> serialVersionUID = -7931100103360242645
>     at 
> org.apache.solr.client.solrj.SolrResponse.deserialize(SolrResponse.java:73)
>     at 
> org.apache.solr.handler.admin.CollectionsHandler.sendToOCPQueue(CollectionsHandler.java:348)
>     at 
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:256)
>     at 
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:230)
>     at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
>     at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:736)
>     at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717)
>     at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:498)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)
>  {noformat}
>  
> [1] 
> [https://github.com/apache/lucene-solr/commit/5ce83237e804ac1130eaf5cf793955667793fee0#diff-b809fa594f93aa6805381029a188e4e2R46]
> [2] 
> [http://localhost:8983/solr/admin/collections?action=ADDREPLICA=blah=shard1=blah=pull]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12209) add Paging Streaming Expression

2018-05-07 Thread Lucene/Solr QA (JIRA)

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

Lucene/Solr QA commented on SOLR-12209:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  3m 
45s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m 
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  2m 59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  2m 59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  2m 59s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 11m 
13s{color} | {color:green} solrj in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 25m 46s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12209 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12922219/SOLR-12209.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 08ee037 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| Default Java | 1.8.0_172 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/85/testReport/ |
| modules | C: solr/solrj U: solr/solrj |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/85/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> add Paging Streaming Expression
> ---
>
> Key: SOLR-12209
> URL: https://issues.apache.org/jira/browse/SOLR-12209
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Affects Versions: 7.3
>Reporter: mosh
>Priority: Major
> Attachments: 0001-added-skip-and-limit-stream-decorators.patch, 
> SOLR-12209.patch, SOLR-12209.patch
>
>
> Currently the closest streaming expression that allows some sort of 
> pagination is top.
> I propose we add a new streaming expression, which is based on the 
> RankedStream class to add offset to the stream. currently it can only be done 
> in code by reading the stream until the desired offset is reached.
> The new expression will be used as such:
> {{paging(rows=3, search(collection1, q="*:*", qt="/export", 
> fl="id,a_s,a_i,a_f", sort="a_f desc, a_i desc"), sort="a_f asc, a_i asc", 
> start=100)}}
> {{this will offset the returned stream by 100 documents}}
>  
> [~joel.bernstein] what to you think?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12055) Enable asynch logging by default

2018-05-07 Thread Mark Miller (JIRA)

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

Mark Miller commented on SOLR-12055:


If we enable it by default we should loudly point out one of the the downsides 
that could affect some users negatively - particularly anyone counting on 
logging for auditing.

> Enable asynch logging by default
> 
>
> Key: SOLR-12055
> URL: https://issues.apache.org/jira/browse/SOLR-12055
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> When SOLR-7887 is done, switching to asynch logging will be a simple change 
> to the config files for log4j2. This will reduce contention and increase 
> throughput generally and logging in particular.
> There's a discussion of the pros/cons here: 
> https://logging.apache.org/log4j/2.0/manual/async.html
> An alternative is to put a note in the Ref Guide about how to enable async 
> logging.
> I guess even if we enable async by default the ref guide still needs a note 
> about how to _disable_ it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-11881) Connection Reset Causing LIR

2018-05-07 Thread Mark Miller (JIRA)

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

Mark Miller commented on SOLR-11881:


Patch looks nice [~tomasflobbe] - very clean.

> Connection Reset Causing LIR
> 
>
> Key: SOLR-11881
> URL: https://issues.apache.org/jira/browse/SOLR-11881
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11881-SolrCmdDistributor.patch, SOLR-11881.patch, 
> SOLR-11881.patch
>
>
> We can see that a connection reset is causing LIR.
> If a leader -> replica update get's a connection like this the leader will 
> initiate LIR
> {code:java}
> 2018-01-08 17:39:16.980 ERROR (qtp1010030701-468988) [c:collection s:shardX 
> r:core_node56 collection_shardX_replicaY] 
> o.a.s.u.p.DistributedUpdateProcessor Setting up to try to start recovery on 
> replica https://host08.domain:8985/solr/collection_shardX_replicaY/
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
> at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
> at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
> at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
> at 
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
> at 
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
> at 
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
> at 
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
> 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:55)
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:312)
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:185)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> From https://issues.apache.org/jira/browse/SOLR-6931 Mark says "On a heavy 
> working SolrCloud cluster, even a rare response like this from a replica can 
> cause a recovery and heavy cluster disruption" .
> Looking at SOLR-6931 we added a http retry handler but we only retry on GET 
> requests. Updates are POST requests 
> {{ConcurrentUpdateSolrClient#sendUpdateStream}}
> Update requests between the leader and replica should be retry-able since 
> they have been versioned.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12303) Subquery Doc transform doesn't inherit path from original request

2018-05-07 Thread Lucene/Solr QA (JIRA)

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

Lucene/Solr QA commented on SOLR-12303:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 3 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
23s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m 
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  2m 30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  2m 20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  2m 20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} | 
{color:green}  2m 20s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}182m 43s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}193m 20s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.autoscaling.IndexSizeTriggerTest |
|   | solr.cloud.TestRandomFlRTGCloud |
|   | solr.cloud.autoscaling.sim.TestGenericDistributedQueue |
|   | solr.security.hadoop.TestSolrCloudWithHadoopAuthPlugin |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12303 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12922284/SOLR-12303.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  validaterefguide  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 3e8f31e |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_172 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/84/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/84/testReport/ |
| modules | C: solr/core solr/solr-ref-guide U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/84/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, 
> SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, 
> SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId 
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
>  qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request 
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should 
> be an option to override this behavior. (option to override is already 
> available by specifying *qt*)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-NightlyTests-7.3 - Build # 22 - Still Unstable

2018-05-07 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.3/22/

2 tests failed.
FAILED:  org.apache.solr.cloud.RestartWhileUpdatingTest.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([A1301A2097C7DAD]:0)


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

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

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




Build Log:
[...truncated 15360 lines...]
   [junit4] Suite: org.apache.solr.cloud.RestartWhileUpdatingTest
   [junit4]   2> 3831694 INFO  
(SUITE-RestartWhileUpdatingTest-seed#[A1301A2097C7DAD]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> Creating dataDir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/build/solr-core/test/J1/temp/solr.cloud.RestartWhileUpdatingTest_A1301A2097C7DAD-001/init-core-data-001
   [junit4]   2> 3831711 WARN  
(SUITE-RestartWhileUpdatingTest-seed#[A1301A2097C7DAD]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=25 numCloses=25
   [junit4]   2> 3831713 INFO  
(SUITE-RestartWhileUpdatingTest-seed#[A1301A2097C7DAD]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=true
   [junit4]   2> 3831727 INFO  
(SUITE-RestartWhileUpdatingTest-seed#[A1301A2097C7DAD]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 3831728 INFO  
(SUITE-RestartWhileUpdatingTest-seed#[A1301A2097C7DAD]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /h/
   [junit4]   2> 3831731 INFO  
(TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 3831772 INFO  (Thread-9567) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 3831772 INFO  (Thread-9567) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 3831792 ERROR (Thread-9567) [] o.a.z.s.ZooKeeperServer 
ZKShutdownHandler is not registered, so ZooKeeper server won't take any action 
on ERROR or SHUTDOWN server state changes
   [junit4]   2> 3831890 INFO  
(TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] 
o.a.s.c.ZkTestServer start zk server on port:41496
   [junit4]   2> 3831934 INFO  (zkConnectionManagerCallback-2648-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 3832040 INFO  (zkConnectionManagerCallback-2650-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 3832043 INFO  
(TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] 
o.a.s.c.AbstractZkTestCase put 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 3832057 INFO  
(TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] 
o.a.s.c.AbstractZkTestCase put 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/core/src/test-files/solr/collection1/conf/schema15.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 3832058 INFO  
(TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] 
o.a.s.c.AbstractZkTestCase put 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 3832059 INFO  
(TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] 
o.a.s.c.AbstractZkTestCase put 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/core/src/test-files/solr/collection1/conf/stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 3832077 INFO  
(TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] 
o.a.s.c.AbstractZkTestCase put 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/core/src/test-files/solr/collection1/conf/protwords.txt
 to /configs/conf1/protwords.txt
   [junit4]   2> 3832078 INFO  
(TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] 
o.a.s.c.AbstractZkTestCase put 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/core/src/test-files/solr/collection1/conf/currency.xml
 to /configs/conf1/currency.xml
   [junit4]   2> 3832079 INFO  
(TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] 
o.a.s.c.AbstractZkTestCase put 

[jira] [Commented] (SOLR-11881) Connection Reset Causing LIR

2018-05-07 Thread Mark Miller (JIRA)

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

Mark Miller commented on SOLR-11881:


Yeah, I'd be hesitant to add retries to DBQ without input from 
[~ysee...@gmail.com].

> Connection Reset Causing LIR
> 
>
> Key: SOLR-11881
> URL: https://issues.apache.org/jira/browse/SOLR-11881
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11881-SolrCmdDistributor.patch, SOLR-11881.patch, 
> SOLR-11881.patch
>
>
> We can see that a connection reset is causing LIR.
> If a leader -> replica update get's a connection like this the leader will 
> initiate LIR
> {code:java}
> 2018-01-08 17:39:16.980 ERROR (qtp1010030701-468988) [c:collection s:shardX 
> r:core_node56 collection_shardX_replicaY] 
> o.a.s.u.p.DistributedUpdateProcessor Setting up to try to start recovery on 
> replica https://host08.domain:8985/solr/collection_shardX_replicaY/
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
> at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
> at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
> at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
> at 
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
> at 
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
> at 
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
> at 
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
> 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:55)
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:312)
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:185)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> From https://issues.apache.org/jira/browse/SOLR-6931 Mark says "On a heavy 
> working SolrCloud cluster, even a rare response like this from a replica can 
> cause a recovery and heavy cluster disruption" .
> Looking at SOLR-6931 we added a http retry handler but we only retry on GET 
> requests. Updates are POST requests 
> {{ConcurrentUpdateSolrClient#sendUpdateStream}}
> Update requests between the leader and replica should be retry-able since 
> they have been versioned.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-11881) Connection Reset Causing LIR

2018-05-07 Thread JIRA

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

Tomás Fernández Löbbe commented on SOLR-11881:
--

I updated the CR with a new patch. Added a test for minRf, but this is more 
deeply tested in ReplicationFactorTest (that test now takes longer because of 
the retries. I'm thinking in either making the wait time configurable or modify 
it for test purposes only). ReplicationFactorTest is marked as {{@BadApple}} 
pointing to SOLR-6944, this retry logic will probably fix that one. I haven't 
seen failures of that test so far.
There is one nocommit in the code, I'm wondering if we want to keep the retries 
for DBQs. I'm thinking in setting the retry count for DBQs to 0, since those 
are not versioned AFAIK.
Another thing I noticed is that we sleep after each error retried (so if we 
need to retry two requests to two hosts, we sleep before the first request, and 
sleep before the second one). This seems odd, I think we want to sleep before 
retrying a batch of errors. I won't be changing this here though, I'll create a 
new Jira for that.
I'll be running some tests with the current patch, feel free to review and let 
me know if you have any thoughts

> Connection Reset Causing LIR
> 
>
> Key: SOLR-11881
> URL: https://issues.apache.org/jira/browse/SOLR-11881
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11881-SolrCmdDistributor.patch, SOLR-11881.patch, 
> SOLR-11881.patch
>
>
> We can see that a connection reset is causing LIR.
> If a leader -> replica update get's a connection like this the leader will 
> initiate LIR
> {code:java}
> 2018-01-08 17:39:16.980 ERROR (qtp1010030701-468988) [c:collection s:shardX 
> r:core_node56 collection_shardX_replicaY] 
> o.a.s.u.p.DistributedUpdateProcessor Setting up to try to start recovery on 
> replica https://host08.domain:8985/solr/collection_shardX_replicaY/
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
> at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
> at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
> at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
> at 
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
> at 
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
> at 
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
> at 
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
> 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:55)
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:312)
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:185)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> From https://issues.apache.org/jira/browse/SOLR-6931 Mark says "On a heavy 
> working SolrCloud cluster, even a rare response like this from a replica can 
> cause a recovery and heavy cluster disruption" .
> Looking at SOLR-6931 we added a http retry handler but we only retry on GET 
> requests. Updates are POST requests 
> {{ConcurrentUpdateSolrClient#sendUpdateStream}}
> Update requests between the leader and replica should be retry-able since 
> 

[jira] [Commented] (SOLR-12322) Select specific field list for child documents using ChildDocTransformerFactory

2018-05-07 Thread adeppa (JIRA)

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

adeppa commented on SOLR-12322:
---

[~mkhludnev] Please find attachment for the explanation of business use case 
and what feature i used   
 

> Select specific field list for child documents using 
> ChildDocTransformerFactory
> ---
>
> Key: SOLR-12322
> URL: https://issues.apache.org/jira/browse/SOLR-12322
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers, search
>Affects Versions: 6.6
>Reporter: adeppa
>Priority: Minor
> Fix For: 6.6
>
> Attachments: SOLR-12322.patch, doc_level_exaplantion.docx
>
>
> With the current version of SOLR and nested indexing, when you are fetch a 
> parent record it returns all the fields of its children. This is increasing 
> the size of data being returned from SOLR and also hits our performance 
> sometime.
> This ticket will be used to update the ChildDocTransformerFactory class with 
> additional parameters to specify the list of fields to be pulled for child 
> documents.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-12322) Select specific field list for child documents using ChildDocTransformerFactory

2018-05-07 Thread adeppa (JIRA)

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

adeppa updated SOLR-12322:
--
Attachment: doc_level_exaplantion.docx

> Select specific field list for child documents using 
> ChildDocTransformerFactory
> ---
>
> Key: SOLR-12322
> URL: https://issues.apache.org/jira/browse/SOLR-12322
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers, search
>Affects Versions: 6.6
>Reporter: adeppa
>Priority: Minor
> Fix For: 6.6
>
> Attachments: SOLR-12322.patch, doc_level_exaplantion.docx
>
>
> With the current version of SOLR and nested indexing, when you are fetch a 
> parent record it returns all the fields of its children. This is increasing 
> the size of data being returned from SOLR and also hits our performance 
> sometime.
> This ticket will be used to update the ChildDocTransformerFactory class with 
> additional parameters to specify the list of fields to be pulled for child 
> documents.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



Re: Review Request 66967: SolrCmdDistributor retries requestss from leader to followers

2018-05-07 Thread Tomás Fernández Löbbe

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66967/
---

(Updated May 8, 2018, 3:51 a.m.)


Review request for lucene.


Repository: lucene-solr


Description (updated)
---

SolrCmdDistributor retries requestss from leader to followers


Diffs (updated)
-

  solr/core/src/java/org/apache/solr/update/SolrCmdDistributor.java 08b397fbb2 
  solr/core/src/java/org/apache/solr/update/StreamingSolrClients.java 
316aa455a1 
  
solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java
 d5e4194b15 
  
solr/core/src/java/org/apache/solr/update/processor/TimeRoutedAliasUpdateProcessor.java
 224bd4b6ba 
  solr/core/src/test/org/apache/solr/cloud/ChaosMonkeySafeLeaderTest.java 
76c1984a0d 
  solr/core/src/test/org/apache/solr/update/MockStreamingSolrClients.java 
72d39ff89b 
  solr/core/src/test/org/apache/solr/update/SolrCmdDistributorTest.java 
1699b0d70d 


Diff: https://reviews.apache.org/r/66967/diff/3/

Changes: https://reviews.apache.org/r/66967/diff/2-3/


Testing
---


Thanks,

Tomás Fernández Löbbe



[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 4613 - Unstable!

2018-05-07 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4613/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseSerialGC

4 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger

Error Message:
waitFor not elapsed but produced an event

Stack Trace:
java.lang.AssertionError: waitFor not elapsed but produced an event
at 
__randomizedtesting.SeedInfo.seed([68D8E8204374F09C:B13DEA2DABB83B1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger(IndexSizeTriggerTest.java:180)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger

Error Message:
number of ops expected:<2> but was:<1>

Stack Trace:
java.lang.AssertionError: number of ops expected:<2> but was:<1>
at 

[jira] [Commented] (SOLR-12258) V2 API should "retry" for unresolved collections/aliases (like V1 does)

2018-05-07 Thread David Smiley (JIRA)

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

David Smiley commented on SOLR-12258:
-

Thanks for the input.  Here's another variation of this method; this time 
without a secondTry arg which I don't really like:
{code:java}
  protected DocCollection resolveDocCollection(String collectionStr) {
if (!cores.isZooKeeperAware()) {
  throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "Solr not 
running in cloud mode ");
}
ZkStateReader zkStateReader = cores.getZkController().getZkStateReader();

Supplier logic = () -> {
  this.collectionsList = resolveCollectionListOrAlias(collectionStr); // 
side-effect
  String collectionName = collectionsList.get(0); // first
  //TODO an option to choose another collection in the list if can't find a 
local replica of the first?

  return 
zkStateReader.getClusterState().getCollectionOrNull(collectionName);
};

DocCollection docCollection = logic.get();
if (docCollection != null) {
  return docCollection;
}
// ensure our view is up to date before trying again
try {
  zkStateReader.aliasesManager.update();
  zkStateReader.forceUpdateCollection(collectionsList.get(0));
} catch (Exception e) {
  log.error("Error trying to update state while resolving collection.", e);
  //don't propagate exception on purpose
}
return logic.get();
  }
{code}
I can't come up with anything elegant.  At least the lambda had little ceremony 
to it, helped by the fact that no checked exceptions are involved and so I 
could use the standard Supplier interface.


bq. forciblyRefreshAllClusterStateSlow

Heh; I didn't notice it.  It sure does look like a candidate!  Yeah, adding 
sync() over there ought to be its own JIRA.

> V2 API should "retry" for unresolved collections/aliases (like V1 does)
> ---
>
> Key: SOLR-12258
> URL: https://issues.apache.org/jira/browse/SOLR-12258
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, v2 API
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-12258.patch, SOLR-12258.patch
>
>
> When using V1, if the request refers to a possible collection/alias that 
> fails to resolve, HttpSolrCall will invoke AliasesManager.update() then retry 
> the request as if anew (in collaboration with SolrDispatchFilter).  If it 
> fails to resolve again we stop there and return an error; it doesn't go on 
> forever.
> V2 (V2HttpCall specifically) doesn't have this retry mechanism.  It'll return 
> "no such collection or alias".
> The retry will not only work for an alias but the retrying is a delay that 
> will at least help the odds of a newly made collection from being known to 
> this Solr node.  It'd be nice if this was more explicit – i.e. if there was a 
> mechanism similar to AliasesManager.update() but for a collection.  I'm not 
> sure how to do that?
> BTW I discovered this while debugging a Jenkins failure of 
> TimeRoutedAliasUpdateProcessorTest.test where it early on simply goes to 
> issue a V2 based request to change the configuration of a collection that was 
> created immediately before it.  It's pretty mysterious.  I am aware of 
> SolrCloudTestCase.waitForState which is maybe something that needs to be 
> called?  But if that were true then *every* SolrCloud test would need to use 
> it; it just seems wrong to me that we ought to use this method commonly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-12265) Upgrade Jetty to 9.4.10

2018-05-07 Thread Varun Thacker (JIRA)

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

Varun Thacker updated SOLR-12265:
-
Summary: Upgrade Jetty to 9.4.10  (was: Upgrade Jetty to 9.4.9)

> Upgrade Jetty to 9.4.10
> ---
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>
> Solr 7.3 upgraded to Jetty 9.4.8 
> We're seeing this WARN very sporadically ( maybe one in every 100k requests ) 
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) - 
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for 
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28 
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0 
> of 
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
>  of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a 
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was 
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x 
> and then in Jetty 9.4.9 this class has undergone quite a few changes 
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
>  . 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (SOLR-12308) LISTALIASES should return up to date response

2018-05-07 Thread David Smiley (JIRA)

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

David Smiley resolved SOLR-12308.
-
   Resolution: Fixed
Fix Version/s: 7.4

> LISTALIASES should return up to date response
> -
>
> Key: SOLR-12308
> URL: https://issues.apache.org/jira/browse/SOLR-12308
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.4
>
> Attachments: SOLR-12308.patch
>
>
> The LISTALIASES command might return a stale response due to the default 
> eventual consistency of reads of ZooKeeper.  I think if someone calls this 
> command (which generally won't be rapid-fire), they deserve an up to date 
> response.  This is easily done with a one-liner; patch forthcoming.
> Returning stale alias info is the only plausible explanation I have for why a 
> recent CI failure for AliasesIntegrationTest.tearDown() failed to detect 
> aliases to be deleted. It calls listAliases to know which aliases exist so it 
> can then delete them 1st.
>  [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1833/]
> tearDown then calls MiniSolrCloudCluster.deleteAllCollections() which 
> interestingly grabs a ZkStateReader.createClusterStateWatchersAndUpdate() 
> perhaps this ought to delete all aliases _as well_ since, after all, if there 
> were any aliases then well deleting all collections is bound to fail.  Should 
> I file a separate issue or just handle this together?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12308) LISTALIASES should return up to date response

2018-05-07 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12308:


Commit 6b1a64e1e6041e1205c3180c08365bbab18096a1 in lucene-solr's branch 
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6b1a64e ]

SOLR-12308: LISTALIASES is now assured to return an up-to-date response
* MiniSolrCloudCluster.deleteAllCollections will now first delete aliases
* Minor refactorings to AliasesManager, AliasIntegrationTest, 
CreateRoutedAliasTest

(cherry picked from commit 08ee037)


> LISTALIASES should return up to date response
> -
>
> Key: SOLR-12308
> URL: https://issues.apache.org/jira/browse/SOLR-12308
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12308.patch
>
>
> The LISTALIASES command might return a stale response due to the default 
> eventual consistency of reads of ZooKeeper.  I think if someone calls this 
> command (which generally won't be rapid-fire), they deserve an up to date 
> response.  This is easily done with a one-liner; patch forthcoming.
> Returning stale alias info is the only plausible explanation I have for why a 
> recent CI failure for AliasesIntegrationTest.tearDown() failed to detect 
> aliases to be deleted. It calls listAliases to know which aliases exist so it 
> can then delete them 1st.
>  [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1833/]
> tearDown then calls MiniSolrCloudCluster.deleteAllCollections() which 
> interestingly grabs a ZkStateReader.createClusterStateWatchersAndUpdate() 
> perhaps this ought to delete all aliases _as well_ since, after all, if there 
> were any aliases then well deleting all collections is bound to fail.  Should 
> I file a separate issue or just handle this together?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12308) LISTALIASES should return up to date response

2018-05-07 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12308:


Commit 08ee037ff8cc1edee87c14424d5a5a479ad2adf5 in lucene-solr's branch 
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=08ee037 ]

SOLR-12308: LISTALIASES is now assured to return an up-to-date response
* MiniSolrCloudCluster.deleteAllCollections will now first delete aliases
* Minor refactorings to AliasesManager, AliasIntegrationTest, 
CreateRoutedAliasTest


> LISTALIASES should return up to date response
> -
>
> Key: SOLR-12308
> URL: https://issues.apache.org/jira/browse/SOLR-12308
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12308.patch
>
>
> The LISTALIASES command might return a stale response due to the default 
> eventual consistency of reads of ZooKeeper.  I think if someone calls this 
> command (which generally won't be rapid-fire), they deserve an up to date 
> response.  This is easily done with a one-liner; patch forthcoming.
> Returning stale alias info is the only plausible explanation I have for why a 
> recent CI failure for AliasesIntegrationTest.tearDown() failed to detect 
> aliases to be deleted. It calls listAliases to know which aliases exist so it 
> can then delete them 1st.
>  [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1833/]
> tearDown then calls MiniSolrCloudCluster.deleteAllCollections() which 
> interestingly grabs a ZkStateReader.createClusterStateWatchersAndUpdate() 
> perhaps this ought to delete all aliases _as well_ since, after all, if there 
> were any aliases then well deleting all collections is bound to fail.  Should 
> I file a separate issue or just handle this together?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-7.3-Windows (64bit/jdk-10) - Build # 45 - Unstable!

2018-05-07 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Windows/45/
Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.testTrigger

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([A409447E985B591E:C7C272FC01942A33]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.testTrigger(NodeAddedTriggerTest.java:111)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 14183 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest
   [junit4]   2> 2818821 INFO  
(SUITE-NodeAddedTriggerTest-seed#[A409447E985B591E]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & 

[JENKINS] Lucene-Solr-Tests-master - Build # 2521 - Still Unstable

2018-05-07 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2521/

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([8F301B8FD3EE943:5B4A43081F2F7CB9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 13145 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest
   [junit4]   2> 802241 INFO  
(SUITE-IndexSizeTriggerTest-seed#[8F301B8FD3EE943]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & 

[jira] [Updated] (SOLR-7767) Zookeeper Ensemble Admin UI

2018-05-07 Thread JIRA

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

Jan Høydahl updated SOLR-7767:
--
Attachment: (was: image-2018-05-08-02-26-29-989.png)

> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: zk-status-error.png, zk-status-tab.png
>
>
> For SolrCloud mode can we have the functionality to display the live nodes 
> from the zookeeper ensemble. So that user can easily get to know if any of 
> zookeeper instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-7767) Zookeeper Ensemble Admin UI

2018-05-07 Thread JIRA

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

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

Here is screenshot from a new "Zookeeper" tab in the cloud section:

!zk-status-tab.png|width=700!

It takes zkHost string and talks directly to each configured zookeeper using 
the low-level socket API 
"[four-letter-word|https://zookeeper.apache.org/doc/r3.4.11/zookeeperAdmin.html#sc_zkCommands];
 and returns monitoring status (MNTR) as well as configuration details (CONF) 
for each ZK. It will also print warnings if there is an odd number of nodes, if 
there is a mix of standalone and ensemble nodes and other warning states.

The API is added to {{ZookeeperInfoHandler}}, with parameter {{mntr=true}}. 
Example:

[http://localhost:8983/solr/admin/zookeeper?mntr=true]
{code}
{
  "responseHeader": {
"QTime": 24,
"status": 0
  },
  "zkStatus": {
"details": [{
  "clientPort": "9983",
  "dataDir": 
"/Users/janhoy/git/lucene-solr/solr/server/solr/zoo_data/version-2",
  "dataLogDir": 
"/Users/janhoy/git/lucene-solr/solr/server/solr/zoo_data/version-2",
  "host": "localhost:9983",
  "maxClientCnxns": "60",
  "maxSessionTimeout": "4",
  "minSessionTimeout": "4000",
  "ok": true,
  "serverId": "0",
  "tickTime": "2000",
  "zk_approximate_data_size": "210920",
  "zk_avg_latency": "0",
  "zk_ephemerals_count": "3",
  "zk_max_file_descriptor_count": "10240",
  "zk_max_latency": "4",
  "zk_min_latency": "0",
  "zk_num_alive_connections": "3",
  "zk_open_file_descriptor_count": "158",
  "zk_outstanding_requests": "0",
  "zk_packets_received": "165",
  "zk_packets_sent": "167",
  "zk_server_state": "standalone",
  "zk_version": "3.4.11-37e277162d567b55a07d1755f0b31c32e93c01a0, built on 
11/01/2017 18:06 GMT",
  "zk_watch_count": "18",
  "zk_znode_count": "79"
}],
"ensembleSize": 1,
"mode": "standalone",
"status": "green"
  }
}
{code}

Here's an example of an error (one zk cannot be reached):
 !zk-status-error.png|width=700! 

> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: image-2018-05-08-02-26-29-989.png, zk-status-error.png, 
> zk-status-tab.png
>
>
> For SolrCloud mode can we have the functionality to display the live nodes 
> from the zookeeper ensemble. So that user can easily get to know if any of 
> zookeeper instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-7767) Zookeeper Ensemble Admin UI

2018-05-07 Thread JIRA

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

Jan Høydahl updated SOLR-7767:
--
Attachment: zk-status-error.png

> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: image-2018-05-08-02-26-29-989.png, zk-status-error.png, 
> zk-status-tab.png
>
>
> For SolrCloud mode can we have the functionality to display the live nodes 
> from the zookeeper ensemble. So that user can easily get to know if any of 
> zookeeper instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-7767) Zookeeper Ensemble Admin UI

2018-05-07 Thread JIRA

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

Jan Høydahl updated SOLR-7767:
--
Attachment: image-2018-05-08-02-26-29-989.png

> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: image-2018-05-08-02-26-29-989.png, zk-status-tab.png
>
>
> For SolrCloud mode can we have the functionality to display the live nodes 
> from the zookeeper ensemble. So that user can easily get to know if any of 
> zookeeper instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-9480) Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)

2018-05-07 Thread Hoss Man (JIRA)

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

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

> Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)
> --
>
> Key: SOLR-9480
> URL: https://issues.apache.org/jira/browse/SOLR-9480
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Trey Grainger
>Priority: Major
> Attachments: SOLR-9480.patch, SOLR-9480.patch
>
>
> This issue is to track the contribution of the Semantic Knowledge Graph Solr 
> Plugin (request handler), which exposes a graph-like interface for 
> discovering and traversing significant relationships between entities within 
> an inverted index.
> This data model has been described in the following research paper: [The 
> Semantic Knowledge Graph: A compact, auto-generated model for real-time 
> traversal and ranking of any relationship within a 
> domain|https://arxiv.org/abs/1609.00464], as well as in presentations I gave 
> in October 2015 at [Lucene/Solr 
> Revolution|http://www.slideshare.net/treygrainger/leveraging-lucenesolr-as-a-knowledge-graph-and-intent-engine]
>  and November 2015 at the [Bay Area Search 
> Meetup|http://www.treygrainger.com/posts/presentations/searching-on-intent-knowledge-graphs-personalization-and-contextual-disambiguation/].
> The source code for this project is currently available at 
> [https://github.com/careerbuilder/semantic-knowledge-graph], and the folks at 
> CareerBuilder (where this was built) have given me the go-ahead to now 
> contribute this back to the Apache Solr Project, as well.
> Check out the Github repository, research paper, or presentations for a more 
> detailed description of this contribution. Initial patch coming soon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-9480) Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)

2018-05-07 Thread Hoss Man (JIRA)

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

Hoss Man commented on SOLR-9480:


I've been playing with this "SKG" code off an on for a bit, and talking with 
trey about it offline, and I think I've come up with a nice strategy for 
integrating it directly into JSON Faceting as a handfull small improvements, to 
be able to leverage most of the existing JSON Facet code (including distributed 
refinement) w/o needing to be "tacked on" to the outside as much as the code in 
the older patch/github-repo does.

The attached patch includes the 3 most "important" of these improvements in 
order for this to work, along with lots of new tests...
 # Refactoring the {{SlotAcc}} so that everytime it's asked to {{collect(...)}} 
a slot, it has the ability to ask for a {{Query}} that identifies this slot 
_independent of the current context_
 ** This allows the new SKG code (described below) to have enough information 
about the current bucket that it can compute the full "foreground" that it 
wants, regardless of the bucket type or how the current bucket may be nested 
under other facets ... so SKG graphs can be built by nesting any types of 
facets (including range & query facets) regardless of how the top level {{q + 
fq}} params realted to the {{foreground}} query.
 ** this happens via a {{IntFunction}} callback function – so there 
shouldn't be any overhead to existing FacetProcessor/SlotAcc usages that don't 
care about this extra info about the bucket – there's no extra {{TermQuery}} 
(or {{RangeQuery}} etc...) overhead when the accumulators only care about the 
final filtered set of documents for the current bucket/slot.

 # Add an {{skg(...)}} AggValueSource function that can be nested under any 
facet
 ** this function takes in the "foreground" and "background" queries to use, 
which just like any existing (aggregate) function can be {{$variables}} 
pointing to existing request params
 ** this means that, unlike the original SKG code linked from this issue, you 
could compute the SKG relatedness info only at certain points in the facet 
herirachy, or use different foreground/background queries in different places
 ** this function actually produces JSON "objects" as the function result, 
containing the foreground/background popularities as well as the "relatedness" 
score – which is what's used if you sort on this function
 ** I originally experimented with implementing "SKG" as a new type of _facet_ 
that could be nested under any (othe) facet, but implementing as a function 
means that we can leverage the existing code for sorting (parent) facet buckets 
by the (child) function's results – which is very powerful for SKG results (and 
it's not currently possible to "sort" on the results of a sub-facet, and doing 
so would be a lot of work given how sub-facet refinement is currently handled 
... i looked into it briefly)
 ** but sorting on the {{skg()}} function is optional, and not strictly 
neccessary when the clients care more about performance then accuracy – as with 
the existing SKG code trey contributed, the (default) sort on facet count could 
still be used, which means the existing JSON faceting code would only compute 
the (semi-expensive) {{skg()}} function on the final buckets to be returned, 
and the client could then post-process to re-sort them by the {{skg()}} values.

 # Add support for a "explicit query domain" via syntax like {{domain : 
\{query:'foo:bar'\}}}  (or any other JSON query syntax supported by the 
{{filters}} option) that let's you arbitrarily pick any set of queries you want 
to use as a "domain" for a facet, regardless of it's parent facets/bucket.
 ** this provides an optional way to improve the "top n" accuracy of sub-facets 
in a deep SKG request, by letting you ignore the "ancestor facet bucket 
filtering" typically done in faceting, and instead request that *all* buckets 
under some arbitrarr query – like the original background query – be considered.
 ** SKG users that care more about speed & aproximations can ignore this 
feature, and just sort the regular facet terms by the {{skg()}} function to get 
a good aproximation of the top terms ... or as I mentioned before: trust the 
(default) sort on facet counts (w/or w/o using the {{$background_q}} as an 
explicit domain) to approximate the top N terms)

An example of what all these features together can look like right now...
{noformat}
rows=0&
q=type:QUESTION&
fore=body:%22harry+potter%22&
back=*:*&
json.facet='{
  tags : {
type : terms,
field : tags,
limit : 5,
sort : { skg: desc },
facet : {
  skg : "skg($fore,$back)",
  body : {
type : terms,
field : body,
limit : 5,
domain : { query:{param:back} },
sort : { skg: desc },
facet : {
  skg : "skg($fore,$back)"
}
  }
}
  }
}'

[jira] [Updated] (SOLR-7767) Zookeeper Ensemble Admin UI

2018-05-07 Thread JIRA

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

Jan Høydahl updated SOLR-7767:
--
Attachment: zk-status-tab.png

> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: zk-status-tab.png
>
>
> For SolrCloud mode can we have the functionality to display the live nodes 
> from the zookeeper ensemble. So that user can easily get to know if any of 
> zookeeper instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12258) V2 API should "retry" for unresolved collections/aliases (like V1 does)

2018-05-07 Thread Gus Heck (JIRA)

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

Gus Heck commented on SOLR-12258:
-

I think it might read better to move the contents of the two
{code:java}
if (secondTry){code}
blocks into the
{code:java}
if(!secondTry){code}
block just before recursion. (conditionally "Update and recurse" rather than 
recurse then conditionally update)

 

Also in inspecting usages of
{code:java}
forceUpdateCollection(collectionName) {code}
I came across the javadoc comment on
{code:java}
org.apache.solr.common.cloud.ZkStateReader#forciblyRefreshAllClusterStateSlow{code}
method. That method seems like an even bigger candidate for a Zookeeper.sync(), 
but maybe that's another jira

 

> V2 API should "retry" for unresolved collections/aliases (like V1 does)
> ---
>
> Key: SOLR-12258
> URL: https://issues.apache.org/jira/browse/SOLR-12258
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, v2 API
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-12258.patch, SOLR-12258.patch
>
>
> When using V1, if the request refers to a possible collection/alias that 
> fails to resolve, HttpSolrCall will invoke AliasesManager.update() then retry 
> the request as if anew (in collaboration with SolrDispatchFilter).  If it 
> fails to resolve again we stop there and return an error; it doesn't go on 
> forever.
> V2 (V2HttpCall specifically) doesn't have this retry mechanism.  It'll return 
> "no such collection or alias".
> The retry will not only work for an alias but the retrying is a delay that 
> will at least help the odds of a newly made collection from being known to 
> this Solr node.  It'd be nice if this was more explicit – i.e. if there was a 
> mechanism similar to AliasesManager.update() but for a collection.  I'm not 
> sure how to do that?
> BTW I discovered this while debugging a Jenkins failure of 
> TimeRoutedAliasUpdateProcessorTest.test where it early on simply goes to 
> issue a V2 based request to change the configuration of a collection that was 
> created immediately before it.  It's pretty mysterious.  I am aware of 
> SolrCloudTestCase.waitForState which is maybe something that needs to be 
> called?  But if that were true then *every* SolrCloud test would need to use 
> it; it just seems wrong to me that we ought to use this method commonly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-10) - Build # 7306 - Still Unstable!

2018-05-07 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7306/
Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseParallelGC

27 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([343DA872540BC647:DB311327BF40FB9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration(IndexSizeTriggerTest.java:298)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 

[jira] [Commented] (LUCENE-8287) ContextQuery with empty RegexCompletionQuery produces an assertion failure

2018-05-07 Thread Julie Tibshirani (JIRA)

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

Julie Tibshirani commented on LUCENE-8287:
--

We caught up offline, and [~jim.ferenczi] agrees that we should match the 
RegexpQuery semantics of returning no results. I'll work on updating the patch.

> ContextQuery with empty RegexCompletionQuery produces an assertion failure
> --
>
> Key: LUCENE-8287
> URL: https://issues.apache.org/jira/browse/LUCENE-8287
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8287-repro.patch, LUCENE-8287.patch
>
>
> When an empty RegexCompletionQuery is provided to ContextQuery, the following 
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with the context separator
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:296)
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at 
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at 
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at 
> org.apache.lucene.search.suggest.document.TestContextQuery.testEmptyRegexQuery(TestContextQuery.java:193)
> {code}
> This is a bit of an edge case, but may be concerning since without assertions 
> enabled, you can go on to access IntsRef indices that are out of bounds.
> The attached patch provides a reproduction of the issue, as the test case 
> TestContextQuery#testEmptyRegexQuery. Note that to reproduce, Java assertions 
> must be enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty 
> RegexCompletionQuery, when it is not wrapped in ContextQuery 
> (TestRegexCompletionQuery#testEmptyRegexQuery). In this case, there is no 
> error, and all suggestions are returned. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12308) LISTALIASES should return up to date response

2018-05-07 Thread Gus Heck (JIRA)

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

Gus Heck commented on SOLR-12308:
-

Changes all look good to me :)

> LISTALIASES should return up to date response
> -
>
> Key: SOLR-12308
> URL: https://issues.apache.org/jira/browse/SOLR-12308
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12308.patch
>
>
> The LISTALIASES command might return a stale response due to the default 
> eventual consistency of reads of ZooKeeper.  I think if someone calls this 
> command (which generally won't be rapid-fire), they deserve an up to date 
> response.  This is easily done with a one-liner; patch forthcoming.
> Returning stale alias info is the only plausible explanation I have for why a 
> recent CI failure for AliasesIntegrationTest.tearDown() failed to detect 
> aliases to be deleted. It calls listAliases to know which aliases exist so it 
> can then delete them 1st.
>  [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1833/]
> tearDown then calls MiniSolrCloudCluster.deleteAllCollections() which 
> interestingly grabs a ZkStateReader.createClusterStateWatchersAndUpdate() 
> perhaps this ought to delete all aliases _as well_ since, after all, if there 
> were any aliases then well deleting all collections is bound to fail.  Should 
> I file a separate issue or just handle this together?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_162) - Build # 1865 - Still Unstable!

2018-05-07 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1865/
Java: 64bit/jdk1.8.0_162 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.SearchRateTriggerTest.testTrigger

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([F0994C2055A8DF16:93527AA2CC67AC3B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.autoscaling.SearchRateTriggerTest.testTrigger(SearchRateTriggerTest.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




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

[JENKINS] Lucene-Solr-repro - Build # 588 - Unstable

2018-05-07 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-repro/588/

[...truncated 32 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-7.x/598/consoleText

[repro] Revision: 7db633910424244356652944d4aca6184807faf6

[repro] Repro line:  ant test  -Dtestcase=NodeAddedTriggerTest 
-Dtests.method=testRestoreState -Dtests.seed=3AE1E401E324462C 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=und 
-Dtests.timezone=America/Hermosillo -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testSplitIntegration -Dtests.seed=3AE1E401E324462C 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ja-JP 
-Dtests.timezone=America/Cancun -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testTrigger -Dtests.seed=3AE1E401E324462C -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=ja-JP -Dtests.timezone=America/Cancun 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
3e8f31ead006a1ed2ee744bc9b37723851c9dd22
[repro] git fetch

[...truncated 2 lines...]
[repro] git checkout 7db633910424244356652944d4aca6184807faf6

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   NodeAddedTriggerTest
[repro]   IndexSizeTriggerTest
[repro] ant compile-test

[...truncated 3316 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.NodeAddedTriggerTest|*.IndexSizeTriggerTest" 
-Dtests.showOutput=onerror  -Dtests.seed=3AE1E401E324462C -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=und -Dtests.timezone=America/Hermosillo 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[...truncated 7172 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest
[repro]   4/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest
[repro] git checkout 3e8f31ead006a1ed2ee744bc9b37723851c9dd22

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 599 - Still Unstable

2018-05-07 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/599/

3 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([A8F5270D88239D33:FB4C65BD6A3208C9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.autoscaling.SearchRateTriggerTest.testTrigger

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([A8F5270D88239D33:CB3E118F11ECEE1E]:0)
at org.junit.Assert.fail(Assert.java:93)
  

[jira] [Commented] (SOLR-12320) Not all multi-part post requests should create tmp files.

2018-05-07 Thread Mark Miller (JIRA)

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

Mark Miller commented on SOLR-12320:


I will have to investigate some to be sure of much, but as far as I know, we 
currently write to a tmp file due to a File based implementation we pick from 
commons-fileupload.

If Tika writes to a different temp file anyway, maybe it's as simple as 
changing that implementation, I'm not sure yet.

We do currently clean up using this reaper thread class that we have copied 
from commons-fileupload due to needing some customizations. I really don't like 
it though - if we could do cleanup without a reaper thread always running in 
the background that would be great - or if we didn't need to write to a tmp 
file here at all. I don't know if we can avoid it entirely or not though. The 
only thing I could think of that might count on it is uploading very large 
files for tika to parse with Solr Cell.

> Not all multi-part post requests should create tmp files.
> -
>
> Key: SOLR-12320
> URL: https://issues.apache.org/jira/browse/SOLR-12320
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
>
> We create tmp files for multi-part posts because often they are uploaded 
> files for Solr cell or something but we also sometimes write params only or 
> params and updates as multi-part post. These should not create any tmp files.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 603 - Unstable!

2018-05-07 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/603/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

11 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([20867F412CBCAEC9:733F3DF1CEAD3B33]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/84)={   
"replicationFactor":"2",   "pullReplicas":"0",   

[jira] [Commented] (SOLR-12298) Index Full nested document Hierarchy For Queries (umbrella issue)

2018-05-07 Thread David Smiley (JIRA)

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

David Smiley commented on SOLR-12298:
-

bq.  that will not prevent the need for a new JSON loader, since the current 
one requires the \_childDocument\_ to be added at each level.

I'm not sure I understand you.  Firstly, \_childDocument\_ isn't required; you 
could instead provide an array as a JSON value and it'll be assumed to contain 
multiple child documents.  JsonLoaderTest.PARENT_TWO_CHILDREN_JSON demonstrates 
that.  Secondly, I don't get the point/consequence of why this is a problem.

Nevertheless, I can see that  SolrInputDocument.getChildDocuments doesn't 
capture the nature of the relationship, plus some child docs may have a varying 
relationship.  The JSON structure will usually have labels that are indicative 
of that relationship, like a "comments" array of child docs on a blog post, and 
perhaps an "author" child doc for the author of the post (if we imagine 
modeling it this way).  

Still; it'd be a shame if a solution here were fixed to JSON only, so I'm 
stubborn on going with an URP for at least part of this.  Perhaps if the 
SolrInputDocument held optional contextual metadata populated by JsonLoader, 
then an URP could use this information.  Lacking that information it could work 
in a general way (e.g. assume simply "child" relationship).  Or... what if 
SolrInputDocument did not have an explicit \_childDocuments field list.  What 
if a SolrInputDocument was simply a supported value inside SolrInputField? That 
would be a bigger change but may be a more appropriate fix, since adding the 
relationship after the fact (what we're talking about) could be seen a hack on 
top of SolrInputDocument which doesn't capture it natively when it should.  
I'll sleep on it.

> Index Full nested document Hierarchy For Queries (umbrella issue)
> -
>
> Key: SOLR-12298
> URL: https://issues.apache.org/jira/browse/SOLR-12298
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
>
> Solr ought to have the ability to index deeply nested objects, while storing 
> the original document hierarchy.
>  Currently the client has to index the child document's full path and level 
> to manually reconstruct the original document structure, since the children 
> are flattened and returned in the reserved "__childDocuments__" key.
> Ideally you could index a nested document, having Solr transparently add the 
> required fields while providing a document transformer to rebuild the 
> original document's hierarchy.
>  
> This issue is an umbrella issue for the particular tasks that will make it 
> all happen – either subtasks or issue linking.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-12328) Adding graph json facet domain change

2018-05-07 Thread Daniel Meehl (JIRA)

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

Daniel Meehl updated SOLR-12328:

Attachment: SOLR-12328.patch

> Adding graph json facet domain change
> -
>
> Key: SOLR-12328
> URL: https://issues.apache.org/jira/browse/SOLR-12328
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 7.3
>Reporter: Daniel Meehl
>Priority: Major
> Attachments: SOLR-12328.patch
>
>
> Json facets now support join queries via domain change. I've made a 
> relatively small enhancement to add graph to the mix. I'll attach a patch for 
> your viewing. I'm hoping this can be merged into solr proper. Please let me 
> know if there are any problems/changes/requirements. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (SOLR-12328) Adding graph json facet domain change

2018-05-07 Thread Daniel Meehl (JIRA)
Daniel Meehl created SOLR-12328:
---

 Summary: Adding graph json facet domain change
 Key: SOLR-12328
 URL: https://issues.apache.org/jira/browse/SOLR-12328
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Facet Module
Affects Versions: 7.3
Reporter: Daniel Meehl


Json facets now support join queries via domain change. I've made a relatively 
small enhancement to add graph to the mix. I'll attach a patch for your 
viewing. I'm hoping this can be merged into solr proper. Please let me know if 
there are any problems/changes/requirements. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI

2018-05-07 Thread JIRA

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

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

{quote}One thing that's a little confusing still is the fact that clicking on 
the numbers - which otherwise have no indication that they are clickable - 
opens up the more detailed stats
{quote}
That's how things get when the whole table cell has an on-click action 
attached. I plan to add some mouseover-bgcolor change to the whole row to 
indicate that something will happen. But I'm not married to this click-anywhere 
style. Could just as well replace this with a simple {{(expand details...)}} 
link at the bottom of the "Node" column and a {{(expand details for all...)}} 
link in the "Host" column. Or some graphical symbol.

I'd be thrilled if someone with a nose for the visuals could take a stab at 
clarifying this and more...

> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 5.3
>Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png, 
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 
> the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-7.3-Linux (64bit/jdk-9.0.4) - Build # 189 - Unstable!

2018-05-07 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Linux/189/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseParallelGC

6 tests failed.
FAILED:  org.apache.solr.cloud.AddReplicaTest.test

Error Message:
core_node6:{"core":"addreplicatest_coll_shard1_replica_n5","base_url":"https://127.0.0.1:46597/solr","node_name":"127.0.0.1:46597_solr","state":"active","type":"NRT"}

Stack Trace:
java.lang.AssertionError: 
core_node6:{"core":"addreplicatest_coll_shard1_replica_n5","base_url":"https://127.0.0.1:46597/solr","node_name":"127.0.0.1:46597_solr","state":"active","type":"NRT"}
at 
__randomizedtesting.SeedInfo.seed([273761F71B89A3B3:AF635E2DB575CE4B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.solr.cloud.AddReplicaTest.test(AddReplicaTest.java:84)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts

Error 

[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI

2018-05-07 Thread Cassandra Targett (JIRA)

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

Cassandra Targett commented on SOLR-8207:
-

I didn't get a chance to give feedback last week, but I agree with much that 
was said, and the new changes look good IMO.

I do think the numbers are still a bit large, but the colors are a fine 
mitigation of that if you think they are better with a larger font. IOW, with 
the color variation I don't have strong opinions about it. Another couple years 
and I'll need the numbers that big anyway!

One thing that's a little confusing still is the fact that clicking on the 
numbers - which otherwise have no indication that they are clickable - opens up 
the more detailed stats. My first intuition was to click the Node name which is 
clearly clickable, but that opens up the Solr Admin for that node. That's fine, 
but how do we tell the user there is more to the stats portion? Maybe a carat 
icon in the cell that holds the first metric that shows the cell expands? It 
would be too much maybe to have it in all 3 cells in one row, but the first one 
would get the point across that more is there, hopefully without being too 
cluttered. WDYT?

> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 5.3
>Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png, 
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 
> the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] lucene-solr pull request #370: SOLR-12312: Change buf to not always use up 1...

2018-05-07 Thread millerjeff0
Github user millerjeff0 closed the pull request at:

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


---

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



[jira] [Commented] (SOLR-4052) Upload files to ZooKeeper from Solr Admin interface

2018-05-07 Thread Cassandra Targett (JIRA)

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

Cassandra Targett commented on SOLR-4052:
-

bq. Is this still wanted even now when we have config set API and "bin/solr zk 
cp" capabilities?

I think if we want to minimize the user need to interact with ZK directly, we 
should instead think about how to make UIs that use our existing APIs 
(Configset API, Config API, Parameters API, etc.) and where we still have gaps 
to fill with new APIs. Implementing those would be a better use of our 
collective time and efforts, IMO.

> Upload files to ZooKeeper from Solr Admin interface
> ---
>
> Key: SOLR-4052
> URL: https://issues.apache.org/jira/browse/SOLR-4052
> Project: Solr
>  Issue Type: Improvement
>Reporter: Eric Pugh
>Priority: Major
> Attachments: ZookeeperInfoServletTest.java, zookeeper_edit.patch
>
>
> It would be nice if you could add files to ZooKeeper through the solr admin 
> tool instead of having to use the zkCli.  Steffan and I talked about this at 
> ApacheCon Euro, and he suggested that if I put the java code in place, he'll 
> put in the pretty GUI aspects!  This patch is based around using a tool like 
> http://blueimp.github.com/jQuery-File-Upload/ to upload to a java servlet.  I 
> hung this code off the ZookeeperInfoServlet doPost method mostly b/c I didn't 
> have a better sense of where it should go.   A *very* annoying thing is that 
> it seems like from the browser side you can't select a directory of files and 
> upload it, which would make loading a new solr core configuration split 
> across many directory VERY annoying.   Also, this doesn't really feel like a 
> solid solution to just pulling up a file in the ZK tree browser webpage, 
> editing it (maybe via a big text box) and then posting the contents back.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8261) InterpolatedProperties.interpolate and recursive property references

2018-05-07 Thread ASF subversion and git services (JIRA)

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

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

Commit 572490088149e6fc498b1a1ca739f277c7364e00 in lucene-solr's branch 
refs/heads/branch_7x from [~dawid.weiss]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5724900 ]

LUCENE-8261: non-recursive->recursive (javadoc update).


> InterpolatedProperties.interpolate and recursive property references
> 
>
> Key: LUCENE-8261
> URL: https://issues.apache.org/jira/browse/LUCENE-8261
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.4
>
> Attachments: LUCENE-8261.patch, LUCENE-8261.patch
>
>
> InterpolatedProperties is used in lib check tasks in the build file. I 
> occasionally see this:
> {code}
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/custom-tasks.xml:108:
>  java.lang.IllegalArgumentException: named capturing group is missing 
> trailing '}'
> at 
> java.base/java.util.regex.Matcher.appendExpandedReplacement(Matcher.java:1052)
> at 
> java.base/java.util.regex.Matcher.appendReplacement(Matcher.java:908)
> at 
> org.apache.lucene.dependencies.InterpolatedProperties.interpolate(InterpolatedProperties.java:64)
> {code}
> I don't think we ever need to use any group references in those replacements; 
> they should be fixed strings (quoted verbatim)? So 
> {{Pattern.quoteReplacement}} would be adequate here.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8261) InterpolatedProperties.interpolate and recursive property references

2018-05-07 Thread ASF subversion and git services (JIRA)

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

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

Commit 3e8f31ead006a1ed2ee744bc9b37723851c9dd22 in lucene-solr's branch 
refs/heads/master from [~dawid.weiss]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3e8f31e ]

LUCENE-8261: non-recursive->recursive (javadoc update).


> InterpolatedProperties.interpolate and recursive property references
> 
>
> Key: LUCENE-8261
> URL: https://issues.apache.org/jira/browse/LUCENE-8261
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.4
>
> Attachments: LUCENE-8261.patch, LUCENE-8261.patch
>
>
> InterpolatedProperties is used in lib check tasks in the build file. I 
> occasionally see this:
> {code}
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/custom-tasks.xml:108:
>  java.lang.IllegalArgumentException: named capturing group is missing 
> trailing '}'
> at 
> java.base/java.util.regex.Matcher.appendExpandedReplacement(Matcher.java:1052)
> at 
> java.base/java.util.regex.Matcher.appendReplacement(Matcher.java:908)
> at 
> org.apache.lucene.dependencies.InterpolatedProperties.interpolate(InterpolatedProperties.java:64)
> {code}
> I don't think we ever need to use any group references in those replacements; 
> they should be fixed strings (quoted verbatim)? So 
> {{Pattern.quoteReplacement}} would be adequate here.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8261) InterpolatedProperties.interpolate and recursive property references

2018-05-07 Thread Dawid Weiss (JIRA)

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

Dawid Weiss commented on LUCENE-8261:
-

Thanks Steve, I'll correct the Javadoc and commit it in.

> InterpolatedProperties.interpolate and recursive property references
> 
>
> Key: LUCENE-8261
> URL: https://issues.apache.org/jira/browse/LUCENE-8261
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.4
>
> Attachments: LUCENE-8261.patch, LUCENE-8261.patch
>
>
> InterpolatedProperties is used in lib check tasks in the build file. I 
> occasionally see this:
> {code}
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/custom-tasks.xml:108:
>  java.lang.IllegalArgumentException: named capturing group is missing 
> trailing '}'
> at 
> java.base/java.util.regex.Matcher.appendExpandedReplacement(Matcher.java:1052)
> at 
> java.base/java.util.regex.Matcher.appendReplacement(Matcher.java:908)
> at 
> org.apache.lucene.dependencies.InterpolatedProperties.interpolate(InterpolatedProperties.java:64)
> {code}
> I don't think we ever need to use any group references in those replacements; 
> they should be fixed strings (quoted verbatim)? So 
> {{Pattern.quoteReplacement}} would be adequate here.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (SOLR-12312) Replication's IndexFetcher buf size can be initialized smarter to not waste RAM/GC

2018-05-07 Thread David Smiley (JIRA)

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

David Smiley resolved SOLR-12312.
-
   Resolution: Fixed
Fix Version/s: 7.4

> Replication's IndexFetcher buf size can be initialized smarter to not waste 
> RAM/GC
> --
>
> Key: SOLR-12312
> URL: https://issues.apache.org/jira/browse/SOLR-12312
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.4
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> IndexFetcher's constructor knows the size of the file it's going to transfer. 
>  As-such, it ought to initialize the "buf" field to no larger than this size. 
>  This has been shown to waste Java heap/GC in  an environment with lots of 
> cores of small indexes and thus small files.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8288) Context query with regex "." produces an assertion failure

2018-05-07 Thread Jim Ferenczi (JIRA)

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

Jim Ferenczi commented on LUCENE-8288:
--

I attached a new patch that fixes the name of the option (preserveSep is the 
correct option, preservePositionIncrements is for keeping holes when tokens are 
removed by a filter). I'll commit next week if there is no objection.

> Context query with regex "." produces an assertion failure
> --
>
> Key: LUCENE-8288
> URL: https://issues.apache.org/jira/browse/LUCENE-8288
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8288-repro.patch, LUCENE-8288.patch, 
> LUCENE-8288.patch
>
>
> When a RegexCompletionQuery of "." is provided to ContextQuery, the following 
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with a context separator 
> followed by SEP_LABEL
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:299)
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at 
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at 
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at 
> org.apache.lucene.search.suggest.document.TestContextQuery.testDotRegexQuery(TestContextQuery.java:188)
> {code}
> Note that this is a related, but distinct issue from 
> https://issues.apache.org/jira/browse/LUCENE-8287, where the 
> RegexCompletionQuery is empty.
> The attached patch provides a reproduction of the issue, as the test case 
> TestContextQuery#testRegexDotQuery. To reproduce, Java assertions must be 
> enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty 
> RegexCompletionQuery, when it is not wrapped in ContextQuery 
> (TestRegexCompletionQuery#testRegexDotQuery). In this case, there is no 
> error, and all suggestions are returned.
> From a quick look, it seems as though "." doesn't capture any characters past 
>  CompletionAnalyzer.SEP_LABEL, so the matching prefix in 
> ContextCompletionWeight#setInnerWeight is unexpectedly empty.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_162) - Build # 1864 - Still Unstable!

2018-05-07 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1864/
Java: 32bit/jdk1.8.0_162 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.testDeleteNode

Error Message:
unexpected DELETENODE status: 
{responseHeader={status=0,QTime=3},status={state=notfound,msg=Did not find 
[search_rate_trigger3/37da35ec58f98T9hn4lq5d40l4kmq30kadte16t/0] in any tasks 
queue}}

Stack Trace:
java.lang.AssertionError: unexpected DELETENODE status: 
{responseHeader={status=0,QTime=3},status={state=notfound,msg=Did not find 
[search_rate_trigger3/37da35ec58f98T9hn4lq5d40l4kmq30kadte16t/0] in any tasks 
queue}}
at 
__randomizedtesting.SeedInfo.seed([CE0FD220A5BC8799:EC9D1CA2927608E4]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.lambda$testDeleteNode$6(SearchRateTriggerIntegrationTest.java:668)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at 
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.testDeleteNode(SearchRateTriggerIntegrationTest.java:660)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Updated] (LUCENE-8288) Context query with regex "." produces an assertion failure

2018-05-07 Thread Jim Ferenczi (JIRA)

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

Jim Ferenczi updated LUCENE-8288:
-
Attachment: LUCENE-8288.patch

> Context query with regex "." produces an assertion failure
> --
>
> Key: LUCENE-8288
> URL: https://issues.apache.org/jira/browse/LUCENE-8288
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8288-repro.patch, LUCENE-8288.patch, 
> LUCENE-8288.patch
>
>
> When a RegexCompletionQuery of "." is provided to ContextQuery, the following 
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with a context separator 
> followed by SEP_LABEL
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:299)
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at 
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at 
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at 
> org.apache.lucene.search.suggest.document.TestContextQuery.testDotRegexQuery(TestContextQuery.java:188)
> {code}
> Note that this is a related, but distinct issue from 
> https://issues.apache.org/jira/browse/LUCENE-8287, where the 
> RegexCompletionQuery is empty.
> The attached patch provides a reproduction of the issue, as the test case 
> TestContextQuery#testRegexDotQuery. To reproduce, Java assertions must be 
> enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty 
> RegexCompletionQuery, when it is not wrapped in ContextQuery 
> (TestRegexCompletionQuery#testRegexDotQuery). In this case, there is no 
> error, and all suggestions are returned.
> From a quick look, it seems as though "." doesn't capture any characters past 
>  CompletionAnalyzer.SEP_LABEL, so the matching prefix in 
> ContextCompletionWeight#setInnerWeight is unexpectedly empty.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1539 - Still Unstable

2018-05-07 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1539/

2 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/40)={   
"replicationFactor":"2",   "pullReplicas":"0",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0",   
"autoCreated":"true",   "shards":{ "shard2":{   "replicas":{ 
"core_node3":{   
"core":"testSplitIntegration_collection_shard2_replica_n3",   
"leader":"true",   "SEARCHER.searcher.maxDoc":11,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":1,   
"node_name":"127.0.0.1:10001_solr",   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":11}, "core_node4":{ 
  "core":"testSplitIntegration_collection_shard2_replica_n4",   
"SEARCHER.searcher.maxDoc":11,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:1_solr",  
 "state":"active",   "type":"NRT",   
"SEARCHER.searcher.numDocs":11}},   "range":"0-7fff",   
"state":"active"}, "shard1":{   "stateTimestamp":"1525714553704979100", 
  "replicas":{ "core_node1":{   
"core":"testSplitIntegration_collection_shard1_replica_n1",   
"leader":"true",   "SEARCHER.searcher.maxDoc":14,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":1,   
"node_name":"127.0.0.1:10001_solr",   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":14}, "core_node2":{ 
  "core":"testSplitIntegration_collection_shard1_replica_n2",   
"SEARCHER.searcher.maxDoc":14,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:1_solr",  
 "state":"active",   "type":"NRT",   
"SEARCHER.searcher.numDocs":14}},   "range":"8000-",   
"state":"inactive"}, "shard1_1":{   "parent":"shard1",   
"stateTimestamp":"1525714553738107800",   "range":"c000-",  
 "state":"active",   "replicas":{ "core_node10":{   
"leader":"true",   
"core":"testSplitIntegration_collection_shard1_1_replica1",   
"SEARCHER.searcher.maxDoc":6,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":6}, 
"core_node9":{   
"core":"testSplitIntegration_collection_shard1_1_replica0",   
"SEARCHER.searcher.maxDoc":6,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":6}}}, "shard1_0":{  
 "parent":"shard1",   "stateTimestamp":"1525714553737785050",   
"range":"8000-bfff",   "state":"active",   "replicas":{ 
"core_node7":{   "leader":"true",   
"core":"testSplitIntegration_collection_shard1_0_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}, 
"core_node8":{   
"core":"testSplitIntegration_collection_shard1_0_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}

Stack Trace:
java.util.concurrent.TimeoutException: last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/40)={
  "replicationFactor":"2",
  "pullReplicas":"0",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0",
  "autoCreated":"true",
  "shards":{
"shard2":{
  "replicas":{
"core_node3":{
  "core":"testSplitIntegration_collection_shard2_replica_n3",
  "leader":"true",
  "SEARCHER.searcher.maxDoc":11,
  "SEARCHER.searcher.deletedDocs":0,
  "INDEX.sizeInBytes":1,
  "node_name":"127.0.0.1:10001_solr",
  "state":"active",
  "type":"NRT",
  

[jira] [Resolved] (SOLR-4528) Implementation numShards option in admin interface

2018-05-07 Thread JIRA

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

Jan Høydahl resolved SOLR-4528.
---
Resolution: Not A Problem

> Implementation numShards option in admin interface
> --
>
> Key: SOLR-4528
> URL: https://issues.apache.org/jira/browse/SOLR-4528
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 4.1
>Reporter: Arkadi Colson
>Priority: Major
>
> Currently it is possible to just start creating shards on nodes with the 
> admin interface without creating the collection first with the API. This way 
> of working creates a collection with having numShards = null in the zookeeper 
> config and giving trouble on updates. It would be great to have a numShards 
> field when creating the first shard/node of a collection.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-4052) Upload files to ZooKeeper from Solr Admin interface

2018-05-07 Thread JIRA

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

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

Is this still wanted even now when we have config set API and "bin/solr zk cp" 
capabilities?

> Upload files to ZooKeeper from Solr Admin interface
> ---
>
> Key: SOLR-4052
> URL: https://issues.apache.org/jira/browse/SOLR-4052
> Project: Solr
>  Issue Type: Improvement
>Reporter: Eric Pugh
>Priority: Major
> Attachments: ZookeeperInfoServletTest.java, zookeeper_edit.patch
>
>
> It would be nice if you could add files to ZooKeeper through the solr admin 
> tool instead of having to use the zkCli.  Steffan and I talked about this at 
> ApacheCon Euro, and he suggested that if I put the java code in place, he'll 
> put in the pretty GUI aspects!  This patch is based around using a tool like 
> http://blueimp.github.com/jQuery-File-Upload/ to upload to a java servlet.  I 
> hung this code off the ZookeeperInfoServlet doPost method mostly b/c I didn't 
> have a better sense of where it should go.   A *very* annoying thing is that 
> it seems like from the browser side you can't select a directory of files and 
> upload it, which would make loading a new solr core configuration split 
> across many directory VERY annoying.   Also, this doesn't really feel like a 
> solid solution to just pulling up a file in the ZK tree browser webpage, 
> editing it (maybe via a big text box) and then posting the contents back.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12312) Replication's IndexFetcher buf size can be initialized smarter to not waste RAM/GC

2018-05-07 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12312:


Commit 93f9cc71b127b84c432bf40e115fd4afe689bd8a in lucene-solr's branch 
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=93f9cc7 ]

SOLR-12312: Replication's IndexFetcher buf size should be initialized
to an amount no greater than the size of the file being transferred.

(cherry picked from commit 81f6112)


> Replication's IndexFetcher buf size can be initialized smarter to not waste 
> RAM/GC
> --
>
> Key: SOLR-12312
> URL: https://issues.apache.org/jira/browse/SOLR-12312
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> IndexFetcher's constructor knows the size of the file it's going to transfer. 
>  As-such, it ought to initialize the "buf" field to no larger than this size. 
>  This has been shown to waste Java heap/GC in  an environment with lots of 
> cores of small indexes and thus small files.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12312) Replication's IndexFetcher buf size can be initialized smarter to not waste RAM/GC

2018-05-07 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12312:


Commit 81f611209c9b71b7538a46d047631ea164dc2a2c in lucene-solr's branch 
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=81f6112 ]

SOLR-12312: Replication's IndexFetcher buf size should be initialized
to an amount no greater than the size of the file being transferred.


> Replication's IndexFetcher buf size can be initialized smarter to not waste 
> RAM/GC
> --
>
> Key: SOLR-12312
> URL: https://issues.apache.org/jira/browse/SOLR-12312
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> IndexFetcher's constructor knows the size of the file it's going to transfer. 
>  As-such, it ought to initialize the "buf" field to no larger than this size. 
>  This has been shown to waste Java heap/GC in  an environment with lots of 
> cores of small indexes and thus small files.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8273) Add a ConditionalTokenFilter

2018-05-07 Thread David Smiley (JIRA)

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

David Smiley commented on LUCENE-8273:
--

Looks good Alan.
 * Maybe make {{ConditionBuilder whenTerm(Predicate 
predicate)}} even simpler by referring to CharSequence in the predicate instead 
of CharTermAttribute? This is just a convenience method after all; and it keeps 
the caller immune to some lower level details like Attributes. And it somewhat 
prevents them from using mutable methods on CharTermAttribute which would be 
pretty nasty.

> Add a ConditionalTokenFilter
> 
>
> Key: LUCENE-8273
> URL: https://issues.apache.org/jira/browse/LUCENE-8273
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, 
> LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch
>
>
> Spinoff of LUCENE-8265.  It would be useful to be able to wrap a TokenFilter 
> in such a way that it could optionally be bypassed based on the current state 
> of the TokenStream.  This could be used to, for example, only apply 
> WordDelimiterFilter to terms that contain hyphens.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (SOLR-12327) 'bin/solr status' should be able to produce output as pure JSON

2018-05-07 Thread Simon Rosenthal (JIRA)

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

Simon Rosenthal resolved SOLR-12327.

Resolution: Not A Problem

Didn't realize that 

*curl 'http://localhost:8983/solr/admin/info/system'*

will return  pure JON with that information

> 'bin/solr status' should be able to produce output as pure JSON
> ---
>
> Key: SOLR-12327
> URL: https://issues.apache.org/jira/browse/SOLR-12327
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.2
>Reporter: Simon Rosenthal
>Priority: Minor
>
> The 'bin/solr status' command should optionally (so as not to break back 
> compat) produce its outputs in pure JSON, for easier parsing, rather than a 
> mixture of free text and JSON as it does at present.
> e.g.
> {{prompt# bin/solr status purejson}}
> {{ {}}
> {{# these two lines replace "Solr process  on port "}}
> {{ *"solr_port":"8983",*}}
> {{ *"solr_pid":"14020",*}}
> {{ "solr_home":"/home/user/solr-7.2.1/server/solr",}}
> {{ "version":"7.2.1 b2b6438b37073bee1fca40374e85bf91aa457c0b - ubuntu - 
> 2018-01-10 00:54:21",}}
> {{ "startTime":"2018-05-02T13:51:43.388Z",}}
> {{ "uptime":"5 days, 2 hours, 39 minutes, 35 seconds",}}
> {{ "memory":"1.2 GB (%25.7) of 4.8 GB",}}
> {{ "cloud":{}}
> {{ "ZooKeeper":"localhost:9983",}}
> {{ "liveNodes":"1",}}
> {{ "collections":"1"
> The use case here is mapping a solr port (where that is the only available 
> information about the Solr instance) to ZK host/port(s) for a subsequent call 
> to zkcli.sh.
>  
> {{ }}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (SOLR-12327) 'bin/solr status' should be able to produce output as pure JSON

2018-05-07 Thread Simon Rosenthal (JIRA)

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

Simon Rosenthal edited comment on SOLR-12327 at 5/7/18 5:39 PM:


Didn't realize that 

*curl 'http://localhost:8983/solr/admin/info/system'*

will return  pure JSON with that information


was (Author: simon.rosenthal):
Didn't realize that 

*curl 'http://localhost:8983/solr/admin/info/system'*

will return  pure JON with that information

> 'bin/solr status' should be able to produce output as pure JSON
> ---
>
> Key: SOLR-12327
> URL: https://issues.apache.org/jira/browse/SOLR-12327
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.2
>Reporter: Simon Rosenthal
>Priority: Minor
>
> The 'bin/solr status' command should optionally (so as not to break back 
> compat) produce its outputs in pure JSON, for easier parsing, rather than a 
> mixture of free text and JSON as it does at present.
> e.g.
> {{prompt# bin/solr status purejson}}
> {{ {}}
> {{# these two lines replace "Solr process  on port "}}
> {{ *"solr_port":"8983",*}}
> {{ *"solr_pid":"14020",*}}
> {{ "solr_home":"/home/user/solr-7.2.1/server/solr",}}
> {{ "version":"7.2.1 b2b6438b37073bee1fca40374e85bf91aa457c0b - ubuntu - 
> 2018-01-10 00:54:21",}}
> {{ "startTime":"2018-05-02T13:51:43.388Z",}}
> {{ "uptime":"5 days, 2 hours, 39 minutes, 35 seconds",}}
> {{ "memory":"1.2 GB (%25.7) of 4.8 GB",}}
> {{ "cloud":{}}
> {{ "ZooKeeper":"localhost:9983",}}
> {{ "liveNodes":"1",}}
> {{ "collections":"1"
> The use case here is mapping a solr port (where that is the only available 
> information about the Solr instance) to ZK host/port(s) for a subsequent call 
> to zkcli.sh.
>  
> {{ }}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (LUCENE-8287) ContextQuery with empty RegexCompletionQuery produces an assertion failure

2018-05-07 Thread Julie Tibshirani (JIRA)

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

Julie Tibshirani edited comment on LUCENE-8287 at 5/7/18 5:37 PM:
--

I uploaded a patch that throws an IllegalArgumentException if an empty term is 
passed to RegexCompletionQuery.

This approach certainly works, but I noticed that this behavior is a bit 
inconsistent with a normal RegexpQuery, where an empty term is accepted, but 
the query produces no results. [~jim.ferenczi] would it be better to have an 
empty regex completion query return no results, or is the discrepancy not too 
concerning to you?


was (Author: jtibshirani):
I uploaded a patch that throws an IllegalArgumentException if an empty term is 
passed to RegexCompletionQuery.

This approach certainly works, but I just wanted to note that the behavior is a 
bit inconsistent with a normal RegexpQuery, where an empty term is accepted, 
but the query produces no results.

> ContextQuery with empty RegexCompletionQuery produces an assertion failure
> --
>
> Key: LUCENE-8287
> URL: https://issues.apache.org/jira/browse/LUCENE-8287
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8287-repro.patch, LUCENE-8287.patch
>
>
> When an empty RegexCompletionQuery is provided to ContextQuery, the following 
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with the context separator
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:296)
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at 
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at 
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at 
> org.apache.lucene.search.suggest.document.TestContextQuery.testEmptyRegexQuery(TestContextQuery.java:193)
> {code}
> This is a bit of an edge case, but may be concerning since without assertions 
> enabled, you can go on to access IntsRef indices that are out of bounds.
> The attached patch provides a reproduction of the issue, as the test case 
> TestContextQuery#testEmptyRegexQuery. Note that to reproduce, Java assertions 
> must be enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty 
> RegexCompletionQuery, when it is not wrapped in ContextQuery 
> (TestRegexCompletionQuery#testEmptyRegexQuery). In this case, there is no 
> error, and all suggestions are returned. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (LUCENE-8287) ContextQuery with empty RegexCompletionQuery produces an assertion failure

2018-05-07 Thread Julie Tibshirani (JIRA)

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

Julie Tibshirani edited comment on LUCENE-8287 at 5/7/18 5:32 PM:
--

I uploaded a patch that throws an IllegalArgumentException if an empty term is 
passed to RegexCompletionQuery.

This approach certainly works, but I just wanted to note that the behavior is a 
bit inconsistent with a normal RegexpQuery, where an empty term is accepted, 
but the query produces no results.


was (Author: jtibshirani):
I uploaded a patch that throws an IllegalArgumentException if an empty term is 
passed to RegexCompletionQuery.

This approach certainly works, but I just wanted to note that the behavior is a 
bit different in a normal RegexpQuery, where an empty term is accepted, but the 
query produces no results.

> ContextQuery with empty RegexCompletionQuery produces an assertion failure
> --
>
> Key: LUCENE-8287
> URL: https://issues.apache.org/jira/browse/LUCENE-8287
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8287-repro.patch, LUCENE-8287.patch
>
>
> When an empty RegexCompletionQuery is provided to ContextQuery, the following 
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with the context separator
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:296)
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at 
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at 
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at 
> org.apache.lucene.search.suggest.document.TestContextQuery.testEmptyRegexQuery(TestContextQuery.java:193)
> {code}
> This is a bit of an edge case, but may be concerning since without assertions 
> enabled, you can go on to access IntsRef indices that are out of bounds.
> The attached patch provides a reproduction of the issue, as the test case 
> TestContextQuery#testEmptyRegexQuery. Note that to reproduce, Java assertions 
> must be enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty 
> RegexCompletionQuery, when it is not wrapped in ContextQuery 
> (TestRegexCompletionQuery#testEmptyRegexQuery). In this case, there is no 
> error, and all suggestions are returned. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8287) ContextQuery with empty RegexCompletionQuery produces an assertion failure

2018-05-07 Thread Julie Tibshirani (JIRA)

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

Julie Tibshirani commented on LUCENE-8287:
--

I uploaded a patch that throws an IllegalArgumentException if an empty term is 
passed to RegexCompletionQuery.

This approach certainly works, but I just wanted to note that the behavior is a 
bit different in a normal RegexpQuery, where an empty term is accepted, but the 
query produces no results.

> ContextQuery with empty RegexCompletionQuery produces an assertion failure
> --
>
> Key: LUCENE-8287
> URL: https://issues.apache.org/jira/browse/LUCENE-8287
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8287-repro.patch, LUCENE-8287.patch
>
>
> When an empty RegexCompletionQuery is provided to ContextQuery, the following 
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with the context separator
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:296)
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at 
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at 
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at 
> org.apache.lucene.search.suggest.document.TestContextQuery.testEmptyRegexQuery(TestContextQuery.java:193)
> {code}
> This is a bit of an edge case, but may be concerning since without assertions 
> enabled, you can go on to access IntsRef indices that are out of bounds.
> The attached patch provides a reproduction of the issue, as the test case 
> TestContextQuery#testEmptyRegexQuery. Note that to reproduce, Java assertions 
> must be enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty 
> RegexCompletionQuery, when it is not wrapped in ContextQuery 
> (TestRegexCompletionQuery#testEmptyRegexQuery). In this case, there is no 
> error, and all suggestions are returned. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (LUCENE-8287) ContextQuery with empty RegexCompletionQuery produces an assertion failure

2018-05-07 Thread Julie Tibshirani (JIRA)

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

Julie Tibshirani updated LUCENE-8287:
-
Attachment: LUCENE-8287.patch

> ContextQuery with empty RegexCompletionQuery produces an assertion failure
> --
>
> Key: LUCENE-8287
> URL: https://issues.apache.org/jira/browse/LUCENE-8287
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8287-repro.patch, LUCENE-8287.patch
>
>
> When an empty RegexCompletionQuery is provided to ContextQuery, the following 
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with the context separator
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:296)
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at 
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at 
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at 
> org.apache.lucene.search.suggest.document.TestContextQuery.testEmptyRegexQuery(TestContextQuery.java:193)
> {code}
> This is a bit of an edge case, but may be concerning since without assertions 
> enabled, you can go on to access IntsRef indices that are out of bounds.
> The attached patch provides a reproduction of the issue, as the test case 
> TestContextQuery#testEmptyRegexQuery. Note that to reproduce, Java assertions 
> must be enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty 
> RegexCompletionQuery, when it is not wrapped in ContextQuery 
> (TestRegexCompletionQuery#testEmptyRegexQuery). In this case, there is no 
> error, and all suggestions are returned. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12303) Subquery Doc transform doesn't inherit path from original request

2018-05-07 Thread Munendra S N (JIRA)

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

Munendra S N commented on SOLR-12303:
-

 [^SOLR-12303.patch] 
I have added test when handleSelect=true(handleSelect=false is default previous 
tests covers this case) and default is enabled/disabled

> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, 
> SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, 
> SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId 
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
>  qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request 
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should 
> be an option to override this behavior. (option to override is already 
> available by specifying *qt*)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-12303) Subquery Doc transform doesn't inherit path from original request

2018-05-07 Thread Munendra S N (JIRA)

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

Munendra S N updated SOLR-12303:

Attachment: SOLR-12303.patch

> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, 
> SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, 
> SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId 
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
>  qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request 
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should 
> be an option to override this behavior. (option to override is already 
> available by specifying *qt*)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12314) ConcurrentUpdateSolrClient doesn't respect the timeout's defined in the solr.xml file

2018-05-07 Thread Varun Thacker (JIRA)

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

Varun Thacker commented on SOLR-12314:
--

CUSC is a SolrJ public API so as Mark pointed out we can simply omit the socket 
timeout's and connection timeout's that the user is specifying in the 
constructor.

In this approach when StreamingSolrClients creates a CUSC object to send data , 
we basically read the socket timeout's and connection timeout's from the 
UpdateShardHandler / UpdateShardHandlerConfig and set it explicitly. If the 
user has specifying none/only one of them then default values will be used for 
the timeout's that weren't specified. 

> ConcurrentUpdateSolrClient doesn't respect the timeout's defined in the 
> solr.xml file
> -
>
> Key: SOLR-12314
> URL: https://issues.apache.org/jira/browse/SOLR-12314
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12314.patch, SOLR-12314.patch
>
>
> In ConcurrentUpdateSolrClient we create an HttpPost Request which allows you 
> to set a request config. If the request config is not provided httpclient 
> will use the default request config. 
>  
> {code:java}
> org.apache.http.client.config.RequestConfig.Builder requestConfigBuilder = 
> HttpClientUtil.createDefaultRequestConfigBuilder();
> if (soTimeout != null) {
>   requestConfigBuilder.setSocketTimeout(soTimeout);
> }
> if (connectionTimeout != null) {
>   requestConfigBuilder.setConnectTimeout(connectionTimeout);
> }
> method.setConfig(requestConfigBuilder.build());{code}
> While creating the httpclient object we ensure that the default request is 
> set with the properties we care about.  This happens in 
> HttpClientUtils#setupBuilder
> {code:java}
> RequestConfig requestConfig = requestConfigBuilder.build();
> HttpClientBuilder retBuilder = 
> builder.setDefaultRequestConfig(requestConfig);{code}
> So there is no need to set a per request config 
>  
> Here is where the httpclient picks the request config is provided on the 
> request itself : 
> [https://github.com/apache/httpcomponents-client/blob/4.5.3/httpclient/src/main/java/org/apache/http/impl/client/InternalHttpClient.java#L168]
>  
> And if it's not provided it uses the default here : 
> https://github.com/apache/httpcomponents-client/blob/4.5.3/httpclient/src/main/java/org/apache/http/impl/client/InternalHttpClient.java#L148



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-12314) ConcurrentUpdateSolrClient doesn't respect the timeout's defined in the solr.xml file

2018-05-07 Thread Varun Thacker (JIRA)

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

Varun Thacker updated SOLR-12314:
-
Attachment: SOLR-12314.patch

> ConcurrentUpdateSolrClient doesn't respect the timeout's defined in the 
> solr.xml file
> -
>
> Key: SOLR-12314
> URL: https://issues.apache.org/jira/browse/SOLR-12314
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12314.patch, SOLR-12314.patch
>
>
> In ConcurrentUpdateSolrClient we create an HttpPost Request which allows you 
> to set a request config. If the request config is not provided httpclient 
> will use the default request config. 
>  
> {code:java}
> org.apache.http.client.config.RequestConfig.Builder requestConfigBuilder = 
> HttpClientUtil.createDefaultRequestConfigBuilder();
> if (soTimeout != null) {
>   requestConfigBuilder.setSocketTimeout(soTimeout);
> }
> if (connectionTimeout != null) {
>   requestConfigBuilder.setConnectTimeout(connectionTimeout);
> }
> method.setConfig(requestConfigBuilder.build());{code}
> While creating the httpclient object we ensure that the default request is 
> set with the properties we care about.  This happens in 
> HttpClientUtils#setupBuilder
> {code:java}
> RequestConfig requestConfig = requestConfigBuilder.build();
> HttpClientBuilder retBuilder = 
> builder.setDefaultRequestConfig(requestConfig);{code}
> So there is no need to set a per request config 
>  
> Here is where the httpclient picks the request config is provided on the 
> request itself : 
> [https://github.com/apache/httpcomponents-client/blob/4.5.3/httpclient/src/main/java/org/apache/http/impl/client/InternalHttpClient.java#L168]
>  
> And if it's not provided it uses the default here : 
> https://github.com/apache/httpcomponents-client/blob/4.5.3/httpclient/src/main/java/org/apache/http/impl/client/InternalHttpClient.java#L148



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (SOLR-12327) 'bin/solr status' should be able to produce output as pure JSON

2018-05-07 Thread Simon Rosenthal (JIRA)
Simon Rosenthal created SOLR-12327:
--

 Summary: 'bin/solr status' should be able to produce output as 
pure JSON
 Key: SOLR-12327
 URL: https://issues.apache.org/jira/browse/SOLR-12327
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: scripts and tools
Affects Versions: 7.2
Reporter: Simon Rosenthal


The 'bin/solr status' command should optionally (so as not to break back 
compat) produce its outputs in pure JSON, for easier parsing, rather than a 
mixture of free text and JSON as it does at present.

e.g.

{{prompt# bin/solr status purejson}}
{{ {}}

{{# these two lines replace "Solr process  on port "}}
{{ *"solr_port":"8983",*}}
{{ *"solr_pid":"14020",*}}
{{ "solr_home":"/home/user/solr-7.2.1/server/solr",}}
{{ "version":"7.2.1 b2b6438b37073bee1fca40374e85bf91aa457c0b - ubuntu - 
2018-01-10 00:54:21",}}
{{ "startTime":"2018-05-02T13:51:43.388Z",}}
{{ "uptime":"5 days, 2 hours, 39 minutes, 35 seconds",}}
{{ "memory":"1.2 GB (%25.7) of 4.8 GB",}}
{{ "cloud":{}}
{{ "ZooKeeper":"localhost:9983",}}
{{ "liveNodes":"1",}}
{{ "collections":"1"

The use case here is mapping a solr port (where that is the only available 
information about the Solr instance) to ZK host/port(s) for a subsequent call 
to zkcli.sh.

 


{{ }}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (SOLR-12326) Unnecessary refinement requests

2018-05-07 Thread Yonik Seeley (JIRA)
Yonik Seeley created SOLR-12326:
---

 Summary: Unnecessary refinement requests
 Key: SOLR-12326
 URL: https://issues.apache.org/jira/browse/SOLR-12326
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Facet Module
Reporter: Yonik Seeley


TestJsonFacets.testStatsDistrib() appears to result in more refinement requests 
than would otherwise be expected.  Those tests were developed before refinement 
was implemented and hence do not need refinement to generate correct results 
due to limited numbers of buckets.  This should be detectable by refinement 
code in the majority of cases to prevent extra work from being done.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12265) Upgrade Jetty to 9.4.9

2018-05-07 Thread Varun Thacker (JIRA)

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

Varun Thacker commented on SOLR-12265:
--

Cool! I'll work on getting it upgraded now. 

The "ReadPendingException"  that I had mentioned on the Jira description is 
likely still gonna remain a problem according to this discussion : 
[https://dev.eclipse.org/mhonarc/lists/jetty-dev/msg03165.html]

But I feel it's worth upgrading to 9.4.10

> Upgrade Jetty to 9.4.9
> --
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>
> Solr 7.3 upgraded to Jetty 9.4.8 
> We're seeing this WARN very sporadically ( maybe one in every 100k requests ) 
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) - 
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for 
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28 
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0 
> of 
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
>  of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a 
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was 
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x 
> and then in Jetty 9.4.9 this class has undergone quite a few changes 
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
>  . 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12170) terms facet on a date field can fail

2018-05-07 Thread Yonik Seeley (JIRA)

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

Yonik Seeley commented on SOLR-12170:
-

Attached draft patch that seems to fix the issues I've found so far.

> terms facet on a date field can fail
> 
>
> Key: SOLR-12170
> URL: https://issues.apache.org/jira/browse/SOLR-12170
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 6.6
>Reporter: Yonik Seeley
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12170.patch
>
>
> There are still some modes of failures when doing a terms facet on a date 
> field.  This issue picks up from SOLR-12020 since the fixes likely won't make 
> it in time for the 7.3 release.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-12170) terms facet on a date field can fail

2018-05-07 Thread Yonik Seeley (JIRA)

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

Yonik Seeley updated SOLR-12170:

Attachment: SOLR-12170.patch

> terms facet on a date field can fail
> 
>
> Key: SOLR-12170
> URL: https://issues.apache.org/jira/browse/SOLR-12170
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 6.6
>Reporter: Yonik Seeley
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12170.patch
>
>
> There are still some modes of failures when doing a terms facet on a date 
> field.  This issue picks up from SOLR-12020 since the fixes likely won't make 
> it in time for the 7.3 release.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12265) Upgrade Jetty to 9.4.9

2018-05-07 Thread Michael Braun (JIRA)

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

Michael Braun commented on SOLR-12265:
--

[~varunthacker] Jetty 9.4.10 is out - 
https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.10.v20180503

> Upgrade Jetty to 9.4.9
> --
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>
> Solr 7.3 upgraded to Jetty 9.4.8 
> We're seeing this WARN very sporadically ( maybe one in every 100k requests ) 
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) - 
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for 
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28 
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0 
> of 
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
>  of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a 
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was 
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x 
> and then in Jetty 9.4.9 this class has undergone quite a few changes 
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
>  . 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (LUCENE-8288) Context query with regex "." produces an assertion failure

2018-05-07 Thread Julie Tibshirani (JIRA)

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

Julie Tibshirani edited comment on LUCENE-8288 at 5/7/18 4:42 PM:
--

Thank you [~jim.ferenczi]! I'm looking forward to this fix going in, as we're 
hoping to use a "." regex completion query as part of an elasticsearch 
enhancement 
([https://github.com/elastic/elasticsearch/issues/19147)|https://github.com/elastic/elasticsearch/issues/19147),].


was (Author: jtibshirani):
Thank you [~jim.ferenczi]! I'm looking forward to this fix going in, as we're 
hoping to use a "." regex completion query as part of an elasticsearch ticket 
([https://github.com/elastic/elasticsearch/issues/19147)|https://github.com/elastic/elasticsearch/issues/19147),].

> Context query with regex "." produces an assertion failure
> --
>
> Key: LUCENE-8288
> URL: https://issues.apache.org/jira/browse/LUCENE-8288
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8288-repro.patch, LUCENE-8288.patch
>
>
> When a RegexCompletionQuery of "." is provided to ContextQuery, the following 
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with a context separator 
> followed by SEP_LABEL
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:299)
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at 
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at 
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at 
> org.apache.lucene.search.suggest.document.TestContextQuery.testDotRegexQuery(TestContextQuery.java:188)
> {code}
> Note that this is a related, but distinct issue from 
> https://issues.apache.org/jira/browse/LUCENE-8287, where the 
> RegexCompletionQuery is empty.
> The attached patch provides a reproduction of the issue, as the test case 
> TestContextQuery#testRegexDotQuery. To reproduce, Java assertions must be 
> enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty 
> RegexCompletionQuery, when it is not wrapped in ContextQuery 
> (TestRegexCompletionQuery#testRegexDotQuery). In this case, there is no 
> error, and all suggestions are returned.
> From a quick look, it seems as though "." doesn't capture any characters past 
>  CompletionAnalyzer.SEP_LABEL, so the matching prefix in 
> ContextCompletionWeight#setInnerWeight is unexpectedly empty.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8288) Context query with regex "." produces an assertion failure

2018-05-07 Thread Julie Tibshirani (JIRA)

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

Julie Tibshirani commented on LUCENE-8288:
--

Thank you [~jim.ferenczi]! I'm looking forward to this fix going in, as we're 
hoping to use a "." regex completion query as part of an elasticsearch ticket 
([https://github.com/elastic/elasticsearch/issues/19147)|https://github.com/elastic/elasticsearch/issues/19147),].

> Context query with regex "." produces an assertion failure
> --
>
> Key: LUCENE-8288
> URL: https://issues.apache.org/jira/browse/LUCENE-8288
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8288-repro.patch, LUCENE-8288.patch
>
>
> When a RegexCompletionQuery of "." is provided to ContextQuery, the following 
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with a context separator 
> followed by SEP_LABEL
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:299)
> at 
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at 
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at 
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at 
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at 
> org.apache.lucene.search.suggest.document.TestContextQuery.testDotRegexQuery(TestContextQuery.java:188)
> {code}
> Note that this is a related, but distinct issue from 
> https://issues.apache.org/jira/browse/LUCENE-8287, where the 
> RegexCompletionQuery is empty.
> The attached patch provides a reproduction of the issue, as the test case 
> TestContextQuery#testRegexDotQuery. To reproduce, Java assertions must be 
> enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty 
> RegexCompletionQuery, when it is not wrapped in ContextQuery 
> (TestRegexCompletionQuery#testRegexDotQuery). In this case, there is no 
> error, and all suggestions are returned.
> From a quick look, it seems as though "." doesn't capture any characters past 
>  CompletionAnalyzer.SEP_LABEL, so the matching prefix in 
> ContextCompletionWeight#setInnerWeight is unexpectedly empty.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8261) InterpolatedProperties.interpolate and recursive property references

2018-05-07 Thread Steve Rowe (JIRA)

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

Steve Rowe commented on LUCENE-8261:


Belated +1, [~dweiss], thanks for working on it!

One tiny nit: the class and {{load()}} methods' javadoc still say:

{code:java}
/**
 * Parse a properties file, performing non-recursive Ant-like
 * property value interpolation, and return the resulting Properties.
 */
[...]
  /**
   * Loads the properties file via {@link Properties#load(InputStream)},
   * then performs non-recursive Ant-like property value interpolation.
   */
{code}

{{s/non-recursive/recursive/g}} ?

> InterpolatedProperties.interpolate and recursive property references
> 
>
> Key: LUCENE-8261
> URL: https://issues.apache.org/jira/browse/LUCENE-8261
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.4
>
> Attachments: LUCENE-8261.patch, LUCENE-8261.patch
>
>
> InterpolatedProperties is used in lib check tasks in the build file. I 
> occasionally see this:
> {code}
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/custom-tasks.xml:108:
>  java.lang.IllegalArgumentException: named capturing group is missing 
> trailing '}'
> at 
> java.base/java.util.regex.Matcher.appendExpandedReplacement(Matcher.java:1052)
> at 
> java.base/java.util.regex.Matcher.appendReplacement(Matcher.java:908)
> at 
> org.apache.lucene.dependencies.InterpolatedProperties.interpolate(InterpolatedProperties.java:64)
> {code}
> I don't think we ever need to use any group references in those replacements; 
> they should be fixed strings (quoted verbatim)? So 
> {{Pattern.quoteReplacement}} would be adequate here.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (SOLR-12323) Missing explain information

2018-05-07 Thread Stefan Langenmaier (JIRA)

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

Stefan Langenmaier resolved SOLR-12323.
---
Resolution: Duplicate

> Missing explain information
> ---
>
> Key: SOLR-12323
> URL: https://issues.apache.org/jira/browse/SOLR-12323
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Stefan Langenmaier
>Priority: Major
>
> We have a problem in Solr 7.3 with the explain field when the edismax query 
> parser is used with the boost parameter.
> To reproduce the issue I created a collection "mycollection" with the default 
> configset and indexed the following csv data:
> {code:java}
> title_txt,rating_i
> mytext,2
> {code}
> When I issue the following query to analyse the computation of the score
> [http://localhost:8983/solr/mycollection/select?boost=rating_i=edismax=*,score,[explain]=title_txt:mytext]
>  
> I receive the following response:
> {code:java}
> {
>   "responseHeader":{
> "status":0,
> "QTime":3,
> "params":{
>   "q":"title_txt:mytext",
>   "defType":"edismax",
>   "fl":"*,score,[explain]",
>   "boost":"rating_i"}},
>   "response":{"numFound":1,"start":0,"maxScore":0.5753642,"docs":[
>   {
> "title_txt":["mytext"],
> "rating_i":2,
> "id":"3a7299dc-9628-403b-935b-0ddf17e74897",
> "_version_":1599803310411350016,
> "score":0.5753642,
> "[explain]":"0.5753642 = product of:\n  1.0 = boost\n  0.5753642 = 
> boost(int(rating_i))\n"}]
>   }}
> {code}
> The explain no longer contains all the information of the score. For 
> comparison with Solr 7.2.1 but otherwise the same setup the output looks like 
> this:
> {code:java}
> {
>   "responseHeader":{
> "status":0,
> "QTime":3,
> "params":{
>   "q":"title_txt:mytext",
>   "defType":"edismax",
>   "fl":"*,score,[explain]",
>   "boost":"rating_i"}},
>   "response":{"numFound":1,"start":0,"maxScore":0.5753642,"docs":[
>   {
> "title_txt":["mytext"],
> "rating_i":2,
> "id":"747b9102-0566-4786-a155-87fac10388cc",
> "_version_":1599803926880714752,
> "score":0.5753642,
> "[explain]":"0.5753642 = boost(title_txt:mytext,int(rating_i)), 
> product of:\n  0.2876821 = weight(title_txt:mytext in 0) [SchemaSimilarity], 
> result of:\n0.2876821 = score(doc=0,freq=1.0 = termFreq=1.0\n), product 
> of:\n  0.2876821 = idf, computed as log(1 + (docCount - docFreq + 0.5) / 
> (docFreq + 0.5)) from:\n1.0 = docFreq\n1.0 = docCount\n  
> 1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * 
> fieldLength / avgFieldLength)) from:\n1.0 = termFreq=1.0\n1.2 
> = parameter k1\n0.75 = parameter b\n1.0 = avgFieldLength\n
> 1.0 = fieldLength\n  2.0 = int(rating_i)=2\n"}]
>   }}
> {code}
> When the boost parameter gets remove Solr 7.3 also show the calculation again:
> {code:java}
> {
>   "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
>   "q":"title_txt:mytext",
>   "defType":"edismax",
>   "fl":"*,score,[explain]"}},
>   "response":{"numFound":1,"start":0,"maxScore":0.2876821,"docs":[
>   {
> "title_txt":["mytext"],
> "rating_i":2,
> "id":"3a7299dc-9628-403b-935b-0ddf17e74897",
> "_version_":1599803310411350016,
> "score":0.2876821,
> "[explain]":"0.2876821 = weight(title_txt:mytext in 0) 
> [SchemaSimilarity], result of:\n  0.2876821 = score(doc=0,freq=1.0 = 
> termFreq=1.0\n), product of:\n0.2876821 = idf, computed as log(1 + 
> (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n  1.0 = docFreq\n
>   1.0 = docCount\n1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + 
> k1 * (1 - b + b * fieldLength / avgFieldLength)) from:\n  1.0 = 
> termFreq=1.0\n  1.2 = parameter k1\n  0.75 = parameter b\n  1.0 = 
> avgFieldLength\n  1.0 = fieldLength\n"}]
>   }}
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12323) Missing explain information

2018-05-07 Thread Stefan Langenmaier (JIRA)

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

Stefan Langenmaier commented on SOLR-12323:
---

This seems to be the same issue. I have the same problem with debugQuery=on.

> Missing explain information
> ---
>
> Key: SOLR-12323
> URL: https://issues.apache.org/jira/browse/SOLR-12323
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Stefan Langenmaier
>Priority: Major
>
> We have a problem in Solr 7.3 with the explain field when the edismax query 
> parser is used with the boost parameter.
> To reproduce the issue I created a collection "mycollection" with the default 
> configset and indexed the following csv data:
> {code:java}
> title_txt,rating_i
> mytext,2
> {code}
> When I issue the following query to analyse the computation of the score
> [http://localhost:8983/solr/mycollection/select?boost=rating_i=edismax=*,score,[explain]=title_txt:mytext]
>  
> I receive the following response:
> {code:java}
> {
>   "responseHeader":{
> "status":0,
> "QTime":3,
> "params":{
>   "q":"title_txt:mytext",
>   "defType":"edismax",
>   "fl":"*,score,[explain]",
>   "boost":"rating_i"}},
>   "response":{"numFound":1,"start":0,"maxScore":0.5753642,"docs":[
>   {
> "title_txt":["mytext"],
> "rating_i":2,
> "id":"3a7299dc-9628-403b-935b-0ddf17e74897",
> "_version_":1599803310411350016,
> "score":0.5753642,
> "[explain]":"0.5753642 = product of:\n  1.0 = boost\n  0.5753642 = 
> boost(int(rating_i))\n"}]
>   }}
> {code}
> The explain no longer contains all the information of the score. For 
> comparison with Solr 7.2.1 but otherwise the same setup the output looks like 
> this:
> {code:java}
> {
>   "responseHeader":{
> "status":0,
> "QTime":3,
> "params":{
>   "q":"title_txt:mytext",
>   "defType":"edismax",
>   "fl":"*,score,[explain]",
>   "boost":"rating_i"}},
>   "response":{"numFound":1,"start":0,"maxScore":0.5753642,"docs":[
>   {
> "title_txt":["mytext"],
> "rating_i":2,
> "id":"747b9102-0566-4786-a155-87fac10388cc",
> "_version_":1599803926880714752,
> "score":0.5753642,
> "[explain]":"0.5753642 = boost(title_txt:mytext,int(rating_i)), 
> product of:\n  0.2876821 = weight(title_txt:mytext in 0) [SchemaSimilarity], 
> result of:\n0.2876821 = score(doc=0,freq=1.0 = termFreq=1.0\n), product 
> of:\n  0.2876821 = idf, computed as log(1 + (docCount - docFreq + 0.5) / 
> (docFreq + 0.5)) from:\n1.0 = docFreq\n1.0 = docCount\n  
> 1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * 
> fieldLength / avgFieldLength)) from:\n1.0 = termFreq=1.0\n1.2 
> = parameter k1\n0.75 = parameter b\n1.0 = avgFieldLength\n
> 1.0 = fieldLength\n  2.0 = int(rating_i)=2\n"}]
>   }}
> {code}
> When the boost parameter gets remove Solr 7.3 also show the calculation again:
> {code:java}
> {
>   "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
>   "q":"title_txt:mytext",
>   "defType":"edismax",
>   "fl":"*,score,[explain]"}},
>   "response":{"numFound":1,"start":0,"maxScore":0.2876821,"docs":[
>   {
> "title_txt":["mytext"],
> "rating_i":2,
> "id":"3a7299dc-9628-403b-935b-0ddf17e74897",
> "_version_":1599803310411350016,
> "score":0.2876821,
> "[explain]":"0.2876821 = weight(title_txt:mytext in 0) 
> [SchemaSimilarity], result of:\n  0.2876821 = score(doc=0,freq=1.0 = 
> termFreq=1.0\n), product of:\n0.2876821 = idf, computed as log(1 + 
> (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n  1.0 = docFreq\n
>   1.0 = docCount\n1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + 
> k1 * (1 - b + b * fieldLength / avgFieldLength)) from:\n  1.0 = 
> termFreq=1.0\n  1.2 = parameter k1\n  0.75 = parameter b\n  1.0 = 
> avgFieldLength\n  1.0 = fieldLength\n"}]
>   }}
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12243) Edismax missing phrase queries when phrases contain multiterm synonyms

2018-05-07 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-12243:
-

I have not been following code changes on this issue.  But I have been seeing 
frequent failures in Solr tests even with a completely unmodified code 
checkout.  This is what Erick is trying to fix with his recent work on tests.

Until tests reach the point where they pass on virtually all runs, test 
failures in the automatic patch validation are to be expected, and it's not 
straightforward to know whether they indicate a problem in the patch.  That 
DOES mean that automatic patch validation isn't as useful as it could be.  The 
problem is known and is not being ignored.


> Edismax missing phrase queries when phrases contain multiterm synonyms
> --
>
> Key: SOLR-12243
> URL: https://issues.apache.org/jira/browse/SOLR-12243
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 7.1
> Environment: RHEL, MacOS X
> Do not believe this is environment-specific.
>Reporter: Elizabeth Haubert
>Priority: Major
> Attachments: SOLR-12243.patch, SOLR-12243.patch, SOLR-12243.patch, 
> SOLR-12243.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> synonyms.txt:
> allergic, hypersensitive
> aspirin, acetylsalicylic acid
> dog, canine, canis familiris, k 9
> rat, rattus
> request handler:
> 
>  
> 
>  edismax
>   0.4
>  title^100
>  title~20^5000
>  title~11
>  title~22^1000
>  text
>  
>  3-1 6-3 930%
>  *:*
>  25
> 
>  
> Phrase queries (pf, pf2, pf3) containing "dog" or "aspirin"  against the 
> above list will not be generated.
> "allergic reaction dog" will generate pf2: "allergic reaction", but not 
> pf:"allergic reaction dog", pf2: "reaction dog", or pf3: "allergic reaction 
> dog"
> "aspirin dose in rats" will generate pf3: "dose ? rats" but not pf2: "aspirin 
> dose" or pf3:"aspirin dose ?"
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12309) CloudSolrClient.Builder constructors are not well documented

2018-05-07 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-12309:
-

I can understand the desire to not have lots of constructors.  We're using the 
fluent paradigm, so the most straighforward option is only one constructor -- 
the one with no arguments.  Complexity can then happen in the fluent methods, 
making confusion a lot less likely.  We could have signatures like these, where 
using one of them is required before build() will work:

 * withZkHosts(List zkHosts)
 * withZkHosts(List zkHosts, String chroot)
 * withZkConnectString(String connectString)
 * withUrls(List urls)


> CloudSolrClient.Builder constructors are not well documented
> 
>
> Key: SOLR-12309
> URL: https://issues.apache.org/jira/browse/SOLR-12309
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 7.3
>Reporter: Shawn Heisey
>Priority: Minor
>
> I was having a lot of trouble figuring out how to create a CloudSolrClient 
> object without using deprecated code.
> The no-arg constructor on the Builder object is deprecated, and the two 
> remaining methods have similar signatures to each other.  It is not at all 
> obvious how to successfully call the one that uses ZooKeeper to connect.  The 
> javadoc is silent on the issue.  I did finally figure it out with a lot of 
> googling, and I would like to save others the hassle.
> I believe that this is what the javadoc for the third ctor should say:
> 
> Provide a series of ZooKeeper hosts which will be used when configuring 
> CloudSolrClient instances.  Optionally, include a chroot to be used when 
> accessing the ZooKeeper database.
> Here are a couple of examples.  The first one has no chroot, the second one 
> does:
> new CloudSolrClient.Builder(zkHosts, Optional.empty())
> new CloudSolrClient.Builder(zkHosts, Optional.of("/solr"))
> 
> The javadoc for the URL-based method should probably say something to 
> indicate that it is easy to confuse with the ZK-based method.
> I have not yet looked at the current reference guide to see if that has any 
> clarification.
> Is it a good idea to completely eliminate the ability to create a cloud 
> client using a single string that matches the zkHost value used when starting 
> Solr in cloud mode?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8273) Add a ConditionalTokenFilter

2018-05-07 Thread Alan Woodward (JIRA)

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

Alan Woodward commented on LUCENE-8273:
---

Patch, up to date with master and passing all tests and precommit.  I think 
this is ready?

> Add a ConditionalTokenFilter
> 
>
> Key: LUCENE-8273
> URL: https://issues.apache.org/jira/browse/LUCENE-8273
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, 
> LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch
>
>
> Spinoff of LUCENE-8265.  It would be useful to be able to wrap a TokenFilter 
> in such a way that it could optionally be bypassed based on the current state 
> of the TokenStream.  This could be used to, for example, only apply 
> WordDelimiterFilter to terms that contain hyphens.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (LUCENE-8273) Add a ConditionalTokenFilter

2018-05-07 Thread Alan Woodward (JIRA)

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

Alan Woodward updated LUCENE-8273:
--
Attachment: LUCENE-8273.patch

> Add a ConditionalTokenFilter
> 
>
> Key: LUCENE-8273
> URL: https://issues.apache.org/jira/browse/LUCENE-8273
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, 
> LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch
>
>
> Spinoff of LUCENE-8265.  It would be useful to be able to wrap a TokenFilter 
> in such a way that it could optionally be bypassed based on the current state 
> of the TokenStream.  This could be used to, for example, only apply 
> WordDelimiterFilter to terms that contain hyphens.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_162) - Build # 1863 - Unstable!

2018-05-07 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1863/
Java: 32bit/jdk1.8.0_162 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.search.TestRealTimeGet.testStressGetRealtime

Error Message:
Captured an uncaught exception in thread: Thread[id=6, name=WRITER8, 
state=RUNNABLE, group=TGRP-TestRealTimeGet]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=6, name=WRITER8, state=RUNNABLE, 
group=TGRP-TestRealTimeGet]
at 
__randomizedtesting.SeedInfo.seed([DA5670AD607B5B92:40587ACF46083830]:0)
Caused by: java.lang.RuntimeException: org.apache.solr.common.SolrException: 
Exception writing document id 15 to the index; possible analysis error.
at __randomizedtesting.SeedInfo.seed([DA5670AD607B5B92]:0)
at 
org.apache.solr.search.TestRealTimeGet$1.run(TestRealTimeGet.java:706)
Caused by: org.apache.solr.common.SolrException: Exception writing document id 
15 to the index; possible analysis error.
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:246)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:950)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1163)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:633)
at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
at 
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleAdds(JsonLoader.java:501)
at 
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:145)
at 
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:121)
at org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:84)
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2510)
at 
org.apache.solr.servlet.DirectSolrConnection.request(DirectSolrConnection.java:125)
at org.apache.solr.SolrTestCaseJ4.updateJ(SolrTestCaseJ4.java:1286)
at 
org.apache.solr.SolrTestCaseJ4.addAndGetVersion(SolrTestCaseJ4.java:1451)
at 
org.apache.solr.search.TestRealTimeGet$1.run(TestRealTimeGet.java:675)
Caused by: java.lang.NullPointerException
at 
org.apache.solr.update.UpdateLog.getCurrentLogSizeFromStream(UpdateLog.java:299)
at 
org.apache.solr.update.DirectUpdateHandler2.getCurrentTLogSize(DirectUpdateHandler2.java:1007)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:291)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:234)
... 18 more




Build Log:
[...truncated 13766 lines...]
   [junit4] Suite: org.apache.solr.search.TestRealTimeGet
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J0/temp/solr.search.TestRealTimeGet_DA5670AD607B5B92-001/init-core-data-001
   [junit4]   2> 1131492 WARN  
(SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=18 numCloses=18
   [junit4]   2> 1131492 INFO  
(SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=true
   [junit4]   2> 1131493 INFO  
(SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 1131493 INFO  
(SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> 1131493 INFO  
(SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] 
o.a.s.SolrTestCaseJ4 updateLog impl=solr.CdcrUpdateLog
   [junit4]   2> 1131494 INFO  
(SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] 
o.a.s.SolrTestCaseJ4 initCore
   [junit4]   2> 1131494 INFO  
(SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] 
o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths: 

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.4) - Build # 580 - Still Unstable!

2018-05-07 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/580/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseParallelGC

26 tests failed.
FAILED:  
org.apache.solr.handler.component.DistributedSpellCheckComponentTest.test

Error Message:
Error from server at https://127.0.0.1:61294//collection1: Directory 
(MMapDirectory@C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedSpellCheckComponentTest_5FBD132F0CB9CD72-001\tempDir-001\control\cores\collection1\data\spellchecker1
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@20774dbd) still has 
pending deleted files; cannot initialize IndexWriter

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:61294//collection1: Directory 
(MMapDirectory@C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedSpellCheckComponentTest_5FBD132F0CB9CD72-001\tempDir-001\control\cores\collection1\data\spellchecker1
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@20774dbd) still has 
pending deleted files; cannot initialize IndexWriter
at 
__randomizedtesting.SeedInfo.seed([5FBD132F0CB9CD72:D7E92CF5A245A08A]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.handler.component.DistributedSpellCheckComponentTest.q(DistributedSpellCheckComponentTest.java:67)
at 
org.apache.solr.handler.component.DistributedSpellCheckComponentTest.test(DistributedSpellCheckComponentTest.java:146)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1019)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[jira] [Commented] (SOLR-12309) CloudSolrClient.Builder constructors are not well documented

2018-05-07 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-12309:
-

I'm not saying that the use of Optional was bad.  Just that I couldn't figure 
it out how to use it by looking at the Builder javadoc.  I had to go searching 
for docs on Optional -- it was a object type I had never encountered before.  I 
suspect that this will be relatively common.

A java developer gets to know the more basic objects really quickly and they 
become second nature.  Things like Optional are not so common.  Of course we 
can't provide documentation for EVERY native object we use, but when we use 
something outside what developers use every day, we ought to provide some 
simple examples.

At first I just tried a List with the individual zkHost values in it, 
which naturally failed, because it tried to interpret those strings as URLs.  I 
hadn't even quite noticed that the URL-based constructor was there when I did 
this.  I was using my IDE's language-specific capabilities to find the 
constructor, not reading the javadocs directly.  When I did a closer 
examination of the javadoc after that trial didn't work, I saw my mistake, but 
still didn't know how to actually create an Optional object to use the correct 
constructor.

I think I did try "null" for the Optional argument.  If I did, I don't remember 
what the error for that was.  I can see what it does.

The Optional could have been replaced with a simple String value to 
differentiate it from the URL-based constructor.  Most java developers already 
know how to deal with String.

I'm curious why the no-arg constructor and the fluent methods for providing the 
ZK definition were deprecated.  The Fluent paradigm that the builders use is 
pretty straightforward and still present, so that still seems like a relevant 
way to use the builder.


> CloudSolrClient.Builder constructors are not well documented
> 
>
> Key: SOLR-12309
> URL: https://issues.apache.org/jira/browse/SOLR-12309
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 7.3
>Reporter: Shawn Heisey
>Priority: Minor
>
> I was having a lot of trouble figuring out how to create a CloudSolrClient 
> object without using deprecated code.
> The no-arg constructor on the Builder object is deprecated, and the two 
> remaining methods have similar signatures to each other.  It is not at all 
> obvious how to successfully call the one that uses ZooKeeper to connect.  The 
> javadoc is silent on the issue.  I did finally figure it out with a lot of 
> googling, and I would like to save others the hassle.
> I believe that this is what the javadoc for the third ctor should say:
> 
> Provide a series of ZooKeeper hosts which will be used when configuring 
> CloudSolrClient instances.  Optionally, include a chroot to be used when 
> accessing the ZooKeeper database.
> Here are a couple of examples.  The first one has no chroot, the second one 
> does:
> new CloudSolrClient.Builder(zkHosts, Optional.empty())
> new CloudSolrClient.Builder(zkHosts, Optional.of("/solr"))
> 
> The javadoc for the URL-based method should probably say something to 
> indicate that it is easy to confuse with the ZK-based method.
> I have not yet looked at the current reference guide to see if that has any 
> clarification.
> Is it a good idea to completely eliminate the ability to create a cloud 
> client using a single string that matches the zkHost value used when starting 
> Solr in cloud mode?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax

2018-05-07 Thread m-khl
Github user m-khl commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/371#discussion_r186447413
  
--- Diff: 
solr/core/src/test/org/apache/solr/search/json/TestJsonRequest.java ---
@@ -401,4 +396,180 @@ public static void doJsonRequest(Client client, 
boolean isDistrib) throws Except
 
   }
 
+  public static void doJsonRequestWithTag(Client client) throws Exception {
--- End diff --

I haven't seen the test for tagging just string like 
``` "filter": ["title:solr"]``` -> ``` "filter": 
[{"#drag":"title:solr"}]``` 


---

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



[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax

2018-05-07 Thread m-khl
Github user m-khl commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/371#discussion_r186446692
  
--- Diff: 
solr/core/src/java/org/apache/solr/request/json/JsonQueryConverter.java ---
@@ -69,6 +69,13 @@ private void buildLocalParams(StringBuilder builder, 
Object val, boolean isQPars
 "Error when parsing json query, expect only one query parser 
here, but found : "+map.keySet());
   }
   String qtype = map.keySet().iterator().next();
+  String qTypeTrimmed = qtype.trim();
+  String tagName = null;
+  if (qTypeTrimmed.startsWith("#")) {
--- End diff --

and what if not? Do we have a test which verify that violating this syntax 
triggers an exception?


---

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



[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax

2018-05-07 Thread m-khl
Github user m-khl commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/371#discussion_r186446157
  
--- Diff: 
solr/core/src/java/org/apache/solr/request/json/JsonQueryConverter.java ---
@@ -69,6 +69,13 @@ private void buildLocalParams(StringBuilder builder, 
Object val, boolean isQPars
 "Error when parsing json query, expect only one query parser 
here, but found : "+map.keySet());
   }
   String qtype = map.keySet().iterator().next();
+  String qTypeTrimmed = qtype.trim();
--- End diff --

Not sure why to trim. Makes no sense from my pow.  


---

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



[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax

2018-05-07 Thread m-khl
Github user m-khl commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/371#discussion_r186445658
  
--- Diff: 
solr/core/src/test/org/apache/solr/search/json/TestJsonRequest.java ---
@@ -25,20 +25,20 @@
 import org.junit.BeforeClass;
 import org.junit.Test;
 

-@LuceneTestCase.SuppressCodecs({"Lucene3x","Lucene40","Lucene41","Lucene42","Lucene45","Appending"})
+@LuceneTestCase.SuppressCodecs({"Lucene3x", "Lucene40", "Lucene41", 
"Lucene42", "Lucene45", "Appending"})
--- End diff --

Please don't format the code.  


---

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



[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax

2018-05-07 Thread m-khl
Github user m-khl commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/371#discussion_r186445542
  
--- Diff: 
solr/core/src/java/org/apache/solr/request/json/JsonQueryConverter.java ---
@@ -77,7 +84,10 @@ private void buildLocalParams(StringBuilder builder, 
Object val, boolean isQPars
 
   if (useSubBuilder) subBuilder = new StringBuilder();
 
-  subBuilder = subBuilder.append("{!").append(qtype).append(' ');;
+  if (tagName != null) {
+subBuilder.append("{!tag=").append(tagName).append("}");
--- End diff --

I believe it should be quoted to avoid problems with spaces inside of tags. 
Also, would you mind to embed tag in the same ```{! }``` qparser, rather 
than wrap. I'm afraid of some edgecases.  


---

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



[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax

2018-05-07 Thread m-khl
Github user m-khl commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/371#discussion_r186444765
  
--- Diff: 
solr/core/src/java/org/apache/solr/request/json/JsonQueryConverter.java ---
@@ -69,6 +69,13 @@ private void buildLocalParams(StringBuilder builder, 
Object val, boolean isQPars
 "Error when parsing json query, expect only one query parser 
here, but found : "+map.keySet());
   }
   String qtype = map.keySet().iterator().next();
+  String qTypeTrimmed = qtype.trim();
+  String tagName = null;
+  if (qTypeTrimmed.startsWith("#")) {
+tagName = qTypeTrimmed.substring(1);
--- End diff --

I suppose it makes more sense to keep hash in tag just to make it more 
noticeable and explicit. 


---

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



[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 215 - Still unstable

2018-05-07 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/215/

1 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.SearchRateTriggerTest.testTrigger

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([2BF31B11BE1CE9D:61740733822EBDB0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.autoscaling.SearchRateTriggerTest.testTrigger(SearchRateTriggerTest.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 15457 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.SearchRateTriggerTest
   [junit4]   2> 8438141 INFO  

[jira] [Commented] (LUCENE-8298) Allow DocValues updates to reset a value

2018-05-07 Thread Simon Willnauer (JIRA)

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

Simon Willnauer commented on LUCENE-8298:
-

I attached a patch for discussion. I need to do some cleanups, more tests and 
clarify javadocs but it shows the idea

> Allow DocValues updates to reset a value
> 
>
> Key: LUCENE-8298
> URL: https://issues.apache.org/jira/browse/LUCENE-8298
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8298.patch
>
>
>  Today once a document has a value in a certain DV field this values
> can only be changed but not removed. While resetting / removing a value
> from a field is certainly a corner case it can be used to undelete a
> soft-deleted document unless it's merged away.
> This allows to rollback changes without rolling back to another 
> commitpoint
> or trashing all uncommitted changes. In certain cenarios it can be used to
> "repair" history of documents in distributed systems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (LUCENE-8298) Allow DocValues updates to reset a value

2018-05-07 Thread Simon Willnauer (JIRA)

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

Simon Willnauer updated LUCENE-8298:

Attachment: LUCENE-8298.patch

> Allow DocValues updates to reset a value
> 
>
> Key: LUCENE-8298
> URL: https://issues.apache.org/jira/browse/LUCENE-8298
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8298.patch
>
>
>  Today once a document has a value in a certain DV field this values
> can only be changed but not removed. While resetting / removing a value
> from a field is certainly a corner case it can be used to undelete a
> soft-deleted document unless it's merged away.
> This allows to rollback changes without rolling back to another 
> commitpoint
> or trashing all uncommitted changes. In certain cenarios it can be used to
> "repair" history of documents in distributed systems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (LUCENE-8298) Allow DocValues updates to reset a value

2018-05-07 Thread Simon Willnauer (JIRA)
Simon Willnauer created LUCENE-8298:
---

 Summary: Allow DocValues updates to reset a value
 Key: LUCENE-8298
 URL: https://issues.apache.org/jira/browse/LUCENE-8298
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 7.4, master (8.0)
Reporter: Simon Willnauer
 Fix For: 7.4, master (8.0)


 Today once a document has a value in a certain DV field this values
can only be changed but not removed. While resetting / removing a value
from a field is certainly a corner case it can be used to undelete a
soft-deleted document unless it's merged away.
This allows to rollback changes without rolling back to another commitpoint
or trashing all uncommitted changes. In certain cenarios it can be used to
"repair" history of documents in distributed systems.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-12324) handling numeric fields in uniqueBlock(id) aggregation for JSON Facet

2018-05-07 Thread Mikhail Khludnev (JIRA)

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

Mikhail Khludnev updated SOLR-12324:

Summary: handling numeric fields in uniqueBlock(id) aggregation for JSON 
Facet  (was: handling numeric fields in uniqueBlock(id))

> handling numeric fields in uniqueBlock(id) aggregation for JSON Facet
> -
>
> Key: SOLR-12324
> URL: https://issues.apache.org/jira/browse/SOLR-12324
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 7.4
>Reporter: Mikhail Khludnev
>Priority: Minor
>
> Now it trows exception. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-12324) handling numeric fields in uniqueBlock(id)

2018-05-07 Thread Mikhail Khludnev (JIRA)

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

Mikhail Khludnev updated SOLR-12324:

Component/s: Facet Module

> handling numeric fields in uniqueBlock(id)
> --
>
> Key: SOLR-12324
> URL: https://issues.apache.org/jira/browse/SOLR-12324
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 7.4
>Reporter: Mikhail Khludnev
>Priority: Minor
>
> Now it trows exception. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



  1   2   >