[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_72) - Build # 16213 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16213/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=8444, 
name=testExecutor-4229-thread-12, state=RUNNABLE, 
group=TGRP-UnloadDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=8444, name=testExecutor-4229-thread-12, 
state=RUNNABLE, group=TGRP-UnloadDistributedZkTest]
at 
__randomizedtesting.SeedInfo.seed([2CDCCF1487833DA1:A488F0CE297F5059]:0)
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:35019
at __randomizedtesting.SeedInfo.seed([2CDCCF1487833DA1]:0)
at 
org.apache.solr.cloud.BasicDistributedZkTest.lambda$createCores$0(BasicDistributedZkTest.java:583)
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)
Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occured 
while waiting response from server at: http://127.0.0.1:35019
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:588)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.BasicDistributedZkTest.lambda$createCores$0(BasicDistributedZkTest.java:581)
... 4 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
at 
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:487)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:482)
... 8 more




Build Log:
[...truncated 11453 lines...]
   [junit4] Suite: org.apache.solr.cloud.UnloadDistributedZkTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.UnloadDistributedZkTest_2CDCCF1487833DA1-001/init-core-data-001
   [junit4]   2> 948389 INFO  
(SUITE-UnloadDistributedZkTest-seed#[2CDCCF1487833DA1]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 948391 INFO  
(TEST-UnloadDistributedZkTest.test-seed#[2CDCCF1487833DA1]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 948394 INFO  (Thread-2817) [] o.a.s.c.ZkTestServer client 

[jira] [Updated] (LUCENE-7105) squeeze a little more perf out of LatLonPoint.newDistanceQuery

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7105:

Attachment: LUCENE-7105.patch

Here is a patch. Its a 10.5% QPS improvement on Mike's London benchmark. I also 
see similar improvements doing queries around my house in geonames.

Changes:
* visit(int, byte[]) does range checks on individual points. This is cheap, 
removes "false positives" to speed up two-phase intersection, and BKD has read 
the data already anyway.
* range checks in visit(int, byte[]) and compare(min, max) just work on the 
binary form.
* 2nd phase iterator uses the two-stage haversin from the distance sort when 
possible to reject candidates faster.


> squeeze a little more perf out of LatLonPoint.newDistanceQuery
> --
>
> Key: LUCENE-7105
> URL: https://issues.apache.org/jira/browse/LUCENE-7105
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7105.patch
>
>
> This query can make use of some of the same optimizations we applied to the 
> distance sort.



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

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

[jira] [Created] (LUCENE-7105) squeeze a little more perf out of LatLonPoint.newDistanceQuery

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7105:
---

 Summary: squeeze a little more perf out of 
LatLonPoint.newDistanceQuery
 Key: LUCENE-7105
 URL: https://issues.apache.org/jira/browse/LUCENE-7105
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir


This query can make use of some of the same optimizations we applied to the 
distance sort.



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

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

[jira] [Commented] (SOLR-445) Update Handlers abort with bad documents

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-445:
---

The usage you explained looks nice Hoss!  This will be very useful.  I assume 
there are SolrJ hooks here.  I'll leave the internal review to others.

> Update Handlers abort with bad documents
> 
>
> Key: SOLR-445
> URL: https://issues.apache.org/jira/browse/SOLR-445
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 1.3
>Reporter: Will Johnson
>Assignee: Hoss Man
> Attachments: SOLR-445-3_x.patch, SOLR-445-alternative.patch, 
> SOLR-445-alternative.patch, SOLR-445-alternative.patch, 
> SOLR-445-alternative.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, 
> SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, 
> SOLR-445.patch, SOLR-445.patch, SOLR-445_3x.patch, solr-445.xml
>
>
> Has anyone run into the problem of handling bad documents / failures mid 
> batch.  Ie:
> 
>   
> 1
>   
>   
> 2
> I_AM_A_BAD_DATE
>   
>   
> 3
>   
> 
> Right now solr adds the first doc and then aborts.  It would seem like it 
> should either fail the entire batch or log a message/return a code and then 
> continue on to add doc 3.  Option 1 would seem to be much harder to 
> accomplish and possibly require more memory while Option 2 would require more 
> information to come back from the API.  I'm about to dig into this but I 
> thought I'd ask to see if anyone had any suggestions, thoughts or comments.   
>  



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

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_72) - Build # 16212 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16212/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseSerialGC

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

Error Message:
[/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_E138FEBF60221299-001/solr-instance-010/./collection1/data/index.20160314211512901,
 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_E138FEBF60221299-001/solr-instance-010/./collection1/data,
 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_E138FEBF60221299-001/solr-instance-010/./collection1/data/index.20160314211512771]
 expected:<2> but was:<3>

Stack Trace:
java.lang.AssertionError: 
[/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_E138FEBF60221299-001/solr-instance-010/./collection1/data/index.20160314211512901,
 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_E138FEBF60221299-001/solr-instance-010/./collection1/data,
 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_E138FEBF60221299-001/solr-instance-010/./collection1/data/index.20160314211512771]
 expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([E138FEBF60221299:164B10E7A6CABD7F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:818)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1248)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java: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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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 

[jira] [Commented] (SOLR-8850) SolrCLI.java Fails if Basic Authentication is Set

[Esther Quansah (JIRA)]

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

Esther Quansah commented on SOLR-8850:
--

As a workaround, authentication was hardcoded into the start script and 
connection to Solr was made. 

> SolrCLI.java Fails if Basic Authentication is Set
> -
>
> Key: SOLR-8850
> URL: https://issues.apache.org/jira/browse/SOLR-8850
> Project: Solr
>  Issue Type: Bug
>  Components: Authentication, SolrJ
>Affects Versions: 5.4.1
>Reporter: Esther Quansah
>
> When you put solr in BasicAuthentication Mode, the Solr start script uses the 
> SolrCLI.java file to make an HTTP connection to Solr to see if it is up, so 
> if basic authentication is set then the SolrCLI.java will fail. This appears 
> as a timeout at the command prompt, even though Solr is up. 



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

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

[jira] [Created] (SOLR-8850) SolrCLI.java Fails if Basic Authentication is Set

[Esther Quansah (JIRA)]

Esther Quansah created SOLR-8850:


 Summary: SolrCLI.java Fails if Basic Authentication is Set
 Key: SOLR-8850
 URL: https://issues.apache.org/jira/browse/SOLR-8850
 Project: Solr
  Issue Type: Bug
  Components: Authentication, SolrJ
Affects Versions: 5.4.1
Reporter: Esther Quansah


When you put solr in BasicAuthentication Mode, the Solr start script uses the 
SolrCLI.java file to make an HTTP connection to Solr to see if it is up, so if 
basic authentication is set then the SolrCLI.java will fail. This appears as a 
timeout at the command prompt, even though Solr is up. 




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

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

[jira] [Commented] (SOLR-8213) SolrJ JDBC support basic authentication

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8213:
--

I suspect it won't be get passed through. But if the we do basic auth on the 
SQLHandler perhaps that's enough. 

> SolrJ JDBC support basic authentication
> ---
>
> Key: SOLR-8213
> URL: https://issues.apache.org/jira/browse/SOLR-8213
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Kevin Risden
> Attachments: SOLR-8213.patch, add_401_httpstatus_code_check.patch, 
> add_basic_authentication_authorization_streaming.patch
>
>
> SolrJ JDBC doesn't support authentication where as Solr supports Basic and 
> Kerberos authentication currently. 



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

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

[jira] [Comment Edited] (SOLR-8213) SolrJ JDBC support basic authentication

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8213 at 3/15/16 1:07 AM:
---

This same approach should be used for StreamTest and StreamExpressionTest as 
well. I only focused on JDBC so far.


was (Author: risdenk):
This same approach should be used for StreamTest and StreamExpressionTest as 
well. I only focused on JDBC so far.

> SolrJ JDBC support basic authentication
> ---
>
> Key: SOLR-8213
> URL: https://issues.apache.org/jira/browse/SOLR-8213
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Kevin Risden
> Attachments: SOLR-8213.patch, add_401_httpstatus_code_check.patch, 
> add_basic_authentication_authorization_streaming.patch
>
>
> SolrJ JDBC doesn't support authentication where as Solr supports Basic and 
> Kerberos authentication currently. 



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

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

[jira] [Updated] (SOLR-8849) ChaosMonkey should cuase chaos in a more reproducible manner

[Hoss Man (JIRA)]

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

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

proposed patch.

in addition to cleaning up the random usage, this also refactors the 
non-loop/sleep portions of the monkeyThread into a new {{public void 
causeSomeChaos()}} method.

this way, it's possible to write a (single threaded) test with 100% 
reproducible chaos w/o needing to write your own random decision making about 
what chaos methods to call.

> ChaosMonkey should cuase chaos in a more reproducible manner
> 
>
> Key: SOLR-8849
> URL: https://issues.apache.org/jira/browse/SOLR-8849
> Project: Solr
>  Issue Type: Test
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-8849.patch
>
>
> Looking into the ChaosMonkey code a bit, and it seems like this class -- 
> particularly the way {{monkeyThread}} is defined -- uses randomness in a way 
> that makes it extremely unlikely that it will ever create reproducible 
> failures.
> Obviously in any test where there are multiple concurrent threads, timing 
> issues might prevent test reproducibility -- but in this case, even the 
> sequence of "chaos" actions the monkeyThread takes won't be reproducible if 
> anyother concurrent test thread accesses {{LuceneTestCase.random()}} ...
> {code}
>   public void run() {
> while (!stop) {
>   try {
> 
> Random random = LuceneTestCase.random();
> // ... lots of stuff using random, or calling methods that use 
> LuceneTestCase.random() directly
> {code}
> It seems like it would be a lot better if ChaosMonkey's constructor created 
> it's own private {{Random chaosRand}} using {{LuceneTestCase.random()}} as a 
> seed, and then used {{chaosRand}} to make all random choices in it's methods.
> That way at least the sequence of chaotic operations made by ChaosMonkey 
> would be consistent for a given test seed, even if the exact 
> timing/interleaving of those operations relative to other operations by other 
> threads couldn't be garunteed.



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

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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_72) - Build # 46 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/46/
Java: 32bit/jdk1.8.0_72 -server -XX:+UseG1GC

No tests ran.

Build Log:
[...truncated 1959 lines...]
ERROR: Connection was broken: java.io.IOException: Unexpected termination of 
the channel
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
Caused by: java.io.EOFException
at 
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2325)
at 
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2794)
at 
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:801)
at java.io.ObjectInputStream.(ObjectInputStream.java:299)
at 
hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:48)
at 
hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)

Build step 'Invoke Ant' marked build as failure
ERROR: Step ‘Archive the artifacts’ failed: no workspace for 
Lucene-Solr-6.x-Windows #46
ERROR: Step ‘Scan for compiler warnings’ failed: no workspace for 
Lucene-Solr-6.x-Windows #46
ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for 
Lucene-Solr-6.x-Windows #46
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (SOLR-8849) ChaosMonkey should cuase chaos in a more reproducible manner

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8849:
---

Makes sense to me. I don't see a problem with the change. 

> ChaosMonkey should cuase chaos in a more reproducible manner
> 
>
> Key: SOLR-8849
> URL: https://issues.apache.org/jira/browse/SOLR-8849
> Project: Solr
>  Issue Type: Test
>Reporter: Hoss Man
>Assignee: Hoss Man
>
> Looking into the ChaosMonkey code a bit, and it seems like this class -- 
> particularly the way {{monkeyThread}} is defined -- uses randomness in a way 
> that makes it extremely unlikely that it will ever create reproducible 
> failures.
> Obviously in any test where there are multiple concurrent threads, timing 
> issues might prevent test reproducibility -- but in this case, even the 
> sequence of "chaos" actions the monkeyThread takes won't be reproducible if 
> anyother concurrent test thread accesses {{LuceneTestCase.random()}} ...
> {code}
>   public void run() {
> while (!stop) {
>   try {
> 
> Random random = LuceneTestCase.random();
> // ... lots of stuff using random, or calling methods that use 
> LuceneTestCase.random() directly
> {code}
> It seems like it would be a lot better if ChaosMonkey's constructor created 
> it's own private {{Random chaosRand}} using {{LuceneTestCase.random()}} as a 
> seed, and then used {{chaosRand}} to make all random choices in it's methods.
> That way at least the sequence of chaotic operations made by ChaosMonkey 
> would be consistent for a given test seed, even if the exact 
> timing/interleaving of those operations relative to other operations by other 
> threads couldn't be garunteed.



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

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

[jira] [Assigned] (SOLR-8849) ChaosMonkey should cuase chaos in a more reproducible manner

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-8849:
--

Assignee: Hoss Man

i'm happy to work on this, but before i spend any time on it i'd appreciate if 
[~markrmil...@gmail.com] or someone else equally familiar with ChaosMonkey 
could sanity check my assessment (i can't imagine the current behavior is 
intentionally desired, but it also seems like it would have been totally 
obvious when initially written this way, so i'm not sure why it wasn't caught 
then)

> ChaosMonkey should cuase chaos in a more reproducible manner
> 
>
> Key: SOLR-8849
> URL: https://issues.apache.org/jira/browse/SOLR-8849
> Project: Solr
>  Issue Type: Test
>Reporter: Hoss Man
>Assignee: Hoss Man
>
> Looking into the ChaosMonkey code a bit, and it seems like this class -- 
> particularly the way {{monkeyThread}} is defined -- uses randomness in a way 
> that makes it extremely unlikely that it will ever create reproducible 
> failures.
> Obviously in any test where there are multiple concurrent threads, timing 
> issues might prevent test reproducibility -- but in this case, even the 
> sequence of "chaos" actions the monkeyThread takes won't be reproducible if 
> anyother concurrent test thread accesses {{LuceneTestCase.random()}} ...
> {code}
>   public void run() {
> while (!stop) {
>   try {
> 
> Random random = LuceneTestCase.random();
> // ... lots of stuff using random, or calling methods that use 
> LuceneTestCase.random() directly
> {code}
> It seems like it would be a lot better if ChaosMonkey's constructor created 
> it's own private {{Random chaosRand}} using {{LuceneTestCase.random()}} as a 
> seed, and then used {{chaosRand}} to make all random choices in it's methods.
> That way at least the sequence of chaotic operations made by ChaosMonkey 
> would be consistent for a given test seed, even if the exact 
> timing/interleaving of those operations relative to other operations by other 
> threads couldn't be garunteed.



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

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

[jira] [Created] (SOLR-8849) ChaosMonkey should cuase chaos in a more reproducible manner

[Hoss Man (JIRA)]

Hoss Man created SOLR-8849:
--

 Summary: ChaosMonkey should cuase chaos in a more reproducible 
manner
 Key: SOLR-8849
 URL: https://issues.apache.org/jira/browse/SOLR-8849
 Project: Solr
  Issue Type: Test
Reporter: Hoss Man


Looking into the ChaosMonkey code a bit, and it seems like this class -- 
particularly the way {{monkeyThread}} is defined -- uses randomness in a way 
that makes it extremely unlikely that it will ever create reproducible failures.

Obviously in any test where there are multiple concurrent threads, timing 
issues might prevent test reproducibility -- but in this case, even the 
sequence of "chaos" actions the monkeyThread takes won't be reproducible if 
anyother concurrent test thread accesses {{LuceneTestCase.random()}} ...

{code}
  public void run() {
while (!stop) {
  try {

Random random = LuceneTestCase.random();
// ... lots of stuff using random, or calling methods that use 
LuceneTestCase.random() directly
{code}

It seems like it would be a lot better if ChaosMonkey's constructor created 
it's own private {{Random chaosRand}} using {{LuceneTestCase.random()}} as a 
seed, and then used {{chaosRand}} to make all random choices in it's methods.

That way at least the sequence of chaotic operations made by ChaosMonkey would 
be consistent for a given test seed, even if the exact timing/interleaving of 
those operations relative to other operations by other threads couldn't be 
garunteed.



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

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

[jira] [Commented] (SOLR-445) Update Handlers abort with bad documents

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-445:
---

Thanks Hoss! I'll take a look at this tonight or tomorrow morning.

> Update Handlers abort with bad documents
> 
>
> Key: SOLR-445
> URL: https://issues.apache.org/jira/browse/SOLR-445
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 1.3
>Reporter: Will Johnson
>Assignee: Hoss Man
> Attachments: SOLR-445-3_x.patch, SOLR-445-alternative.patch, 
> SOLR-445-alternative.patch, SOLR-445-alternative.patch, 
> SOLR-445-alternative.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, 
> SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, 
> SOLR-445.patch, SOLR-445.patch, SOLR-445_3x.patch, solr-445.xml
>
>
> Has anyone run into the problem of handling bad documents / failures mid 
> batch.  Ie:
> 
>   
> 1
>   
>   
> 2
> I_AM_A_BAD_DATE
>   
>   
> 3
>   
> 
> Right now solr adds the first doc and then aborts.  It would seem like it 
> should either fail the entire batch or log a message/return a code and then 
> continue on to add doc 3.  Option 1 would seem to be much harder to 
> accomplish and possibly require more memory while Option 2 would require more 
> information to come back from the API.  I'm about to dig into this but I 
> thought I'd ask to see if anyone had any suggestions, thoughts or comments.   
>  



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

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

[jira] [Commented] (SOLR-5944) Support updates of numeric DocValues

[Gopal Patwa (JIRA)]

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

Gopal Patwa commented on SOLR-5944:
---

Great! to see progress and near to completion this feature. can this be part of 
6.0 release?

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



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

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

[jira] [Resolved] (LUCENE-7104) remove "sort missing first" from LatLonPoint.newDistanceQuery

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-7104.
-
   Resolution: Fixed
Fix Version/s: 6.1
   master

> remove "sort missing first" from LatLonPoint.newDistanceQuery
> -
>
> Key: LUCENE-7104
> URL: https://issues.apache.org/jira/browse/LUCENE-7104
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: master, 6.1
>
> Attachments: LUCENE-7104.patch
>
>
> As [~mikemccand] mentioned on LUCENE-7102, we may not want to allow this.
> I removed it and then made all the cleanups i easily could based on that. 
> Ultimately I think the code is simpler and faster (~ 15%), so we should do it?



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

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

[jira] [Commented] (LUCENE-7104) remove "sort missing first" from LatLonPoint.newDistanceQuery

[ASF subversion and git services (JIRA)]

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

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

Commit bd87ca0c4d0922de446a9de1d6b86c0ab65ec994 in lucene-solr's branch 
refs/heads/branch_6x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bd87ca0 ]

LUCENE-7104: remove "sort missing first" from LatLonPoint.newDistanceSort and 
simplify/speedup code


> remove "sort missing first" from LatLonPoint.newDistanceQuery
> -
>
> Key: LUCENE-7104
> URL: https://issues.apache.org/jira/browse/LUCENE-7104
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7104.patch
>
>
> As [~mikemccand] mentioned on LUCENE-7102, we may not want to allow this.
> I removed it and then made all the cleanups i easily could based on that. 
> Ultimately I think the code is simpler and faster (~ 15%), so we should do it?



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

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

[jira] [Commented] (LUCENE-7104) remove "sort missing first" from LatLonPoint.newDistanceQuery

[ASF subversion and git services (JIRA)]

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

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

Commit 02bb6c01550771fb0d7a75d4b283c897024c923b in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=02bb6c0 ]

LUCENE-7104: remove "sort missing first" from LatLonPoint.newDistanceSort and 
simplify/speedup code


> remove "sort missing first" from LatLonPoint.newDistanceQuery
> -
>
> Key: LUCENE-7104
> URL: https://issues.apache.org/jira/browse/LUCENE-7104
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7104.patch
>
>
> As [~mikemccand] mentioned on LUCENE-7102, we may not want to allow this.
> I removed it and then made all the cleanups i easily could based on that. 
> Ultimately I think the code is simpler and faster (~ 15%), so we should do it?



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

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 56 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/56/

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

Error Message:
ObjectTracker found 4 object(s) that were not released!!! [SolrCore, 
MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 4 object(s) that were not 
released!!! [SolrCore, MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor]
at __randomizedtesting.SeedInfo.seed([880A3006DEC3D869]: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.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:238)
at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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:367)
at java.lang.Thread.run(Thread.java:745)


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

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

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


FAILED:  

[jira] [Commented] (SOLR-8213) SolrJ JDBC support basic authentication

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8213:


There needs to be some randomized testing of authentication/no authentication.

> SolrJ JDBC support basic authentication
> ---
>
> Key: SOLR-8213
> URL: https://issues.apache.org/jira/browse/SOLR-8213
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Kevin Risden
> Attachments: SOLR-8213.patch, add_401_httpstatus_code_check.patch, 
> add_basic_authentication_authorization_streaming.patch
>
>
> SolrJ JDBC doesn't support authentication where as Solr supports Basic and 
> Kerberos authentication currently. 



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

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

[jira] [Commented] (SOLR-8841) edismax: minimum match and compound words

[Christian Winkler (JIRA)]

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

Christian Winkler commented on SOLR-8841:
-

Maybe it's a bit different as this is not a tokenizer but a filter (like 
DictionaryCompoundWordTokenFilter).

Regards
Christian

> edismax: minimum match and compound words
> -
>
> Key: SOLR-8841
> URL: https://issues.apache.org/jira/browse/SOLR-8841
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.5, trunk
> Environment: all
>Reporter: Christian Winkler
>
> Hi,
> when searching for a single word which is split by a compound word splitter 
> (very common in German), minimum match is not handled correctly. It is always 
> set to 1 (only a single search term), but as the word is split into several 
> single parts, one matching part is enough
> This also happens if mm is set to 100%.
> Probably mm should be set after the split has been performed. Similar 
> problems might arise with synonymization at search time.
> Regards
> Christian 



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

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

[jira] [Commented] (LUCENE-7104) remove "sort missing first" from LatLonPoint.newDistanceQuery

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7104:


+1, this is a nice cleanup too!

> remove "sort missing first" from LatLonPoint.newDistanceQuery
> -
>
> Key: LUCENE-7104
> URL: https://issues.apache.org/jira/browse/LUCENE-7104
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7104.patch
>
>
> As [~mikemccand] mentioned on LUCENE-7102, we may not want to allow this.
> I removed it and then made all the cleanups i easily could based on that. 
> Ultimately I think the code is simpler and faster (~ 15%), so we should do it?



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

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

[jira] [Updated] (SOLR-8808) SolrJ deleteById causes missing content stream exception

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-8808:
--
Attachment: SOLR-8808.patch

Uploaded patch contains changes to SolrClient.java.  It also adds a simple test 
to a few SolrClient related test-files that verify the behavior.

One aspect of this change that I hadn't thought about when I first saw it is 
that {{deleteById}} has an UpdateResponse return value.  Since this patch 
changes deleteByid to not send a request when no IDs were given, it's not super 
clear what the best value to return here is.  The patch I uploaded just returns 
a blank value type created via the no-arg ctor.

This means that in practice, a SolrJ user could call deleteById() and get a 
return value just fine.  But if they go to pull out the request timestamp, or 
the headers later on, they could get bitten by an NPE.  So while it looks like 
this patch is an obvious improvement, it really might just kick the can down 
the road a bit and lead to errors later on.

That said, I still think it's an improvement, and this is the right thing to 
do.  Just wanted to call it out in case anyone has a suggestion for getting 
around that limitation.

> SolrJ deleteById causes missing content stream exception
> 
>
> Key: SOLR-8808
> URL: https://issues.apache.org/jira/browse/SOLR-8808
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 5.5
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8808.patch
>
>
> {code}
> client.deleteById(new ArrayList()); 
> {code}
> Causes
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://127.0.0.1:50083/collection1: Error from server at 
> http://127.0.0.1:50083/control_collection: missing content stream
> at 
> __randomizedtesting.SeedInfo.seed([6C4973F1A077B797:65D362791DA8A1AD]:0)
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:576)
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
> at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
> at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:482)
> at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
> {code}
> Although this is not a big issue, it had me puzzled for a while. A test 
> unrelated to one i was working on started sending empty deletes. Causing 
> above trace.
> Perhaps SolrJ should guard for empty input, just ignore and return.



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

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

[jira] [Commented] (SOLR-8841) edismax: minimum match and compound words

[Tom Burton-West (JIRA)]

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

Tom Burton-West commented on SOLR-8841:
---

This looks very similar to the bug that was fixed in Solr 4.1 for  SOLR-3589
https://issues.apache.org/jira/browse/SOLR-3589
I wonder if the fix somehow got lost in the move to Solr 5.5?  
Does the test labeled "SOLR-3589: Edismax parser does not honor mm parameter if 
analyzer splits a token"  in 
https://github.com/apache/lucene-solr/blob/branch_5_5/solr/core/src/test/org/apache/solr/search/TestExtendedDismaxParser.java
 run ok?

Tom




> edismax: minimum match and compound words
> -
>
> Key: SOLR-8841
> URL: https://issues.apache.org/jira/browse/SOLR-8841
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.5, trunk
> Environment: all
>Reporter: Christian Winkler
>
> Hi,
> when searching for a single word which is split by a compound word splitter 
> (very common in German), minimum match is not handled correctly. It is always 
> set to 1 (only a single search term), but as the word is split into several 
> single parts, one matching part is enough
> This also happens if mm is set to 100%.
> Probably mm should be set after the split has been performed. Similar 
> problems might arise with synonymization at search time.
> Regards
> Christian 



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3138/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
No live SolrServers available to handle this request

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request
at 
__randomizedtesting.SeedInfo.seed([93603B2676CA36EA:52A8E660D7ACE743]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:565)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
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.client.solrj.TestLBHttpSolrClient.testReliability(TestLBHttpSolrClient.java:221)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java: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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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:367)
at 

[jira] [Resolved] (LUCENE-7102) LatLonPoint newDistanceSort fails with "sort missing first"

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-7102.
-
   Resolution: Fixed
Fix Version/s: 6.1
   master

> LatLonPoint newDistanceSort fails with "sort missing first"
> ---
>
> Key: LUCENE-7102
> URL: https://issues.apache.org/jira/browse/LUCENE-7102
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: master, 6.1
>
> Attachments: LUCENE-7102.patch
>
>
> The distance sort comparator creates bounding boxes when the priority queue 
> is full, to speed up sorting.
> But with missing values (which we don't test), they can be e.g. -Inf/+Inf and 
> we do the wrong thing (e.g. try to make illegal infinite bounding boxes).



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

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

[jira] [Resolved] (LUCENE-7103) further optimize LatLonPoint.newDistanceSort

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-7103.
-
   Resolution: Fixed
Fix Version/s: 6.1
   master

> further optimize LatLonPoint.newDistanceSort
> 
>
> Key: LUCENE-7103
> URL: https://issues.apache.org/jira/browse/LUCENE-7103
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: master, 6.1
>
> Attachments: LUCENE-7103.patch
>
>
> This comparator creates bounding boxes to avoid calling haversin(), so its no 
> longer a hotspot for most use cases.
> But in the worst case, it could still get called many times. This could be 
> because the user had a massive top N value, or because the incoming data is 
> sorted or mostly sorted by decreasing distance, etc.
> We can optimize the worst case by not invoking a full haversin, just using 
> something that is rank-equivalent.



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

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

[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8297:
--

Potentially related at least. At a glance, the restrictions on this particular 
JIRA seem to be too narrow a use-case, SOLR-7341 seems much more general 
purpose.

> Allow join query over 2 sharded collections: enhance functionality and 
> exception handling
> -
>
> Key: SOLR-8297
> URL: https://issues.apache.org/jira/browse/SOLR-8297
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Paul Blanchaert
>
> Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail 
> Khludnev.
> A) exception handling:
> The exception "SolrCloud join: multiple shards not yet supported" thrown in 
> the function findLocalReplicaForFromIndex of JoinQParserPlugin is not 
> triggered correctly: In my use-case, I've a join on a facet.query and when my 
> results are only found in 1 shard and the facet.query with the join is 
> querying the last replica of the last slice, then the exception is not thrown.
> I believe it's better to verify the nr of slices when we want to verify the  
> "multiple shards not yet supported" exception (so exception is thrown when 
> zkController.getClusterState().getSlices(fromIndex).size()>1).
> B) functional enhancement:
> I would expect that there is no problem to perform a cross-core join over 
> sharded collections when the following conditions are met:
> 1) both collections are sharded with the same replicationFactor and numShards
> 2) router.field of the collections is set to the same "key-field" (collection 
> of "fromindex" has router.field = "from" field and collection joined to has 
> router.field = "to" field)
> The router.field setup ensures that documents with the same "key-field" are 
> routed to the same node. 
> So the combination based on the "key-field" should always be available within 
> the same node.
> From a user perspective, I believe these assumptions seem to be a "normal" 
> use-case in the cross-core join in SolrCloud.
> Hope this helps



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

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

[jira] [Updated] (LUCENE-7104) remove "sort missing first" from LatLonPoint.newDistanceQuery

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7104:

Attachment: LUCENE-7104.patch

patch

> remove "sort missing first" from LatLonPoint.newDistanceQuery
> -
>
> Key: LUCENE-7104
> URL: https://issues.apache.org/jira/browse/LUCENE-7104
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7104.patch
>
>
> As [~mikemccand] mentioned on LUCENE-7102, we may not want to allow this.
> I removed it and then made all the cleanups i easily could based on that. 
> Ultimately I think the code is simpler and faster (~ 15%), so we should do it?



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

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

[jira] [Created] (LUCENE-7104) remove "sort missing first" from LatLonPoint.newDistanceQuery

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7104:
---

 Summary: remove "sort missing first" from 
LatLonPoint.newDistanceQuery
 Key: LUCENE-7104
 URL: https://issues.apache.org/jira/browse/LUCENE-7104
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-7104.patch

As [~mikemccand] mentioned on LUCENE-7102, we may not want to allow this.

I removed it and then made all the cleanups i easily could based on that. 

Ultimately I think the code is simpler and faster (~ 15%), so we should do it?



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_72) - Build # 16210 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16210/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'CY val modified' for path 'response/params/y/c' 
full output: {   "responseHeader":{ "status":0, "QTime":0},   
"response":{ "znodeVersion":1, "params":{   "x":{ "a":"A 
val", "b":"B val", "":{"v":0}},   "y":{ "c":"CY 
val", "b":"BY val", "i":20, "d":[   "val 1",
   "val 2"], "":{"v":0}

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val modified' for 
path 'response/params/y/c' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":1,
"params":{
  "x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
  "y":{
"c":"CY val",
"b":"BY val",
"i":20,
"d":[
  "val 1",
  "val 2"],
"":{"v":0}
at 
__randomizedtesting.SeedInfo.seed([606AB123705BA29E:E83E8EF9DEA7CF66]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:458)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:200)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:67)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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 

[jira] [Commented] (LUCENE-7093) MemoryIndex does not support points

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen commented on LUCENE-7093:
---

bq. Also, I think the visit method only works in the 1D case ... for e.g. the 
2D case, I think it may be buggy because the byte[] values were sorted only by 
the first dimension?

I didn't realize that this was buggy in 2d case. I assumed that I was sorting 
the values correctly for any dimension, because LongPoint and friends pack 
multiple dimensions into a single BytesRef. Just curious, how would the sort 
then work?

bq. I feel like it's best to get a simple, correct, implementation in at first, 
and then worry about optimizing for the "many points in a single document" case 
later?

+1. I'll simplify the visitor method.

> MemoryIndex does not support points
> ---
>
> Key: LUCENE-7093
> URL: https://issues.apache.org/jira/browse/LUCENE-7093
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Martijn van Groningen
> Attachments: LUCENE-7093.patch, LUCENE-7093.patch
>
>
> I realized this glancing at LUCENE-7091.
> I think this should have points support or else people cannot move off of the 
> deprecated LegacyXXX encodings?



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

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

[jira] [Updated] (SOLR-8848) When a SolrJ alias watch is triggered, the new alias state should be logged

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-8848:
-
Attachment: SOLR-8848.patch

Trivial patch against trunk. Clusterstate.load(data) cannot return null so no 
need to check for null.

> When a SolrJ alias watch is triggered, the new alias state should be logged
> ---
>
> Key: SOLR-8848
> URL: https://issues.apache.org/jira/browse/SOLR-8848
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Trivial
> Attachments: SOLR-8848.patch
>
>
> Logging the current alias definition as well as the "Updating aliases..." 
> message would be helpful.



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

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

[jira] [Created] (SOLR-8848) When a SolrJ alias watch is triggered, the new alias state should be logged

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-8848:


 Summary: When a SolrJ alias watch is triggered, the new alias 
state should be logged
 Key: SOLR-8848
 URL: https://issues.apache.org/jira/browse/SOLR-8848
 Project: Solr
  Issue Type: Improvement
Reporter: Erick Erickson
Priority: Trivial


Logging the current alias definition as well as the "Updating aliases..." 
message would be helpful.



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

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

[jira] [Assigned] (SOLR-8848) When a SolrJ alias watch is triggered, the new alias state should be logged

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-8848:


Assignee: Erick Erickson

> When a SolrJ alias watch is triggered, the new alias state should be logged
> ---
>
> Key: SOLR-8848
> URL: https://issues.apache.org/jira/browse/SOLR-8848
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Trivial
>
> Logging the current alias definition as well as the "Updating aliases..." 
> message would be helpful.



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

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

[jira] [Commented] (SOLR-445) Update Handlers abort with bad documents

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-445:
-

digging into this now, thanks [~hossman]

> Update Handlers abort with bad documents
> 
>
> Key: SOLR-445
> URL: https://issues.apache.org/jira/browse/SOLR-445
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 1.3
>Reporter: Will Johnson
>Assignee: Hoss Man
> Attachments: SOLR-445-3_x.patch, SOLR-445-alternative.patch, 
> SOLR-445-alternative.patch, SOLR-445-alternative.patch, 
> SOLR-445-alternative.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, 
> SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, 
> SOLR-445.patch, SOLR-445.patch, SOLR-445_3x.patch, solr-445.xml
>
>
> Has anyone run into the problem of handling bad documents / failures mid 
> batch.  Ie:
> 
>   
> 1
>   
>   
> 2
> I_AM_A_BAD_DATE
>   
>   
> 3
>   
> 
> Right now solr adds the first doc and then aborts.  It would seem like it 
> should either fail the entire batch or log a message/return a code and then 
> continue on to add doc 3.  Option 1 would seem to be much harder to 
> accomplish and possibly require more memory while Option 2 would require more 
> information to come back from the API.  I'm about to dig into this but I 
> thought I'd ask to see if anyone had any suggestions, thoughts or comments.   
>  



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

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

[jira] [Updated] (SOLR-7264) DocValues should support BoolField

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-7264:
---
Fix Version/s: 6.1

> DocValues should support BoolField
> --
>
> Key: SOLR-7264
> URL: https://issues.apache.org/jira/browse/SOLR-7264
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.0
>Reporter: Kevin Osborn
> Fix For: 6.1
>
> Attachments: SOLR-7264.patch
>
>
> DocValues supports numerics and strings, but it currently does not support 
> booleans. Please add this support.
> Here is the error message you get if you try to use DocValues with a 
> BoolField.
> ERROR - 2015-03-18 00:49:54.041; org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.SolrException: SolrCore 'test' is not available 
> due to init failure: Could not load conf for core test: F
> ield type 
> boolean{class=org.apache.solr.schema.BoolField,analyzer=org.apache.solr.schema.FieldType$DefaultAnalyzer,args={sortMissingLast=true,
>  class=solr.BoolField}} does not support doc values. Schema fi
> le is /Users/kosborn/solr/server/solr/test/conf/schema.xml



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

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

[jira] [Commented] (LUCENE-7093) MemoryIndex does not support points

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7093:


bq. If we there many values (lets say a couple of hundred values) for a single 
field, wouldn't the current visit method be better

It's hard to say ... it invokes {{compare}} more than the normal BKD tree 
would, and the compare can be more costly than filtering a single value?

Also, I think the visit method only works in the 1D case ... for e.g. the 2D 
case, I think it may be buggy because the byte[] values were sorted only by the 
first dimension?

I feel like it's best to get a simple, correct, implementation in at first, and 
then worry about optimizing for the "many points in a single document" case 
later?

> MemoryIndex does not support points
> ---
>
> Key: LUCENE-7093
> URL: https://issues.apache.org/jira/browse/LUCENE-7093
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Martijn van Groningen
> Attachments: LUCENE-7093.patch, LUCENE-7093.patch
>
>
> I realized this glancing at LUCENE-7091.
> I think this should have points support or else people cannot move off of the 
> deprecated LegacyXXX encodings?



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

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

Re: Branch update merge blizzards

[Chris Hostetter]

: Is there some specific intent why there should be commit-level email for a
: mere non-release branch update? I mean, does anybody get any value from
: them? I do want to see them if master or branch_xy gets merged into, but
: not for branches LUCENE/SOLR-, especially when each of those Jira
: issues needs the same merge updates.

part of the issue is just the generalization of how the tools work -- 
branches that are important to some people are unimportant to tohers, and 
the commit notification email code doesn't really know which are which, so 
it does the same thing for every branch.

As discussed in another thread last month, i've filed an issue with INFRA 
to request that the details of what branch is being updated be included in 
every email subject...

https://issues.apache.org/jira/browse/INFRA-11462

...so ideally, moving forward, you can tell at a glance which commits are 
to feature branches vs "master" or bug fix branches (or have your email 
client filter/flag the ones you do/don't care about) ... even if a single 
push contains multiple commits to multiple branches.


-Hoss
http://www.lucidworks.com/

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

Re: git email format customizability: add branch to subject?

[Chris Hostetter]

I got side tracked, but I've filed a jira with this request...

https://issues.apache.org/jira/browse/INFRA-11462




: Date: Mon, 22 Feb 2016 14:09:51 -0700 (MST)
: From: Chris Hostetter 
: To: dev@lucene.apache.org, Christine Poerschke 
: Subject: Re: git email format customizability: add branch to subject?
: 
: 
: : +1 for keeping the repo name but perhaps we could drop the "git: " prefix?
: : 
: : Without the prefix the subject would still be fairly distinguishable 
: : from the "svn commit" emails such as "svn commit: r1731559 - 
: : /lucene/cms/trunk/content/extpaths.txt" (assuming the svn commit emails 
: : keep their existing format).
: 
: My concern was that w/o "git" explicitly in the subject somewhere, it 
: would be hard to setup simple filter rules for some folks since
: "lucene-solr" can appear in other subjects ... but i suppose the fact that 
: we have an explicit commits@lucene list for these emails makes that 
: concern moot since that can be part of whatever filter rule folks might 
: use.
: 
: Anybody else feel strongly about leaving "git:" in the subject?
: 
: : Looks good to me. I'd keep the repo name regardless of whether it's
: : the main repo or not.
: 
: I agree -- i know a lot of people who work on multiple projects but filter 
: all "commit" related emails to a single folder, nd being able to tell at a 
: glance which projust a message refers to is useful (let alone if/when we 
: add future git repos)
: 
: Any other concerns/opinions before i mover forward with contacting infra?
: 
: 
: 
: One other thing i recently realized is that tag creation notification 
: emails don't seem to follow the current pattern at all, note this email...
: 
: Subject: [lucene-solr] Git Push Summary
: 
http://mail-archives.apache.org/mod_mbox/lucene-commits/201602.mbox/%3c4bb21471466f4701ba9452b739acb...@git.apache.org%3E
: 
: ...I'll ask infra about getting those to conform to the same 
: subject pattern. 
: 
: 
: 
: 
: 
: 
: 
: -Hoss
: http://www.lucidworks.com/
: 

-Hoss
http://www.lucidworks.com/

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

[JENKINS] Lucene-Solr-Tests-master - Build # 994 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/994/

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

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:41735/x/bt/collection1]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:41735/x/bt/collection1]
at 
__randomizedtesting.SeedInfo.seed([FD17FC2F12DAE308:7543C3F5BC268EF0]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
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.cloud.AbstractFullDistribZkTestBase.queryServer(AbstractFullDistribZkTestBase.java:1397)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.assertPartialResults(CloudExitableDirectoryReaderTest.java:99)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.doTimeoutTests(CloudExitableDirectoryReaderTest.java:71)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.test(CloudExitableDirectoryReaderTest.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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 

[jira] [Commented] (LUCENE-7093) MemoryIndex does not support points

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen commented on LUCENE-7093:
---

bq. In addField you return right away if the field had point values, but this 
is dangerous because the field could also have e.g. doc values: (LatLonPoint 
just recently started doing this), maybe we can add a test case for that?

Good point. I'll add a test for this.

bq. Or maybe MemoryIndex should just use BytesRef[], instead of BytesRefArray, 
and sort that?

+1, lets simplify here. MemoryIndex only exists for a short amount of time and 
then it is tossed away, so we shouldn't spend to0 much effort in space 
efficient data structures here.

bq. Your visit function could be simplified too: just call the compare only 
once, and if it crosses, visit all points (with doc and value); 

If we there many values (lets say a couple of hundred values) for a single 
field, wouldn't the current visit method be better. (because less comparisons 
will need to happen). I have seen cases where fields had relatively a large 
number of terms.

> MemoryIndex does not support points
> ---
>
> Key: LUCENE-7093
> URL: https://issues.apache.org/jira/browse/LUCENE-7093
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Martijn van Groningen
> Attachments: LUCENE-7093.patch, LUCENE-7093.patch
>
>
> I realized this glancing at LUCENE-7091.
> I think this should have points support or else people cannot move off of the 
> deprecated LegacyXXX encodings?



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

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

[jira] [Commented] (SOLR-8176) Model distributed graph traversals with Streaming Expressions

[Gopal Patwa (JIRA)]

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

Gopal Patwa commented on SOLR-8176:
---

Kevin, I am also interested in your solution using GraphQuery with Kafka 

> Model distributed graph traversals with Streaming Expressions
> -
>
> Key: SOLR-8176
> URL: https://issues.apache.org/jira/browse/SOLR-8176
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java, SolrCloud, SolrJ
>Affects Versions: master
>Reporter: Joel Bernstein
>  Labels: Graph
> Fix For: master
>
>
> I think it would be useful to model a few *distributed graph traversal* use 
> cases with Solr's *Streaming Expression* language. This ticket will explore 
> different approaches with a goal of implementing two or three common graph 
> traversal use cases.



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

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

[jira] [Updated] (LUCENE-7091) Add doc values support to MemoryIndex

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen updated LUCENE-7091:
--
Attachment: LUCENE-7091.patch

Ah, that makes more sense. I misunderstood what you meant earlier. I've updated 
the patch. Thank you for this thorough review! 

> Add doc values support to MemoryIndex
> -
>
> Key: LUCENE-7091
> URL: https://issues.apache.org/jira/browse/LUCENE-7091
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Assignee: David Smiley
> Attachments: LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, 
> LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, 
> LUCENE-7091.patch, LUCENE-7091.patch
>
>
> Sometimes queries executed via the MemoryIndex require certain things to be 
> stored as doc values. Today this isn't possible because the memory index 
> doesn't support this and these queries silently return no results.



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

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

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_72) - Build # 45 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/45/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseG1GC

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

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

Stack Trace:
java.lang.AssertionError: replicaCount expected:<0> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([B8C3CCD954FB095E:3097F303FA0764A6]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testNoConfigSetExist(CollectionsAPIDistributedZkTest.java:601)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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)
   

[jira] [Commented] (LUCENE-7103) further optimize LatLonPoint.newDistanceSort

[ASF subversion and git services (JIRA)]

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

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

Commit 3163b98959ae834b27a0ee8479344b61460d8851 in lucene-solr's branch 
refs/heads/branch_6x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3163b98 ]

LUCENE-7103: further optimize LatLonPoint.newDistanceSort


> further optimize LatLonPoint.newDistanceSort
> 
>
> Key: LUCENE-7103
> URL: https://issues.apache.org/jira/browse/LUCENE-7103
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7103.patch
>
>
> This comparator creates bounding boxes to avoid calling haversin(), so its no 
> longer a hotspot for most use cases.
> But in the worst case, it could still get called many times. This could be 
> because the user had a massive top N value, or because the incoming data is 
> sorted or mostly sorted by decreasing distance, etc.
> We can optimize the worst case by not invoking a full haversin, just using 
> something that is rank-equivalent.



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

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

[jira] [Commented] (LUCENE-7103) further optimize LatLonPoint.newDistanceSort

[ASF subversion and git services (JIRA)]

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

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

Commit 1660b5630aec516fb7365e8cb5c0a8a2bfd14d2f in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1660b56 ]

LUCENE-7103: further optimize LatLonPoint.newDistanceSort


> further optimize LatLonPoint.newDistanceSort
> 
>
> Key: LUCENE-7103
> URL: https://issues.apache.org/jira/browse/LUCENE-7103
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7103.patch
>
>
> This comparator creates bounding boxes to avoid calling haversin(), so its no 
> longer a hotspot for most use cases.
> But in the worst case, it could still get called many times. This could be 
> because the user had a massive top N value, or because the incoming data is 
> sorted or mostly sorted by decreasing distance, etc.
> We can optimize the worst case by not invoking a full haversin, just using 
> something that is rank-equivalent.



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

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

[jira] [Commented] (SOLR-7090) Cross collection join

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-7090:
--

These two JIRAs are at least in the same ballpark if you think of an external 
collection as a specialized external data source in SOLR-7341.

My point in linking these is to make sure both are considered if it turns out 
that these should be folded together.

> Cross collection join
> -
>
> Key: SOLR-7090
> URL: https://issues.apache.org/jira/browse/SOLR-7090
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
> Fix For: 5.2, master
>
> Attachments: SOLR-7090-fulljoin.patch, SOLR-7090.patch
>
>
> Although SOLR-4905 supports joins across collections in Cloud mode, there are 
> limitations, (i) the secondary collection must be replicated at each node 
> where the primary collection has a replica, (ii) the secondary collection 
> must be singly sharded.
> This issue explores ideas/possibilities of cross collection joins, even 
> across nodes. This will be helpful for users who wish to maintain boosts or 
> signals in a secondary, more frequently updated collection, and perform query 
> time join of these boosts/signals with results from the primary collection.



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

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

[jira] [Updated] (LUCENE-7101) OfflineSorter's merging is O(N^2) cost for large sorts

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-7101:
---
Attachment: LUCENE-7101.patch

Patch, adding a trivial "log merge policy" to {{OfflineSorter}}, and changing 
its default merge factor from 128 to 10.

I also fixed the 2B points tests to not "cheat" by giving BKD more heap than 
the defaults, and improved {{BKDWriter}}'s temp file naming

I'm running {{Test2BBKDPoints.test2D}} now ...

> OfflineSorter's merging is O(N^2) cost for large sorts
> --
>
> Key: LUCENE-7101
> URL: https://issues.apache.org/jira/browse/LUCENE-7101
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: master, 6.0
>
> Attachments: LUCENE-7101.patch
>
>
> Our {{OfflineSorter}} acts just like Lucene, writing small initial
> segments of sorted values (from what it was able to sort at once in
> heap), periodically merging them when there are too many, and doing a
> {{forceMerge(1)}} in the end.
> But the merge logic is too simplistic today, resulting in O(N^2)
> cost.  Smallish sorts usually won't hit it, because the default 128
> merge factor is so high, but e.g. the new 2B points tests do hit the
> N^2 behavior.  I suspect the high merge factor hurts performance (OS
> struggles to use what free RAM it has to read-ahead on 128 files), and
> also risks file descriptor exhaustion.
> I think we should implement a simple log merge policy for it, and drop
> its default merge factor to 10.



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

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

[jira] [Commented] (LUCENE-7103) further optimize LatLonPoint.newDistanceSort

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7103:


+1, very cool opto!  It takes advantage of the horrors of our comparator APIs!

> further optimize LatLonPoint.newDistanceSort
> 
>
> Key: LUCENE-7103
> URL: https://issues.apache.org/jira/browse/LUCENE-7103
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7103.patch
>
>
> This comparator creates bounding boxes to avoid calling haversin(), so its no 
> longer a hotspot for most use cases.
> But in the worst case, it could still get called many times. This could be 
> because the user had a massive top N value, or because the incoming data is 
> sorted or mostly sorted by decreasing distance, etc.
> We can optimize the worst case by not invoking a full haversin, just using 
> something that is rank-equivalent.



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_72) - Build # 16209 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16209/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=5273, 
name=testExecutor-2211-thread-6, state=RUNNABLE, 
group=TGRP-UnloadDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=5273, name=testExecutor-2211-thread-6, 
state=RUNNABLE, group=TGRP-UnloadDistributedZkTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:46396/vs_cx
at __randomizedtesting.SeedInfo.seed([4D5617483C43693]:0)
at 
org.apache.solr.cloud.BasicDistributedZkTest.lambda$createCores$0(BasicDistributedZkTest.java:583)
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)
Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occured 
while waiting response from server at: http://127.0.0.1:46396/vs_cx
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:588)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.BasicDistributedZkTest.lambda$createCores$0(BasicDistributedZkTest.java:581)
... 4 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
at 
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:487)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:482)
... 8 more




Build Log:
[...truncated 11 lines...]
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$5.execute(JGitAPIImpl.java:1456)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1013)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 

[jira] [Updated] (LUCENE-7103) further optimize LatLonPoint.newDistanceSort

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7103:

Attachment: LUCENE-7103.patch

simple patch. We "do the rest" of the haversin calculation only when we need 
the final value: value() and compareTop().

> further optimize LatLonPoint.newDistanceSort
> 
>
> Key: LUCENE-7103
> URL: https://issues.apache.org/jira/browse/LUCENE-7103
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7103.patch
>
>
> This comparator creates bounding boxes to avoid calling haversin(), so its no 
> longer a hotspot for most use cases.
> But in the worst case, it could still get called many times. This could be 
> because the user had a massive top N value, or because the incoming data is 
> sorted or mostly sorted by decreasing distance, etc.
> We can optimize the worst case by not invoking a full haversin, just using 
> something that is rank-equivalent.



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

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

[jira] [Created] (LUCENE-7103) further optimize LatLonPoint.newDistanceSort

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7103:
---

 Summary: further optimize LatLonPoint.newDistanceSort
 Key: LUCENE-7103
 URL: https://issues.apache.org/jira/browse/LUCENE-7103
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir


This comparator creates bounding boxes to avoid calling haversin(), so its no 
longer a hotspot for most use cases.

But in the worst case, it could still get called many times. This could be 
because the user had a massive top N value, or because the incoming data is 
sorted or mostly sorted by decreasing distance, etc.

We can optimize the worst case by not invoking a full haversin, just using 
something that is rank-equivalent.



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

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

[jira] [Commented] (LUCENE-7093) MemoryIndex does not support points

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7093:


Thanks [~martijn], this is nice!

You don't have to box the point dimensionCount/numBytes up from {{int}} to 
{{Integer}}: 0 can safely mean "this field has no points".

In {{addField}} you return right away if the field had point values, but this 
is dangerous because the field could also have e.g. doc values: 
({{LatLonPoint}} just recently started doing this), maybe we can add a test 
case for that?

Instead of making {{BytesRefArray.sort}} fully public, can we make a version 
that always sorts by natural order public?  This class's entire existence 
scares me so I like to minimize what methods we make public, even for internal 
usage.

Or maybe {{MemoryIndex}} should just use {{BytesRef[]}}, instead of 
{{BytesRefArray}}, and sort that?  The vast majority of the time we are looking 
at a single point value for the fields here?  Your visit function could be 
simplified too: just call the {{compare}} only once, and if it crosses, visit 
all points (with doc and value); if the cell is inside the query, visit with 
just doc; else, do nothing?


> MemoryIndex does not support points
> ---
>
> Key: LUCENE-7093
> URL: https://issues.apache.org/jira/browse/LUCENE-7093
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Martijn van Groningen
> Attachments: LUCENE-7093.patch, LUCENE-7093.patch
>
>
> I realized this glancing at LUCENE-7091.
> I think this should have points support or else people cannot move off of the 
> deprecated LegacyXXX encodings?



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

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

Jenkins VMs updated (OSX and Windows)

[Uwe Schindler]

Hi,

sorry for the build failures. I did not update the Slave's paths. The reason 
for this was a general Operating System Update of the slaves today:

- The Windows Slave is now running "Windows 10 Prof."
- The MacOSX slave to runs with "El Capitan" including "rootless" mode.

Sorry for any failures that may occur because of this.
Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -Original Message-
> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> Sent: Monday, March 14, 2016 7:53 PM
> To: dev@lucene.apache.org
> Subject: [JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_72) - Build # 43 -
> Still Failing!
> 
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/43/
> Java: 32bit/jdk1.8.0_72 -server -XX:+UseConcMarkSweepGC
> 
> No tests ran.
> 
> Build Log:
> [...truncated 19 lines...]
> BUILD FAILED
> C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\build.xml:21: The
> following error occurred while executing this line:
> C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\common-
> build.xml:302: Minimum supported Java version is 1.8.
> 
> Total time: 0 seconds
> Build step 'Invoke Ant' marked build as failure
> Archiving artifacts
> [WARNINGS] Skipping publisher since build result is FAILURE
> Recording test results
> ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
> were
> found. Configuration error?
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
> 



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

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_72) - Build # 44 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/44/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseSerialGC

No tests ran.

Build Log:
[...truncated 520 lines...]
ERROR: Connection was broken: java.io.IOException: Unexpected termination of 
the channel
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
Caused by: java.io.EOFException
at 
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2325)
at 
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2794)
at 
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:801)
at java.io.ObjectInputStream.(ObjectInputStream.java:299)
at 
hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:48)
at 
hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)

Build step 'Invoke Ant' marked build as failure
ERROR: Step ‘Archive the artifacts’ failed: no workspace for 
Lucene-Solr-6.x-Windows #44
ERROR: Step ‘Scan for compiler warnings’ failed: no workspace for 
Lucene-Solr-6.x-Windows #44
ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for 
Lucene-Solr-6.x-Windows #44
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (SOLR-8776) Support RankQuery in grouping

[Diego Ceccarelli (JIRA)]

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

Diego Ceccarelli commented on SOLR-8776:


Update: I found a way to change the behavior of the collectors without moving 
RankQuery into Lucene. This new patch performs the group reranking without 
changing Lucene. The only difference is that if the Query is a RankQuery 
instead of using {{TermSecondPassGroupingCollector}} I'll use a 
{{RerankTermSecondPassGroupingCollector}}. The new collector will scan the 
groups collectors and wrap them in 'rerank collectors': 
{code:java}

for (SearchGroup group : groups) {
if (query != null) {
  collector = groupMap.get(group.groupValue).collector;
  collector = query.getTopDocsCollector(collector, groupSort, searcher);
  groupMap.put(group.groupValue, new 
SearchGroupDocs(group.groupValue, collector));
}
}
{code}

 

> Support RankQuery in grouping
> -
>
> Key: SOLR-8776
> URL: https://issues.apache.org/jira/browse/SOLR-8776
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: master
>Reporter: Diego Ceccarelli
>Priority: Minor
> Fix For: master
>
> Attachments: 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch
>
>
> Currently it is not possible to use RankQuery [1] and Grouping [2] together 
> (see also [3]). In some situations Grouping can be replaced by Collapse and 
> Expand Results [4] (that supports reranking), but i) collapse cannot 
> guarantee that at least a minimum number of groups will be returned for a 
> query, and ii) in the Solr Cloud setting you will have constraints on how to 
> partition the documents among the shards.
> I'm going to start working on supporting RankQuery in grouping. I'll start 
> attaching a patch with a test that fails because grouping does not support 
> the rank query and then I'll try to fix the problem, starting from the non 
> distributed setting (GroupingSearch).
> My feeling is that since grouping is mostly performed by Lucene, RankQuery 
> should be refactored and moved (or partially moved) there. 
> Any feedback is welcome.
> [1] https://cwiki.apache.org/confluence/display/solr/RankQuery+API 
> [2] https://cwiki.apache.org/confluence/display/solr/Result+Grouping
> [3] 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201507.mbox/%3ccahm-lpuvspest-sw63_8a6gt-wor6ds_t_nb2rope93e4+s...@mail.gmail.com%3E
> [4] 
> https://cwiki.apache.org/confluence/display/solr/Collapse+and+Expand+Results



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

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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_72) - Build # 43 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/43/
Java: 32bit/jdk1.8.0_72 -server -XX:+UseConcMarkSweepGC

No tests ran.

Build Log:
[...truncated 19 lines...]
BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\build.xml:21: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\common-build.xml:302: 
Minimum supported Java version is 1.8.

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_72) - Build # 42 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/42/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseG1GC

No tests ran.

Build Log:
[...truncated 24 lines...]
ERROR: Connection was broken: java.io.IOException: Unexpected termination of 
the channel
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
Caused by: java.io.EOFException
at 
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2325)
at 
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2794)
at 
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:801)
at java.io.ObjectInputStream.(ObjectInputStream.java:299)
at 
hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:48)
at 
hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)

Build step 'Invoke Ant' marked build as failure
ERROR: Step ‘Archive the artifacts’ failed: no workspace for 
Lucene-Solr-6.x-Windows #42
ERROR: Step ‘Scan for compiler warnings’ failed: no workspace for 
Lucene-Solr-6.x-Windows #42
ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for 
Lucene-Solr-6.x-Windows #42
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Updated] (SOLR-8776) Support RankQuery in grouping

[Diego Ceccarelli (JIRA)]

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

Diego Ceccarelli updated SOLR-8776:
---
Attachment: 0001-SOLR-8776-Support-RankQuery-in-grouping.patch

> Support RankQuery in grouping
> -
>
> Key: SOLR-8776
> URL: https://issues.apache.org/jira/browse/SOLR-8776
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: master
>Reporter: Diego Ceccarelli
>Priority: Minor
> Fix For: master
>
> Attachments: 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch
>
>
> Currently it is not possible to use RankQuery [1] and Grouping [2] together 
> (see also [3]). In some situations Grouping can be replaced by Collapse and 
> Expand Results [4] (that supports reranking), but i) collapse cannot 
> guarantee that at least a minimum number of groups will be returned for a 
> query, and ii) in the Solr Cloud setting you will have constraints on how to 
> partition the documents among the shards.
> I'm going to start working on supporting RankQuery in grouping. I'll start 
> attaching a patch with a test that fails because grouping does not support 
> the rank query and then I'll try to fix the problem, starting from the non 
> distributed setting (GroupingSearch).
> My feeling is that since grouping is mostly performed by Lucene, RankQuery 
> should be refactored and moved (or partially moved) there. 
> Any feedback is welcome.
> [1] https://cwiki.apache.org/confluence/display/solr/RankQuery+API 
> [2] https://cwiki.apache.org/confluence/display/solr/Result+Grouping
> [3] 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201507.mbox/%3ccahm-lpuvspest-sw63_8a6gt-wor6ds_t_nb2rope93e4+s...@mail.gmail.com%3E
> [4] 
> https://cwiki.apache.org/confluence/display/solr/Collapse+and+Expand+Results



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

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

[JENKINS] Lucene-Solr-master-Windows () - Build # 5707 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5707/
Java: 

No tests ran.

Build Log:
[...truncated 2 lines...]
ERROR: SEVERE ERROR occurs
org.jenkinsci.lib.envinject.EnvInjectException: java.lang.InterruptedException
at 
org.jenkinsci.plugins.envinject.service.EnvironmentVariablesNodeLoader.gatherEnvironmentVariablesNode(EnvironmentVariablesNodeLoader.java:77)
at 
org.jenkinsci.plugins.envinject.EnvInjectListener.loadEnvironmentVariablesNode(EnvInjectListener.java:81)
at 
org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironment(EnvInjectListener.java:39)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(AbstractBuild.java:572)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:492)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at hudson.remoting.Request.call(Request.java:147)
at hudson.remoting.Channel.call(Channel.java:780)
at hudson.FilePath.act(FilePath.java:1074)
at 
org.jenkinsci.plugins.envinject.service.EnvironmentVariablesNodeLoader.gatherEnvironmentVariablesNode(EnvironmentVariablesNodeLoader.java:44)
... 8 more
ERROR: Step ‘Archive the artifacts’ failed: no workspace for 
Lucene-Solr-master-Windows #5707
ERROR: Step ‘Scan for compiler warnings’ failed: no workspace for 
Lucene-Solr-master-Windows #5707
ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for 
Lucene-Solr-master-Windows #5707
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6993:
-

My mistake. thanks for the reminder. I have been working to get things off the 
old numeric encoding but need to break up that work with other things too. 

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



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

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

[jira] [Commented] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Mike Drob (JIRA)]

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

Mike Drob commented on LUCENE-6993:
---

[~rcmuir] - did you get a chance to look at this? Should I wait to ping you 
again until after 6.0 has been released?

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



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

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

[jira] [Commented] (LUCENE-7102) LatLonPoint newDistanceSort fails with "sort missing first"

[ASF subversion and git services (JIRA)]

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

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

Commit a6fe1c0b155ff464d0596289bb209eef99c269d3 in lucene-solr's branch 
refs/heads/branch_6x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a6fe1c0 ]

LUCENE-7102: LatLonPoint.newDistanceSort fails with "sort missing first"


> LatLonPoint newDistanceSort fails with "sort missing first"
> ---
>
> Key: LUCENE-7102
> URL: https://issues.apache.org/jira/browse/LUCENE-7102
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7102.patch
>
>
> The distance sort comparator creates bounding boxes when the priority queue 
> is full, to speed up sorting.
> But with missing values (which we don't test), they can be e.g. -Inf/+Inf and 
> we do the wrong thing (e.g. try to make illegal infinite bounding boxes).



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

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

[jira] [Commented] (LUCENE-7102) LatLonPoint newDistanceSort fails with "sort missing first"

[ASF subversion and git services (JIRA)]

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

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

Commit 0f949c815343c853499d518e7d565d642d93ce63 in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0f949c8 ]

LUCENE-7102: LatLonPoint.newDistanceSort fails with "sort missing first"


> LatLonPoint newDistanceSort fails with "sort missing first"
> ---
>
> Key: LUCENE-7102
> URL: https://issues.apache.org/jira/browse/LUCENE-7102
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7102.patch
>
>
> The distance sort comparator creates bounding boxes when the priority queue 
> is full, to speed up sorting.
> But with missing values (which we don't test), they can be e.g. -Inf/+Inf and 
> we do the wrong thing (e.g. try to make illegal infinite bounding boxes).



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

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

[jira] [Updated] (SOLR-8819) Implement DatabaseMetaDataImpl getTables() and fix getSchemas()

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8819:
---
Attachment: SOLR-8819.patch

Fix usage of get/set Schema in ConnectionImpl.

> Implement DatabaseMetaDataImpl getTables() and fix getSchemas()
> ---
>
> Key: SOLR-8819
> URL: https://issues.apache.org/jira/browse/SOLR-8819
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master
>Reporter: Kevin Risden
> Attachments: SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch
>
>
> DbVisualizer NPE when clicking on DB References tab. After connecting, NPE if 
> double click on "DB" under connection name then click on References tab.



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

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

[jira] [Commented] (LUCENE-7091) Add doc values support to MemoryIndex

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7091:
--

Eh, the grow algorithm/code still isn't right.  The code in the patch will 
double the size even though it's likely plenty big to add the current long 
trying to get added.  This is what I mean:
{code:java}
  case SORTED_NUMERIC:
if (info.numericProducer.dvLongValues == null) {
  info.numericProducer.dvLongValues = new long[4];
}
info.numericProducer.dvLongValues = 
ArrayUtil.grow(info.numericProducer.dvLongValues, info.numericProducer.count + 
1);
info.numericProducer.dvLongValues[info.numericProducer.count++] = 
(long) docValuesValue;
break;
{code}

Everything else is good.  Assuming you agree with this code snippet above, +1 
from me to commit.

> Add doc values support to MemoryIndex
> -
>
> Key: LUCENE-7091
> URL: https://issues.apache.org/jira/browse/LUCENE-7091
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Assignee: David Smiley
> Attachments: LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, 
> LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, 
> LUCENE-7091.patch
>
>
> Sometimes queries executed via the MemoryIndex require certain things to be 
> stored as doc values. Today this isn't possible because the memory index 
> doesn't support this and these queries silently return no results.



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

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

[jira] [Updated] (SOLR-8819) Implement DatabaseMetaDataImpl getTables() and fix getSchemas()

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8819:
---
Attachment: SOLR-8819.patch

Add test file that was missed on previous patch.

> Implement DatabaseMetaDataImpl getTables() and fix getSchemas()
> ---
>
> Key: SOLR-8819
> URL: https://issues.apache.org/jira/browse/SOLR-8819
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master
>Reporter: Kevin Risden
> Attachments: SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch, 
> SOLR-8819.patch
>
>
> DbVisualizer NPE when clicking on DB References tab. After connecting, NPE if 
> double click on "DB" under connection name then click on References tab.



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

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

[jira] [Commented] (LUCENE-7102) LatLonPoint newDistanceSort fails with "sort missing first"

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7102:
-

I thought about this too, but we can do this separately if we want? 

Either way, i don't think we should pass +/- infinite radius to the geo 
functions.

> LatLonPoint newDistanceSort fails with "sort missing first"
> ---
>
> Key: LUCENE-7102
> URL: https://issues.apache.org/jira/browse/LUCENE-7102
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7102.patch
>
>
> The distance sort comparator creates bounding boxes when the priority queue 
> is full, to speed up sorting.
> But with missing values (which we don't test), they can be e.g. -Inf/+Inf and 
> we do the wrong thing (e.g. try to make illegal infinite bounding boxes).



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

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

[jira] [Commented] (SOLR-8847) SolrJ JDBC - Implement "Select *"

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8847:


This probably relates to the work that would be required to get the Apache 
Calcite optimizer into the SQL handling.

> SolrJ JDBC - Implement "Select *" 
> --
>
> Key: SOLR-8847
> URL: https://issues.apache.org/jira/browse/SOLR-8847
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master
>Reporter: Trey Cahill
>
> The sql query "Select *" is commonly used, but currently all fields need to 
> be specified.  This can cause some troubles as "Select *" has been used to 
> pull back column metadata in some JDBC clients.



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

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

[jira] [Commented] (SOLR-8847) SolrJ JDBC - Implement "Select *"

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8847:


Just some notes on the topic. Currently the Schema API supports getting the 
schema, but this won't get dynamic fields that are present in the collection. 
ie: *_i will come back but mycount_i will not. There are a few workarounds for 
this, but nothing that seems well supported.
1) use the luke request handler
2) use csv wt and headers to get back the columns.
Both of these were provided to a stackoverflow answer previously: 
http://stackoverflow.com/questions/3211139/solr-retrieve-field-names-from-a-solr-index

> SolrJ JDBC - Implement "Select *" 
> --
>
> Key: SOLR-8847
> URL: https://issues.apache.org/jira/browse/SOLR-8847
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master
>Reporter: Trey Cahill
>
> The sql query "Select *" is commonly used, but currently all fields need to 
> be specified.  This can cause some troubles as "Select *" has been used to 
> pull back column metadata in some JDBC clients.



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

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

[jira] [Commented] (LUCENE-7102) LatLonPoint newDistanceSort fails with "sort missing first"

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7102:


+1, nice catch.

I'm not sure we should even allow "sort missing first"...

> LatLonPoint newDistanceSort fails with "sort missing first"
> ---
>
> Key: LUCENE-7102
> URL: https://issues.apache.org/jira/browse/LUCENE-7102
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7102.patch
>
>
> The distance sort comparator creates bounding boxes when the priority queue 
> is full, to speed up sorting.
> But with missing values (which we don't test), they can be e.g. -Inf/+Inf and 
> we do the wrong thing (e.g. try to make illegal infinite bounding boxes).



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

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

[jira] [Updated] (SOLR-8847) SolrJ JDBC - Implement "Select *"

[Trey Cahill (JIRA)]

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

Trey Cahill updated SOLR-8847:
--
Issue Type: Sub-task  (was: Improvement)
Parent: SOLR-8659

> SolrJ JDBC - Implement "Select *" 
> --
>
> Key: SOLR-8847
> URL: https://issues.apache.org/jira/browse/SOLR-8847
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master
>Reporter: Trey Cahill
>
> The sql query "Select *" is commonly used, but currently all fields need to 
> be specified.  This can cause some troubles as "Select *" has been used to 
> pull back column metadata in some JDBC clients.



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

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

[jira] [Created] (SOLR-8847) SolrJ JDBC - Implement "Select *"

[Trey Cahill (JIRA)]

Trey Cahill created SOLR-8847:
-

 Summary: SolrJ JDBC - Implement "Select *" 
 Key: SOLR-8847
 URL: https://issues.apache.org/jira/browse/SOLR-8847
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Affects Versions: master
Reporter: Trey Cahill


The sql query "Select *" is commonly used, but currently all fields need to be 
specified.  This can cause some troubles as "Select *" has been used to pull 
back column metadata in some JDBC clients.



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

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

Re: lucene-solr git commit: SOLR-8765: Set parameters correctly in async shard requests

[Chris Hostetter]

: Hm, this is weird - git appears to be using my apache email address 
: (configured for this particularly repository) as author emails, but then 
: using global settings for the committer address.  But, if I run git log 
: --pretty=full locally, then it shows my apache email address for both 
: author and committer lines.

that's incredibly bizare.

locally, this is what "git show --pretty=raw 6b2f36389" gives me...

hossman@tray:~/lucene/dev [master] $ git show --pretty=raw 6b2f36389
commit 6b2f3638969e872c704e3d192caec07ad7ef99ed
tree b5415e43f6e1511d80cc3bc53197b00c32ccae24
parent 4e911f2d3a029ae30dad9ea5ffb42530398adcbc
author Alan Woodward  1457545087 +
committer Alan Woodward  1457545175 +
...


...if you're seeing something diff locally, then the only possibilities i 
can think of are:L

1) something on the apache side is rewriting the commiter metadata after 
you push (which IIUC is not possible)

2) something on your client side is "mapping" the *real* data in the 
committer field (alan.woodw...@romseysoftware.co.uk) to your apache addr 
when displaying to you


what does "git var -l | grep romsey" return on the machine where you did 
that commit?  (env vars like GIT_COMMITTER_EMAIL override git config 
options)





: 
: 
: On 9 Mar 2016, at 17:39, romseyg...@apache.org wrote:
: 
: > Repository: lucene-solr
: > Updated Branches:
: >  refs/heads/branch_6x 4e911f2d3 -> 6b2f36389
: > 
: > 
: > SOLR-8765: Set parameters correctly in async shard requests
: > 
: > 
: > Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
: > Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/6b2f3638
: > Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/6b2f3638
: > Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/6b2f3638
: > 
: > Branch: refs/heads/branch_6x
: > Commit: 6b2f3638969e872c704e3d192caec07ad7ef99ed
: > Parents: 4e911f2
: > Author: Alan Woodward 
: > Authored: Wed Mar 9 17:38:07 2016 +
: > Committer: Alan Woodward 
: > Committed: Wed Mar 9 17:39:35 2016 +
: > 
: > --
: > .../apache/solr/client/solrj/request/CollectionAdminRequest.java   | 2 ++
: > 1 file changed, 2 insertions(+)
: > --
: > 
: > 
: > 
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/6b2f3638/solr/solrj/src/java/org/apache/solr/client/solrj/request/CollectionAdminRequest.java
: > --
: > diff --git 
a/solr/solrj/src/java/org/apache/solr/client/solrj/request/CollectionAdminRequest.java
 
b/solr/solrj/src/java/org/apache/solr/client/solrj/request/CollectionAdminRequest.java
: > index 4f28408..76eb19f 100644
: > --- 
a/solr/solrj/src/java/org/apache/solr/client/solrj/request/CollectionAdminRequest.java
: > +++ 
b/solr/solrj/src/java/org/apache/solr/client/solrj/request/CollectionAdminRequest.java
: > @@ -203,6 +203,8 @@ public abstract class CollectionAdminRequest
: > 
: > public AsyncShardSpecificAdminRequest(CollectionAction action, String 
collection, String shard) {
: >   super(action);
: > +  this.collection = collection;
: > +  this.shard = shard;
: > }
: > 
: > @Deprecated
: > 
: 
: 
: -
: To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: For additional commands, e-mail: dev-h...@lucene.apache.org
: 
: 

-Hoss
http://www.lucidworks.com/

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

[jira] [Updated] (SOLR-8846) SolrJ JDBC - SparkSQL documentation

[Trey Cahill (JIRA)]

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

Trey Cahill updated SOLR-8846:
--
Issue Type: Sub-task  (was: Improvement)
Parent: SOLR-8659

> SolrJ JDBC - SparkSQL documentation
> ---
>
> Key: SOLR-8846
> URL: https://issues.apache.org/jira/browse/SOLR-8846
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master
>Reporter: Trey Cahill
>
> Like SOLR-8521, it would be great to document how SparkSQL can be used with 
> SolrJ JDBC.



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

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

[jira] [Updated] (SOLR-8845) SolrJ JDBC - Ensure that SparkSQL works with SolrJ JDBC

[Trey Cahill (JIRA)]

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

Trey Cahill updated SOLR-8845:
--
Issue Type: Sub-task  (was: Improvement)
Parent: SOLR-8659

> SolrJ JDBC - Ensure that SparkSQL works with SolrJ JDBC
> ---
>
> Key: SOLR-8845
> URL: https://issues.apache.org/jira/browse/SOLR-8845
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master
>Reporter: Trey Cahill
>
> Ensure that SparkSQL is able work with SolrJ JDBC.  
> Currently, in Spark 1.6 there are 2 known issues:
> 1. SparkSQL uses a connection.prepareStatement() call, which returns null in 
> the SolrJ implementation
> 2. SparkSQL query's via a "select *" query, which is currently not supported.



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

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

[jira] [Created] (SOLR-8846) SolrJ JDBC - SparkSQL documentation

[Trey Cahill (JIRA)]

Trey Cahill created SOLR-8846:
-

 Summary: SolrJ JDBC - SparkSQL documentation
 Key: SOLR-8846
 URL: https://issues.apache.org/jira/browse/SOLR-8846
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Affects Versions: master
Reporter: Trey Cahill


Like SOLR-8521, it would be great to document how SparkSQL can be used with 
SolrJ JDBC.



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

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

[jira] [Updated] (LUCENE-7102) LatLonPoint newDistanceSort fails with "sort missing first"

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7102:

Attachment: LUCENE-7102.patch

Here is a patch (with tests for missing, and different missingValues).

First we restrict missingValue to either Double.POSITIVE_INFINITY (missing 
values last) and Double.NEGATIVE_INFINITY (missing values first). This keeps 
things simpler and will allow for more optimizations.

In either case we can just bound Integer.MIN_VALUE .. Integer.MAX_VALUE for 
each dimension:
* +Inf means we've filled the priority queue with only missing values, so any 
possible value competes.
* -Inf means at this point, only missing values can possibly compete anymore 
(and only if you have another comparator). I don't think we should do anything 
tricky to optimize this case.

> LatLonPoint newDistanceSort fails with "sort missing first"
> ---
>
> Key: LUCENE-7102
> URL: https://issues.apache.org/jira/browse/LUCENE-7102
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7102.patch
>
>
> The distance sort comparator creates bounding boxes when the priority queue 
> is full, to speed up sorting.
> But with missing values (which we don't test), they can be e.g. -Inf/+Inf and 
> we do the wrong thing (e.g. try to make illegal infinite bounding boxes).



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

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

[jira] [Created] (LUCENE-7102) LatLonPoint newDistanceSort fails with "sort missing first"

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7102:
---

 Summary: LatLonPoint newDistanceSort fails with "sort missing 
first"
 Key: LUCENE-7102
 URL: https://issues.apache.org/jira/browse/LUCENE-7102
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


The distance sort comparator creates bounding boxes when the priority queue is 
full, to speed up sorting.

But with missing values (which we don't test), they can be e.g. -Inf/+Inf and 
we do the wrong thing (e.g. try to make illegal infinite bounding boxes).




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

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

[jira] [Created] (SOLR-8845) SolrJ JDBC - Ensure that SparkSQL works with SolrJ JDBC

[Trey Cahill (JIRA)]

Trey Cahill created SOLR-8845:
-

 Summary: SolrJ JDBC - Ensure that SparkSQL works with SolrJ JDBC
 Key: SOLR-8845
 URL: https://issues.apache.org/jira/browse/SOLR-8845
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Affects Versions: master
Reporter: Trey Cahill


Ensure that SparkSQL is able work with SolrJ JDBC.  
Currently, in Spark 1.6 there are 2 known issues:
1. SparkSQL uses a connection.prepareStatement() call, which returns null in 
the SolrJ implementation
2. SparkSQL query's via a "select *" query, which is currently not supported.



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

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 54 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/54/

49 tests failed.
FAILED:  org.apache.solr.TestHighlightDedupGrouping.test

Error Message:
IOException occured when talking to server at: 
https://127.0.0.1:50425/qpm/n/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:50425/qpm/n/collection1
at 
__randomizedtesting.SeedInfo.seed([E143AD1061B53D65:691792CACF49509D]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:591)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:895)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:858)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:873)
at 
org.apache.solr.BaseDistributedSearchTestCase.del(BaseDistributedSearchTestCase.java:551)
at 
org.apache.solr.TestHighlightDedupGrouping.basicTest(TestHighlightDedupGrouping.java:45)
at 
org.apache.solr.TestHighlightDedupGrouping.test(TestHighlightDedupGrouping.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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 

[jira] [Commented] (SOLR-445) Update Handlers abort with bad documents

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-445:
---

(ment to post last friday but was blocked by the jira outage)

Ok ... i think things are looking pretty good on the jira/SOLR-445 branch -- 
good enough that I'd really like some help reviewing the code & sanity checking 
the API (and internals for anyone who is up for it)...



For folks who haven't been following closely, here's what the configuration 
looks like (from the javadocs)...

{code}
  
10
  
{code}

When a chain with this processor is used, but maxErrors isn't exceeded, here's 
what the response looks like...

{code}
$ curl 
'http://localhost:8983/solr/techproducts/update?update.chain=tolerant-chain=json=true=-1'
 -H "Content-Type: application/json" --data-binary '{"add" : { 
"doc":{"id":"1","foo_i":"bogus"}}, "delete": {"query":"malformed:["}}'
{
  "responseHeader":{
"errors":[{
"type":"ADD",
"id":"1",
"message":"ERROR: [doc=1] Error adding field 'foo_i'='bogus' msg=For 
input string: \"bogus\""},
  {
"type":"DELQ",
"id":"malformed:[",
"message":"org.apache.solr.search.SyntaxError: Cannot parse 
'malformed:[': Encountered \"\" at line 1, column 11.\nWas expecting one 
of:\n ...\n ...\n"}],
"maxErrors":-1,
"status":0,
"QTime":1}}
{code}

Note in the above example that:

* maxErrors can be overridden on a per-request basis
* an effective {{maxErrors==-1}} (either from config, or request param) means 
"unlimited" (under the covers it's using {{Integer.MAX_VALUE}})

If/When maxErrors is reached for a request, then the _first_ exception that the 
processor caught is propagated back to the user, and metadata is set on that 
exception with all of the same details about all the tolerated errors.

This next example is the same as the previous except that instead of 
{{maxErrors=-1}} the request param is now {{maxErrors=1}}...

{code}
$ curl 
'http://localhost:8983/solr/techproducts/update?update.chain=tolerant-chain=json=true=1'
 -H "Content-Type: application/json" --data-binary '{"add" : { 
"doc":{"id":"1","foo_i":"bogus"}}, "delete": {"query":"malformed:["}}'
{
  "responseHeader":{
"errors":[{
"type":"ADD",
"id":"1",
"message":"ERROR: [doc=1] Error adding field 'foo_i'='bogus' msg=For 
input string: \"bogus\""},
  {
"type":"DELQ",
"id":"malformed:[",
"message":"org.apache.solr.search.SyntaxError: Cannot parse 
'malformed:[': Encountered \"\" at line 1, column 11.\nWas expecting one 
of:\n ...\n ...\n"}],
"maxErrors":1,
"status":400,
"QTime":1},
  "error":{
"metadata":[
  "org.apache.solr.common.ToleratedUpdateError--ADD:1","ERROR: [doc=1] 
Error adding field 'foo_i'='bogus' msg=For input string: \"bogus\"",
  
"org.apache.solr.common.ToleratedUpdateError--DELQ:malformed:[","org.apache.solr.search.SyntaxError:
 Cannot parse 'malformed:[': Encountered \"\" at line 1, column 11.\nWas 
expecting one of:\n ...\n ...\n",
  "error-class","org.apache.solr.common.SolrException",
  "root-error-class","java.lang.NumberFormatException"],
"msg":"ERROR: [doc=1] Error adding field 'foo_i'='bogus' msg=For input 
string: \"bogus\"",
"code":400}}
{code}

...the added exception metadata ensures that even in client code like the 
various SolrJ SolrClient implementations, which throw a (client side) exception 
on non-200 responses, the end user can access info on all the tolerated errors 
that were ignored before the maxErrors threshold was reached.

CloudSolrClient in particular -- which already has logic to split 
{{UpdateRequests}}; route individual commands to the appropraite leaders; and 
merge the responses -- has been updated to handle merging these responses as 
well.

(The {{ToleratedUpdateError}} class for modeling these types of errors has been 
added to solr-common, and has static utilities that client code can use to 
parse the data out of the responseHeader or out of any client side 
SolrException metadata)



There are still a bunch of {{nocommit}} comments, but they are almost all 
related to either:
* adding tests
* adding docs
* refactoring / hardening some internal APIs
* removing suspected unneccessary "isLeader" code (once tests are final)

I'll keep working on those, but I'd appreciate feedback from folks on how 
things currently stand.

Even if you don't understand/care about the internals, thoughts on the user 
facing API would be appreciated.


> Update Handlers abort with bad documents
> 
>
> Key: SOLR-445
> URL: https://issues.apache.org/jira/browse/SOLR-445
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 1.3
>

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

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8082:


Probably related to SOLR-8838.

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



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

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

[jira] [Commented] (LUCENE-7099) add newDistanceSort to sandbox LatLonPoint

[ASF subversion and git services (JIRA)]

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

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

Commit ae866b01499a1474a2178749025c2c571b6a4777 in lucene-solr's branch 
refs/heads/branch_6x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ae866b0 ]

LUCENE-7099: improve test to exercise searchAfter


> add newDistanceSort to sandbox LatLonPoint
> --
>
> Key: LUCENE-7099
> URL: https://issues.apache.org/jira/browse/LUCENE-7099
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7099.patch
>
>
> This field does not support sorting by distance, which is a very common use 
> case. 
> We can add {{LatLonPoint.newDistanceSort(field, latitude, longitude)}} which 
> returns a suitable SortField. There are a lot of optimizations esp when e.g. 
> the priority queue gets full to avoid tons of haversin() computations.
> Also, we can make use of the SortedNumeric data to switch 
> newDistanceQuery/newPolygonQuery to the two-phase iterator api, so they 
> aren't doing haversin() calls on bkd leaf nodes. It should look a lot like 
> LUCENE-7019



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

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

RE: Solr in Linux Platform

[Adel Mohamed Khalifa]

I do that with the hostname ( “ 172.16.0.**:8983/solr/SearchCore “ ) and still 
the problem exist

 

Regards,
Adel Khalifa

 

From: Walter Underwood [mailto:wun...@wunderwood.org] 
Sent: Monday, March 14, 2016 5:36 PM
To: dev@lucene.apache.org
Subject: Re: Solr in Linux Platform

 

Use the hostname of the Ubuntu server instead of “localhost”. This URL will 
only connect to the same host where your client is running: 
localhost:8983/solr/SearchCore

 

wunder

Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

 

On Mar 14, 2016, at 8:12 AM, Shawn Heisey  wrote:

 

On 3/14/2016 8:31 AM, Adel Mohamed Khalifa wrote:



I build a website (Java EE ) and want to search in some json files so
I installed the solr server in an Ubuntu server and create a new core
then indexing json files and the web searched correctly when I moved
my code from windows to the server it stopped and cannot connect to
solr server I try to debug using netbeans in Ubuntu it’s stopped and
there is no exception on this statement (SolrServer server = new
HttpSolrServer(“localhost:8983/solr/SearchCore”) ).



I need for some help Please.



Note :- I attached the servlet I used to search and connect to solr
server.


Don't set the "wt" or "indent" parameters.  You won't be interacting
with the actual text of the response -- all response access with SolrJ
is through Java objects.  Changing wt might just confuse SolrJ -- let it
use its normal binary response format.

The gson/json code you've got probably isn't going to do what you
expect.  If the "wt" parameter did not break the request (which might
happen), then what you get with the getResults method on the response
object will NOT be any standardized format like gson or json.  You will
need to access the SolrDocument object(s) from the SolrDocumentList, and
then access fields from SolrDocument.

Thanks,
Shawn


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

 

[jira] [Commented] (LUCENE-7099) add newDistanceSort to sandbox LatLonPoint

[ASF subversion and git services (JIRA)]

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

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

Commit 80fe00ba18ac1f834028eb0064115a00bafe1f20 in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=80fe00b ]

LUCENE-7099: improve test to exercise searchAfter


> add newDistanceSort to sandbox LatLonPoint
> --
>
> Key: LUCENE-7099
> URL: https://issues.apache.org/jira/browse/LUCENE-7099
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7099.patch
>
>
> This field does not support sorting by distance, which is a very common use 
> case. 
> We can add {{LatLonPoint.newDistanceSort(field, latitude, longitude)}} which 
> returns a suitable SortField. There are a lot of optimizations esp when e.g. 
> the priority queue gets full to avoid tons of haversin() computations.
> Also, we can make use of the SortedNumeric data to switch 
> newDistanceQuery/newPolygonQuery to the two-phase iterator api, so they 
> aren't doing haversin() calls on bkd leaf nodes. It should look a lot like 
> LUCENE-7019



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

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

[jira] [Updated] (LUCENE-7091) Add doc values support to MemoryIndex

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen updated LUCENE-7091:
--
Attachment: LUCENE-7091.patch

Updated the patch.

bq. (still applies to the other addField): I think the javadocs sentence you 
added to addField meant to use "if" not "is".

Changed. 

bq. At first I thought there might have been a bug for double-applying the 
boost since I see you're still passing "boost" as a constructor argument to 
Info. But now I see you only apply when numTokens > 0. I think it would be much 
clearer (and simpler) to remove boost from the constructor to Info, and simply 
apply it in storeTerms (no matter what numTokens is). It's hard to judge the 
testDocValuesDoNotAffectBoostPositionsOrOffset for this problem... it'd get 
encoded in the norm and I have no idea what norm it should be; your test 
asserts -127. H. Perhaps simply leave a check of that nature to the test 
that asserts parity with the real index in RAMDirectory

Removed the boost constructor parameter and added a dedicated test for this in 
TestMemoryIndexAgainstRAMDir.

bq. in storeDocValues() SORTED_NUMERIC: you call ArrayUtil.grow with only the 
array. This results in the same O(N^2) we're trying to avoid! Pass in a second 
argument of the desired length.

Changed, the size is array doubled when growing is necessary.

> Add doc values support to MemoryIndex
> -
>
> Key: LUCENE-7091
> URL: https://issues.apache.org/jira/browse/LUCENE-7091
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Assignee: David Smiley
> Attachments: LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, 
> LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, 
> LUCENE-7091.patch
>
>
> Sometimes queries executed via the MemoryIndex require certain things to be 
> stored as doc values. Today this isn't possible because the memory index 
> doesn't support this and these queries silently return no results.



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

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

[jira] [Commented] (LUCENE-7091) Add doc values support to MemoryIndex

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen commented on LUCENE-7091:
---

Right, speed over memory, I'll change it to the doubling logic you initially 
suggested.

> Add doc values support to MemoryIndex
> -
>
> Key: LUCENE-7091
> URL: https://issues.apache.org/jira/browse/LUCENE-7091
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Assignee: David Smiley
> Attachments: LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, 
> LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch
>
>
> Sometimes queries executed via the MemoryIndex require certain things to be 
> stored as doc values. Today this isn't possible because the memory index 
> doesn't support this and these queries silently return no results.



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

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

[jira] [Assigned] (SOLR-8835) fix multi-valued numeric docvalues faceting

[Yonik Seeley (JIRA)]

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

Yonik Seeley reassigned SOLR-8835:
--

Assignee: Yonik Seeley

> fix multi-valued numeric docvalues faceting
> ---
>
> Key: SOLR-8835
> URL: https://issues.apache.org/jira/browse/SOLR-8835
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 6.0
>
> Attachments: SOLR-8835.patch
>
>
> The new facet module doesn't work with multi-valued numeric docValues fields.



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

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

[jira] [Commented] (LUCENE-7091) Add doc values support to MemoryIndex

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7091:
--

My main concern is that it not be O(N^2).  Personally I'm not too concerned 
with ArrayUtil.grow's algorithm.  You might also pick an initial size of 
something like '4' for the SORTED_NUMERIC case (since it implies the intent to 
add more than 1).  With MemoryIndex I think speed is generally more important 
than memory size any way.

> Add doc values support to MemoryIndex
> -
>
> Key: LUCENE-7091
> URL: https://issues.apache.org/jira/browse/LUCENE-7091
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Assignee: David Smiley
> Attachments: LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, 
> LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch
>
>
> Sometimes queries executed via the MemoryIndex require certain things to be 
> stored as doc values. Today this isn't possible because the memory index 
> doesn't support this and these queries silently return no results.



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

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

[jira] [Resolved] (SOLR-8835) fix multi-valued numeric docvalues faceting

[Yonik Seeley (JIRA)]

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

Yonik Seeley resolved SOLR-8835.

Resolution: Fixed

> fix multi-valued numeric docvalues faceting
> ---
>
> Key: SOLR-8835
> URL: https://issues.apache.org/jira/browse/SOLR-8835
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Reporter: Yonik Seeley
> Fix For: 6.0
>
> Attachments: SOLR-8835.patch
>
>
> The new facet module doesn't work with multi-valued numeric docValues fields.



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

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

[jira] [Commented] (SOLR-8835) fix multi-valued numeric docvalues faceting

[ASF subversion and git services (JIRA)]

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

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

Commit da4342c8e553e20c63410b97ce80cee367d0465e in lucene-solr's branch 
refs/heads/branch_6_0 from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=da4342c ]

SOLR-8835: fix faceting exception (uif) on multi-valued numeric docValues


> fix multi-valued numeric docvalues faceting
> ---
>
> Key: SOLR-8835
> URL: https://issues.apache.org/jira/browse/SOLR-8835
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Reporter: Yonik Seeley
> Fix For: 6.0
>
> Attachments: SOLR-8835.patch
>
>
> The new facet module doesn't work with multi-valued numeric docValues fields.



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

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

[jira] [Commented] (SOLR-8835) fix multi-valued numeric docvalues faceting

[ASF subversion and git services (JIRA)]

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

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

Commit 5d7592bc14c4a20cb365e4cc8515bee92eec1f6f in lucene-solr's branch 
refs/heads/branch_6x from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5d7592b ]

SOLR-8835: fix faceting exception (uif) on multi-valued numeric docValues


> fix multi-valued numeric docvalues faceting
> ---
>
> Key: SOLR-8835
> URL: https://issues.apache.org/jira/browse/SOLR-8835
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Reporter: Yonik Seeley
> Fix For: 6.0
>
> Attachments: SOLR-8835.patch
>
>
> The new facet module doesn't work with multi-valued numeric docValues fields.



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

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

Re: Solr in Linux Platform

[Walter Underwood]

Use the hostname of the Ubuntu server instead of “localhost”. This URL will 
only connect to the same host where your client is running: 
localhost:8983/solr/SearchCore

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Mar 14, 2016, at 8:12 AM, Shawn Heisey  wrote:
> 
> On 3/14/2016 8:31 AM, Adel Mohamed Khalifa wrote:
>> I build a website (Java EE ) and want to search in some json files so
>> I installed the solr server in an Ubuntu server and create a new core
>> then indexing json files and the web searched correctly when I moved
>> my code from windows to the server it stopped and cannot connect to
>> solr server I try to debug using netbeans in Ubuntu it’s stopped and
>> there is no exception on this statement (SolrServer server = new
>> HttpSolrServer(“localhost:8983/solr/SearchCore”) ).
>> 
>> 
>> 
>> I need for some help Please.
>> 
>> 
>> 
>> Note :- I attached the servlet I used to search and connect to solr
>> server.
>> 
> 
> Don't set the "wt" or "indent" parameters.  You won't be interacting
> with the actual text of the response -- all response access with SolrJ
> is through Java objects.  Changing wt might just confuse SolrJ -- let it
> use its normal binary response format.
> 
> The gson/json code you've got probably isn't going to do what you
> expect.  If the "wt" parameter did not break the request (which might
> happen), then what you get with the getResults method on the response
> object will NOT be any standardized format like gson or json.  You will
> need to access the SolrDocument object(s) from the SolrDocumentList, and
> then access fields from SolrDocument.
> 
> Thanks,
> Shawn
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

[jira] [Commented] (SOLR-8835) fix multi-valued numeric docvalues faceting

[ASF subversion and git services (JIRA)]

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

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

Commit 95f20c6f00966db0b16d3abeaf12a768da83366a in lucene-solr's branch 
refs/heads/master from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=95f20c6 ]

SOLR-8835: fix faceting exception (uif) on multi-valued numeric docValues


> fix multi-valued numeric docvalues faceting
> ---
>
> Key: SOLR-8835
> URL: https://issues.apache.org/jira/browse/SOLR-8835
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Reporter: Yonik Seeley
> Fix For: 6.0
>
> Attachments: SOLR-8835.patch
>
>
> The new facet module doesn't work with multi-valued numeric docValues fields.



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

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

[jira] [Commented] (LUCENE-7091) Add doc values support to MemoryIndex

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen commented on LUCENE-7091:
---

> in storeDocValues() SORTED_NUMERIC: you call ArrayUtil.grow with only the 
> array. This results in the same O(N^2) we're trying to avoid! Pass in a 
> second argument of the desired length.

Maybe I was a bit concerned about the size of these arrays. 
ArrayUtil.grow(array) grows an array by an 1/8th and at least adds 3 additional 
slots, I thought that would be enough, since we don't know upfront how many new 
values are going to be added. I can change it double the array instead.

> Add doc values support to MemoryIndex
> -
>
> Key: LUCENE-7091
> URL: https://issues.apache.org/jira/browse/LUCENE-7091
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Assignee: David Smiley
> Attachments: LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, 
> LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch, LUCENE-7091.patch
>
>
> Sometimes queries executed via the MemoryIndex require certain things to be 
> stored as doc values. Today this isn't possible because the memory index 
> doesn't support this and these queries silently return no results.



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

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

[jira] [Closed] (SOLR-8687) Race condition with RTGs during soft commit

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya closed SOLR-8687.
--
Resolution: Invalid

I realized that there is no race condition. What I was seeing was a condition 
whereby the searcher was opening fine before the RTG call, just that the update 
which I was sure should've been in the searcher was not (it was a DV update, as 
per work done in SOLR-5944). Sorry for the noise.

> Race condition with RTGs during soft commit
> ---
>
> Key: SOLR-8687
> URL: https://issues.apache.org/jira/browse/SOLR-8687
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>
> I am facing a problem with stress testing SOLR-5944, even though I think this 
> problem persists in Solr even without my changes.
> The symptom is that during a stress test (similar to TestStressReorder), RTG 
> gets a document which is older version than that of the last acknowledged 
> write.
> Possible reason:
> {code}
> (DUH2's commit())
> ...
> 1:  if (cmd.softCommit) {
> 2:// ulog.preSoftCommit();
> 3:synchronized (solrCoreState.getUpdateLock()) {
> 4:  if (ulog != null) ulog.preSoftCommit(cmd);
> 5:  core.getSearcher(true, false, waitSearcher, true);
> 6:  if (ulog != null) ulog.postSoftCommit(cmd);
> 7:}
> 8:callPostSoftCommitCallbacks();
> 9:  }
> ...
> {code}
> * Before line 1, there was an update (say id=2) which was in ulog's map. Maps 
> are, say, map=\{2=LogPtr(1234)\} , prevMap=\{...\} , prevMap2=\{...\}
> * Due to line 4 (ulog.preSoftCommit()), the maps were rotated. Now, the id=2 
> is in prevMap: map={}, prevMap=\{2=LogPtr(1234)\}, prevMap2=\{...\} . Till 
> now RTG for id=2 will work.
> * Due to line 5, a new searcher is due to be opened. But this is 
> asynchronous, and lets assume this doesn't complete before few more lines are 
> executed.
> * Due to line 6 (ulog.postSoftCommit()), the previous maps are cleared out. 
> Now the maps are: map={}, prevMap=null, prevMap2=null
> * If there's an RTG for id=2, it will not work from the ulog's maps, so it 
> will fall through to be searched using the last searcher. But, the searcher 
> due to be opened in line 5 hasn't yet been opened. In this case, the returned 
> document will be whatever version of id=2 that was present in the previous 
> searcher.
> Can someone please confirm if this is a potential problem? If so, any 
> suggestions for a fix, please? I tried opening a ulog.openRealtimeSearcher() 
> in the above synchronized block, but the problem still persists, but I 
> haven't looked into why that could be.



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

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

[jira] [Updated] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-5944:
---
Attachment: SOLR-5944.patch

Updated the patch to trunk with the following:
1. Some bug fixes.
2. Stress test.
3. Some cleanups.
4. Fixed nocommits.

[~noble.paul], [~yo...@apache.org], could you please review? Thanks.

There is one very very rare situation whereby after a commit the recently 
reopened searcher doesn't see a dv update which was supposed to be in this 
newly opened searcher. There maybe some issue in having the updates flushed 
properly at the Lucene level; I have so far been unable to reproduce this 
during one off plain Lucene tests or Solr tests, but it is exposed only during 
the Stress tests (once in 2000 runs or so). I'll continue to investigate this, 
perhaps by writing a similar stress test for plain Lucene level DV updates. 
Apart from that, I think this patch is feature complete.

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



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

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