[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 7 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/7/

4 tests failed.
FAILED:  org.apache.solr.search.mlt.CloudMLTQParserTest.test

Error Message:
arrays first differed at element [1]; expected:<13> but was:<14>

Stack Trace:
arrays first differed at element [1]; expected:<13> but was:<14>
at 
__randomizedtesting.SeedInfo.seed([AB0843BA6576E38:82E4BBE108AB03C0]:0)
at 
org.junit.internal.ComparisonCriteria.arrayEquals(ComparisonCriteria.java:52)
at org.junit.Assert.internalArrayEquals(Assert.java:416)
at org.junit.Assert.assertArrayEquals(Assert.java:292)
at org.junit.Assert.assertArrayEquals(Assert.java:305)
at 
org.apache.solr.search.mlt.CloudMLTQParserTest.test(CloudMLTQParserTest.java:112)
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 
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 

[jira] [Commented] (LUCENE-7087) Change MemoryIndex#fromDocument(...) helpers to accept Iterable as document

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7087:
--

Can you make it {{Iterable}} instead (like 
IndexWriter) so that it is fine to pass eg. a {{List}}.

> Change MemoryIndex#fromDocument(...) helpers to accept 
> Iterable as document
> ---
>
> Key: LUCENE-7087
> URL: https://issues.apache.org/jira/browse/LUCENE-7087
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
> Attachments: LUCENE_7087.patch
>
>




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

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

[jira] [Updated] (LUCENE-7090) Add single-valued points support to fieldcache

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7090:

Attachment: LUCENE-7090.patch

updated patch with more progress. unrelated to this issue, we should really fix 
the thread-safety test, i think its a no-op? It doesn't seem to be doing any 
actual uninverting.


> Add single-valued points support to fieldcache
> --
>
> Key: LUCENE-7090
> URL: https://issues.apache.org/jira/browse/LUCENE-7090
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7090.patch, LUCENE-7090.patch
>
>
> This is a big user of the deprecated encoding (LUCENE-7075). Also it is a 
> step to help migrate stuff like spatial-extras away from it too.



--
This message was sent by Atlassian 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-7081) Docvalues terms dict should sometimes prefix-compress fixed-length data.

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7081:
--

+1

> Docvalues terms dict should sometimes prefix-compress fixed-length data.
> 
>
> Key: LUCENE-7081
> URL: https://issues.apache.org/jira/browse/LUCENE-7081
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7081.patch
>
>
> For Sorted/SortedSet types, we encode ordinals and a term dictionary (similar 
> to old lucene 3 term dictionary).
> Originally we had no prefix compression, so we "save space" in the 
> fixed-width case by avoiding addressing, we can just use multiplication: 
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/codecs/lucene54/Lucene54DocValuesConsumer.java#L423-L425
>  
> But it means no compression whatsoever of the actual bytes, even if values 
> are enormous, I don't think its necessarily a good tradeoff. The lack of 
> prefix compression can become much more magnified now that we have fixed 
> width 128-bit point types in the sandbox...



--
This message was sent by Atlassian 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-7090) Add single-valued points support to fieldcache

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7090:

Attachment: LUCENE-7090.patch

Patch. I ported a good deal of the tests. If they were testing anything 
particular about numeric types, i kept the legacy version too. Separately there 
is still some cleanup to be done on the tests: I didn't port 100% of them yet 
(esp. dodging SlowMultiWrapper at every turn).

We can followup with multi-valued in another issue, this is already big enough 
at once.

> Add single-valued points support to fieldcache
> --
>
> Key: LUCENE-7090
> URL: https://issues.apache.org/jira/browse/LUCENE-7090
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7090.patch
>
>
> This is a big user of the deprecated encoding (LUCENE-7075). Also it is a 
> step to help migrate stuff like spatial-extras away from it too.



--
This message was sent by Atlassian 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-8097) Implement a builder pattern for constructing a Solrj client

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8097:


Thanks Jason. Looks good overall.

* Change maybeCreateHttpSolrClientWithBuilder to getNewSolrClient() ? 'maybe' 
makes it sound like a client may/may not be created. Also, with a method called 
getNewSolrClient(), we could just change it to always construct a new client 
object using the new design, without having to rename the method to a 
non-maybe* pattern. Also, we passing the 'random()' isn't really required.
* Deprecation to the non-builder calls. Ideally, we should move the builder 
classes to be static inner classes for the existing Client implementations. 
Then we could switch everything to private and leave out the Builder exposed 
when we want to remove the builder, rather than moving the code around.
* CUSC, and HttpSolrClient changes are unrelated
* Do you plan on adding more tests to ConcurrentUpdateSolrClientBuilderTest ?
* There are a few unused imports, we can clean them out before committing.

bq.  I'm happy to move this in either direction (remove the 
random-client-creation changes vs. expanding the changes to encompass other 
SolrClient types)
Let's have a getter for randomizing client creation, while keeping the concept 
of randomizing transparent i.e. the calling code doesn't ever know when we 
randomize. Also, let's have other clients covered too.

I'll create a sub-task so we don't forget that we intend to rename 
updatesToLeaders to preferLeaders. Feel free to create sub-tasks for everything 
that you think is related but doesn't need to go with this.

> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Hrishikesh Gadre
>Assignee: Anshum Gupta
>Priority: Minor
> Attachments: SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, 
> SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, 
> SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need to introduce additional constructors). Instead it will be helpful to 
> provide SolrClient Builder which can provide either default values or support 
> overriding specific parameter. 



--
This message was sent by Atlassian 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-7090) Add single-valued points support to fieldcache

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7090:
---

 Summary: Add single-valued points support to fieldcache
 Key: LUCENE-7090
 URL: https://issues.apache.org/jira/browse/LUCENE-7090
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


This is a big user of the deprecated encoding (LUCENE-7075). Also it is a step 
to help migrate stuff like spatial-extras away from it too.



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+107) - Build # 79 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/79/
Java: 64bit/jdk-9-ea+107 -XX:+UseCompressedOops -XX:+UseG1GC

85 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.search.TestControlledRealTimeReopenThread

Error Message:
Captured an uncaught exception in thread: Thread[id=1349, name=NRTDeletes 
Reopen Thread, state=RUNNABLE, group=TGRP-TestControlledRealTimeReopenThread]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=1349, name=NRTDeletes Reopen Thread, 
state=RUNNABLE, group=TGRP-TestControlledRealTimeReopenThread]
Caused by: java.lang.RuntimeException: java.io.IOException: Unable to unmap the 
mapped buffer: 
MMapIndexInput(path="/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/core/test/J0/temp/lucene.search.TestControlledRealTimeReopenThread_F870A3626EA6FA78-001/TestControlledRealTimeReopenThread-001/_0.fnm")
at __randomizedtesting.SeedInfo.seed([F870A3626EA6FA78]:0)
at 
org.apache.lucene.search.ControlledRealTimeReopenThread.run(ControlledRealTimeReopenThread.java:247)
Caused by: java.io.IOException: Unable to unmap the mapped buffer: 
MMapIndexInput(path="/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/core/test/J0/temp/lucene.search.TestControlledRealTimeReopenThread_F870A3626EA6FA78-001/TestControlledRealTimeReopenThread-001/_0.fnm")
at 
org.apache.lucene.store.MMapDirectory.lambda$unmapHackImpl$1(MMapDirectory.java:384)
at 
org.apache.lucene.store.ByteBufferIndexInput.freeBuffer(ByteBufferIndexInput.java:376)
at 
org.apache.lucene.store.ByteBufferIndexInput.close(ByteBufferIndexInput.java:355)
at 
org.apache.lucene.util.LuceneTestCase.slowFileExists(LuceneTestCase.java:2695)
at 
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:737)
at 
org.apache.lucene.store.Directory.openChecksumInput(Directory.java:113)
at 
org.apache.lucene.store.MockDirectoryWrapper.openChecksumInput(MockDirectoryWrapper.java:1060)
at 
org.apache.lucene.codecs.lucene60.Lucene60FieldInfosFormat.read(Lucene60FieldInfosFormat.java:113)
at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:101)
at org.apache.lucene.index.SegmentReader.(SegmentReader.java:66)
at 
org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:145)
at 
org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:197)
at 
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:102)
at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:444)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenFromWriter(StandardDirectoryReader.java:291)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:266)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:256)
at 
org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:140)
at 
org.apache.lucene.search.SearcherManager.refreshIfNeeded(SearcherManager.java:156)
at 
org.apache.lucene.search.SearcherManager.refreshIfNeeded(SearcherManager.java:58)
at 
org.apache.lucene.search.ReferenceManager.doMaybeRefresh(ReferenceManager.java:176)
at 
org.apache.lucene.search.ReferenceManager.maybeRefreshBlocking(ReferenceManager.java:253)
at 
org.apache.lucene.search.ControlledRealTimeReopenThread.run(ControlledRealTimeReopenThread.java:245)
Caused by: java.lang.IncompatibleClassChangeError: Found class 
jdk.internal.ref.Cleaner, but interface was expected
at 
org.apache.lucene.store.MMapDirectory.lambda$unmapHackImpl$0(MMapDirectory.java:377)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.lucene.store.MMapDirectory.lambda$unmapHackImpl$1(MMapDirectory.java:375)
... 22 more


FAILED:  
org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat.testDocsAndFreqsAndPositionsAndPayloads

Error Message:
Unable to unmap the mapped buffer: 
MMapIndexInput(path="/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/core/test/J0/temp/lucene.codecs.lucene50.TestBlockPostingsFormat_F870A3626EA6FA78-001/testPostingsFormat.testExact-001/_0_Lucene50_0.doc")

Stack Trace:
java.io.IOException: Unable to unmap the mapped buffer: 
MMapIndexInput(path="/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/core/test/J0/temp/lucene.codecs.lucene50.TestBlockPostingsFormat_F870A3626EA6FA78-001/testPostingsFormat.testExact-001/_0_Lucene50_0.doc")
at 
__randomizedtesting.SeedInfo.seed([F870A3626EA6FA78:4ED0A2D456453DEE]:0)
at 
org.apache.lucene.store.MMapDirectory.lambda$unmapHackImpl$1(MMapDirectory.java:384)
at 
org.apache.lucene.store.ByteBufferIndexInput.freeBuffer(ByteBufferIndexInput.java:376)
   

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

[Policeman Jenkins Server]

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

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

Error Message:
Captured an uncaught exception in thread: Thread[id=7868, 
name=testExecutor-3878-thread-9, state=RUNNABLE, 
group=TGRP-UnloadDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=7868, name=testExecutor-3878-thread-9, 
state=RUNNABLE, group=TGRP-UnloadDistributedZkTest]
at 
__randomizedtesting.SeedInfo.seed([5D99F5D8EE2EE259:D5CDCA0240D28FA1]: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:51560
at __randomizedtesting.SeedInfo.seed([5D99F5D8EE2EE259]: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:51560
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 11311 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_5D99F5D8EE2EE259-001/init-core-data-001
   [junit4]   2> 781663 INFO  
(SUITE-UnloadDistributedZkTest-seed#[5D99F5D8EE2EE259]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 781666 INFO  
(TEST-UnloadDistributedZkTest.test-seed#[5D99F5D8EE2EE259]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 781666 INFO  (Thread-2500) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   

[jira] [Commented] (SOLR-6622) Issue with Multivalued fields when using UIMA

[Srinivasarao (JIRA)]

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

Srinivasarao commented on SOLR-6622:


Here's the issue I'm having.

http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201603.mbox/%3CCADvZL4qaWsBv%3DrX6Bu%3DtFtJMd1p50RU-wHhCrCQqeuKSEJj6YQ%40mail.gmail.com%3E

> Issue with Multivalued fields when using UIMA
> -
>
> Key: SOLR-6622
> URL: https://issues.apache.org/jira/browse/SOLR-6622
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - UIMA
>Affects Versions: master
>Reporter: Maryam Khordad
>Assignee: Tommaso Teofili
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-6622.patch
>
>
> When using any of UIMA addons on a multivalued fields, only the first row of 
> the field gets processed and UIMA update ignores the remaining rows. 
> This bug caused by "getTextsToAnalyze" method in "UIMAUpdateRequestProcessor" 
> class. SolrInputDocument
> .getFieldValue  must be changes to olrInputDocument
> .getFieldValues and the result must be an array not a single 
> variable.



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+107) - Build # 78 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/78/
Java: 64bit/jdk-9-ea+107 -XX:-UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.morphlines.solr.SolrMorphlineZkAvroTest

Error Message:
8 threads leaked from SUITE scope at 
org.apache.solr.morphlines.solr.SolrMorphlineZkAvroTest: 1) Thread[id=160, 
name=zkCallback-30-thread-1, state=TIMED_WAITING, 
group=TGRP-SolrMorphlineZkAvroTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1082)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)2) Thread[id=158, 
name=TEST-SolrMorphlineZkAvroTest.test-seed#[73FF2460CEF848FB]-SendThread(127.0.0.1:58011),
 state=TIMED_WAITING, group=TGRP-SolrMorphlineZkAvroTest] at 
java.lang.Thread.sleep(Native Method) at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101)
 at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:940)
 at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1003)
3) Thread[id=161, name=CloudSolrClient ThreadPool-29-thread-1, 
state=TIMED_WAITING, group=TGRP-SolrMorphlineZkAvroTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1082)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)4) Thread[id=162, 
name=CloudSolrClient ThreadPool-29-thread-2, state=TIMED_WAITING, 
group=TGRP-SolrMorphlineZkAvroTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1082)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)5) Thread[id=193, 
name=zkCallback-30-thread-2, state=TIMED_WAITING, 
group=TGRP-SolrMorphlineZkAvroTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1082)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)6) Thread[id=194, 
name=zkCallback-30-thread-3, state=TIMED_WAITING, 
group=TGRP-SolrMorphlineZkAvroTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1082)   
  at 

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

[Policeman Jenkins Server]

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

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

Error Message:
Captured an uncaught exception in thread: Thread[id=4281, 
name=testExecutor-2050-thread-10, state=RUNNABLE, 
group=TGRP-UnloadDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=4281, name=testExecutor-2050-thread-10, 
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:58292
at __randomizedtesting.SeedInfo.seed([44706FA6581A3D06]: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:58292
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 11051 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_44706FA6581A3D06-001/init-core-data-001
   [junit4]   2> 536978 INFO  
(SUITE-UnloadDistributedZkTest-seed#[44706FA6581A3D06]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 536981 INFO  
(TEST-UnloadDistributedZkTest.test-seed#[44706FA6581A3D06]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 536981 INFO  (Thread-1382) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 536981 INFO  (Thread-1382) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]  

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testAll

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([CD0907A6FF1836DF:815729DF8488691A]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDaemonStream(StreamExpressionTest.java:658)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testAll(StreamExpressionTest.java:141)
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 
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 

[jira] [Commented] (SOLR-1833) ShowFileRequestHandle should allow you to specify which files can be viewed, not just which cannot be viewed

[JIRA]

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

Raphaël Droz commented on SOLR-1833:


What kept the patch from being reviewed/pushed?

> ShowFileRequestHandle should allow you to specify which files can be viewed, 
> not just which cannot be viewed
> 
>
> Key: SOLR-1833
> URL: https://issues.apache.org/jira/browse/SOLR-1833
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Mark Miller
>Priority: Minor
> Fix For: 4.9, master
>
> Attachments: SOLR-1833-ShowFileRequestHandler-whitelist.patch
>
>
> In many cases I wouldn't want to come up with every file I want hidden - 
> especially when new files may be added in the future - often you would want 
> to explicitly say which files can be viewed - this is how the old 
> gettableFiles used to work.



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

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testAll

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([CC44AA16A1AB0665:801A846FDA3B59A0]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDaemonStream(StreamExpressionTest.java:658)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testAll(StreamExpressionTest.java:141)
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 
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 

[jira] [Resolved] (LUCENE-7089) Add points support to flexible queryparser to replace legacy numerics support.

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-7089.
-
   Resolution: Fixed
Fix Version/s: 6.0
   master

> Add points support to flexible queryparser to replace legacy numerics support.
> --
>
> Key: LUCENE-7089
> URL: https://issues.apache.org/jira/browse/LUCENE-7089
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: master, 6.0
>
> Attachments: LUCENE-7089.patch
>
>
> This adds 1D point ranges/terms, the exact same way legacy numerics works 
> (and marks all their classes deprecated). 



--
This message was sent by Atlassian 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-7089) Add points support to flexible queryparser to replace legacy numerics support.

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7089, LUCENE-7075: add points to flexible queryparser to replace legacy 
numerics support


> Add points support to flexible queryparser to replace legacy numerics support.
> --
>
> Key: LUCENE-7089
> URL: https://issues.apache.org/jira/browse/LUCENE-7089
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: master, 6.0
>
> Attachments: LUCENE-7089.patch
>
>
> This adds 1D point ranges/terms, the exact same way legacy numerics works 
> (and marks all their classes deprecated). 



--
This message was sent by Atlassian 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-7075) Clean up LegacyNumericUtils usage.

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7089, LUCENE-7075: add points to flexible queryparser to replace legacy 
numerics support


> Clean up LegacyNumericUtils usage.
> --
>
> Key: LUCENE-7075
> URL: https://issues.apache.org/jira/browse/LUCENE-7075
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>
> Tons of code is still on the deprecated LegacyNumericUtils. We will never be 
> able to remove these or even move them to somewhere better (like the 
> backwards jar) if we don't clean this 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] (LUCENE-7089) Add points support to flexible queryparser to replace legacy numerics support.

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7089, LUCENE-7075: add points to flexible queryparser to replace legacy 
numerics support


> Add points support to flexible queryparser to replace legacy numerics support.
> --
>
> Key: LUCENE-7089
> URL: https://issues.apache.org/jira/browse/LUCENE-7089
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7089.patch
>
>
> This adds 1D point ranges/terms, the exact same way legacy numerics works 
> (and marks all their classes deprecated). 



--
This message was sent by Atlassian 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-7075) Clean up LegacyNumericUtils usage.

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7089, LUCENE-7075: add points to flexible queryparser to replace legacy 
numerics support


> Clean up LegacyNumericUtils usage.
> --
>
> Key: LUCENE-7075
> URL: https://issues.apache.org/jira/browse/LUCENE-7075
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>
> Tons of code is still on the deprecated LegacyNumericUtils. We will never be 
> able to remove these or even move them to somewhere better (like the 
> backwards jar) if we don't clean this 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] (LUCENE-7089) Add points support to flexible queryparser to replace legacy numerics support.

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7089, LUCENE-7075: add points to flexible queryparser to replace legacy 
numerics support


> Add points support to flexible queryparser to replace legacy numerics support.
> --
>
> Key: LUCENE-7089
> URL: https://issues.apache.org/jira/browse/LUCENE-7089
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7089.patch
>
>
> This adds 1D point ranges/terms, the exact same way legacy numerics works 
> (and marks all their classes deprecated). 



--
This message was sent by Atlassian 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-7075) Clean up LegacyNumericUtils usage.

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7089, LUCENE-7075: add points to flexible queryparser to replace legacy 
numerics support


> Clean up LegacyNumericUtils usage.
> --
>
> Key: LUCENE-7075
> URL: https://issues.apache.org/jira/browse/LUCENE-7075
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>
> Tons of code is still on the deprecated LegacyNumericUtils. We will never be 
> able to remove these or even move them to somewhere better (like the 
> backwards jar) if we don't clean this 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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+107) - Build # 16160 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16160/
Java: 64bit/jdk-9-ea+107 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.lucene.search.TestFieldCacheRewriteMethod.testRegexps

Error Message:
5

Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: 5
at 
__randomizedtesting.SeedInfo.seed([E47908F07C32B503:52549E1A298E28B]:0)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:466)
at org.apache.lucene.search.RegexpQuery.(RegexpQuery.java:109)
at org.apache.lucene.search.RegexpQuery.(RegexpQuery.java:79)
at 
org.apache.lucene.search.TestFieldCacheRewriteMethod.assertSame(TestFieldCacheRewriteMethod.java:33)
at 
org.apache.lucene.search.TestRegexpRandom2.testRegexps(TestRegexpRandom2.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
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 
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:804)




Build Log:
[...truncated 970 lines...]
   [junit4] Suite: org.apache.lucene.search.TestFieldCacheRewriteMethod
   [junit4]   2> NOTE: reproduce with: ant test  

[jira] [Commented] (SOLR-8812) ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND

[Ryan Steinberg (JIRA)]

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

Ryan Steinberg commented on SOLR-8812:
--

I agree: SOLR-2649 likely introduced this new behavior. I just read through the 
comments on SOLR-2649 and I'm still not sure this was intended: effectively, 
explicit OR is no longer possible when q.op=AND, even in the absence of an 
explicit mm param. After reading this [helpful blog 
post|https://lucidworks.com/blog/2011/12/28/why-not-and-or-and-not/] referenced 
in the ExtendedDismaxQParser unit test, I now understand that AND takes 
precedence over OR but I'm not sure this is a clearly documented or anticipated 
consequence of this recent change.

> ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND
> 
>
> Key: SOLR-8812
> URL: https://issues.apache.org/jira/browse/SOLR-8812
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 5.5
>Reporter: Ryan Steinberg
>
> The edismax parser ignores Boolean OR in queries when q.op=AND. This behavior 
> is new to Solr 5.5.0 and an unexpected major change.
> Example:
>   "q": "id:12345 OR zz",
>   "defType": "edismax",
>   "q.op": "AND",
> where "12345" is a known document ID and "zz" is a string NOT present 
> in my data
> Version 5.5.0 produces zero results:
> "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+((id:12345 
> DisjunctionMaxQuery((text:zz)))~2))/no_coord",
> "parsedquery_toString": "+((id:12345 (text:zz))~2)",
> "explain": {},
> "QParser": "ExtendedDismaxQParser"
> Version 5.4.0 produces one result as expected
>   "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+(id:12345 
> DisjunctionMaxQuery((text:zz/no_coord",
> "parsedquery_toString": "+(id:12345 (text:zz))"
> "explain": {},
> "QParser": "ExtendedDismaxQParser"



--
This message was sent by Atlassian 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-8765) Enforce required parameters in SolrJ Collection APIs

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski edited comment on SOLR-8765 at 3/10/16 1:15 AM:


IMO, Id rather have {{SolrIdentifierValidator}} return boolean than 
SolrException. SolrException is intended to be used on the server side, as it 
can be converted into a status code. That aspect of the exception doesn't make 
a ton of sense being used on the client/Solr J side.

(Disclaimer, when I first wrote SolrIdentifierValidator, I had it throwing 
SolrException. I was then converted after talking to Anshum about the downsides 
of using it client-side)


was (Author: gerlowskija):
IMO, Id rather have {{SolrIdentifierValidator}} throw IAE than SolrException. 
SolrException is intended to be used on the server side, as it can be converted 
into a status code. That aspect of the exception doesn't make a ton of sense 
being used on the client/Solr J side.

(Disclaimer, when I first wrote SolrIdentifierValidator, I had it throwing 
SolrException. I was then converted after talking to Anshum about the downsides 
of using it client-side)

> Enforce required parameters in SolrJ Collection APIs
> 
>
> Key: SOLR-8765
> URL: https://issues.apache.org/jira/browse/SOLR-8765
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.1
>
> Attachments: SOLR-8765.patch, SOLR-8765.patch
>
>
> Several Collection API commands have required parameters.  We should make 
> these constructor parameters, to enforce setting these in the API.



--
This message was sent by Atlassian 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-8765) Enforce required parameters in SolrJ Collection APIs

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8765:


[~romseygeek] Having the validator return a boolean value seem much better to 
me than to return the input value in case of successful validation. What was 
the reason behind changing that behavior.

> Enforce required parameters in SolrJ Collection APIs
> 
>
> Key: SOLR-8765
> URL: https://issues.apache.org/jira/browse/SOLR-8765
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.1
>
> Attachments: SOLR-8765.patch, SOLR-8765.patch
>
>
> Several Collection API commands have required parameters.  We should make 
> these constructor parameters, to enforce setting these in the API.



--
This message was sent by Atlassian 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-8765) Enforce required parameters in SolrJ Collection APIs

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski edited comment on SOLR-8765 at 3/10/16 12:57 AM:
-

IMO, Id rather have {{SolrIdentifierValidator}} throw IAE than SolrException. 
SolrException is intended to be used on the server side, as it can be converted 
into a status code. That aspect of the exception doesn't make a ton of sense 
being used on the client/Solr J side.

(Disclaimer, when I first wrote SolrIdentifierValidator, I had it throwing 
SolrException. I was then converted after talking to Anshum about the downsides 
of using it client-side)


was (Author: gerlowskija):
IMO, Id rather have {{SolrIdentifierValidator}} throw NAE than SolrException. 
SolrException is intended to be used on the server side, as it can be converted 
into a status code. That aspect of the exception doesn't make a ton of sense 
being used on the client/Solr J side.

(Disclaimer, when I first wrote SolrIdentifierValidator, I had it throwing 
SolrException. I was then converted after talking to Anshum about the downsides 
of using it client-side)

> Enforce required parameters in SolrJ Collection APIs
> 
>
> Key: SOLR-8765
> URL: https://issues.apache.org/jira/browse/SOLR-8765
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.1
>
> Attachments: SOLR-8765.patch, SOLR-8765.patch
>
>
> Several Collection API commands have required parameters.  We should make 
> these constructor parameters, to enforce setting these in the API.



--
This message was sent by Atlassian 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-8765) Enforce required parameters in SolrJ Collection APIs

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-8765:
---

IMO, Id rather have {{SolrIdentifierValidator}} throw NAE than SolrException. 
SolrException is intended to be used on the server side, as it can be converted 
into a status code. That aspect of the exception doesn't make a ton of sense 
being used on the client/Solr J side.

(Disclaimer, when I first wrote SolrIdentifierValidator, I had it throwing 
SolrException. I was then converted after talking to Anshum about the downsides 
of using it client-side)

> Enforce required parameters in SolrJ Collection APIs
> 
>
> Key: SOLR-8765
> URL: https://issues.apache.org/jira/browse/SOLR-8765
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.1
>
> Attachments: SOLR-8765.patch, SOLR-8765.patch
>
>
> Several Collection API commands have required parameters.  We should make 
> these constructor parameters, to enforce setting these in the API.



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+107) - Build # 16159 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16159/
Java: 64bit/jdk-9-ea+107 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=6972, 
name=testExecutor-3240-thread-3, state=RUNNABLE, 
group=TGRP-UnloadDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=6972, name=testExecutor-3240-thread-3, 
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:34355
at __randomizedtesting.SeedInfo.seed([8E03B324D2520CA2]: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:1158)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632)
at java.lang.Thread.run(Thread.java:804)
Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occured 
while waiting response from server at: http://127.0.0.1:34355
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 11298 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_8E03B324D2520CA2-001/init-core-data-001
   [junit4]   2> 823702 INFO  
(SUITE-UnloadDistributedZkTest-seed#[8E03B324D2520CA2]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 823703 INFO  
(TEST-UnloadDistributedZkTest.test-seed#[8E03B324D2520CA2]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 823704 INFO  (Thread-2384) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 823704 INFO  (Thread-2384) [] o.a.s.c.ZkTestServer 
Starting 

[jira] [Updated] (SOLR-8814) Support GeoJSON response format

[Ryan McKinley (JIRA)]

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

Ryan McKinley updated SOLR-8814:

Attachment: SOLR-8814-add-GeoJSONResponseWriter.patch

updated patch... also check:
https://github.com/ryantxu/lucene-solr/tree/with_geojson

> Support GeoJSON response format
> ---
>
> Key: SOLR-8814
> URL: https://issues.apache.org/jira/browse/SOLR-8814
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Reporter: Ryan McKinley
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8814-add-GeoJSONResponseWriter.patch, 
> SOLR-8814-add-GeoJSONResponseWriter.patch
>
>
> With minor changes, we can modify the existing JSON writer to produce a 
> GeoJSON `FeatureCollection` for ever SolrDocumentList.  We can then pick a 
> field to use as the geometry type, and use that for the Feature#geometry
> {code}
> "response":{"type":"FeatureCollection","numFound":1,"start":0,"features":[
>   {"type":"Feature",
> "geometry":{"type":"Point","coordinates":[1,2]},
> "properties":{
>   ... the normal solr doc fields here ...}}]
>   }}
> {code}
> This will allow adding solr results directly to various mapping clients like 
> [Leaflet|http://leafletjs.com/]
> 
> This patch will work with Documents that have a spatial field the either:
> 1. Extends AbstractSpatialFieldType
> 2. has a stored value with geojson
> 2. has a stored value that can be parsed by spatial4j (WKT, etc)
> The spatial field is identified with the parameter `geojson.field`



--
This message was sent by Atlassian 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-3990) index size unavailable in gui/mbeans unless replication handler configured

[Keith Laban (JIRA)]

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

Keith Laban updated SOLR-3990:
--
Attachment: SOLR-3990.patch

Bumping this ticket. Attaching a new patch for current master (should also 
apply to 5x)

> index size unavailable in gui/mbeans unless replication handler configured
> --
>
> Key: SOLR-3990
> URL: https://issues.apache.org/jira/browse/SOLR-3990
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 4.10, master
>
> Attachments: SOLR-3990.patch, SOLR-3990.patch
>
>
> Unless you configure the replication handler, the on-disk size of each core's 
> index seems to be unavailable in the gui or from the mbeans handler.  If you 
> are not doing replication, you should still be able to get the size of each 
> index without configuring things that won't be used.
> Also, I would like to get the size of the index in a consistent unit of 
> measurement, probably MB.  I understand the desire to give people a human 
> readable unit next to a number that's not enormous, but it's difficult to do 
> programmatic comparisons between values such as 787.33 MB and 23.56 GB.  That 
> may mean that the number needs to be available twice, one format to be shown 
> in the admin GUI and both formats available from the mbeans handler, for 
> scripting.



--
This message was sent by Atlassian 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-8677) SOLR allows creation of shards with invalid names.

[Anshum Gupta (JIRA)]

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

Anshum Gupta resolved SOLR-8677.

Resolution: Fixed

> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master, 6.0
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



--
This message was sent by Atlassian 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-8677) SOLR allows creation of shards with invalid names.

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8677:
---
Fix Version/s: 6.0

> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master, 6.0
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



--
This message was sent by Atlassian 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-8677) SOLR allows creation of shards with invalid names.

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8677:


Done

> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master, 6.0
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+107) - Build # 75 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/75/
Java: 64bit/jdk-9-ea+107 -XX:+UseCompressedOops -XX:+UseSerialGC

4 tests failed.
FAILED:  org.apache.lucene.search.TestFieldCacheRewriteMethod.testRegexps

Error Message:
Unequal lengths: hits1=2,hits2=0

Stack Trace:
junit.framework.AssertionFailedError: Unequal lengths: hits1=2,hits2=0
at 
__randomizedtesting.SeedInfo.seed([C0F9A55E66B76EF:ED53DB4438C12167]:0)
at junit.framework.Assert.fail(Assert.java:50)
at org.apache.lucene.search.CheckHits.checkEqual(CheckHits.java:211)
at 
org.apache.lucene.search.TestFieldCacheRewriteMethod.assertSame(TestFieldCacheRewriteMethod.java:42)
at 
org.apache.lucene.search.TestRegexpRandom2.testRegexps(TestRegexpRandom2.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
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 
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:804)


FAILED:  org.apache.lucene.search.TestRegexpRandom2.testRegexps

Error Message:
4

Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: 4
at 
__randomizedtesting.SeedInfo.seed([C0F9A55E66B76EF:ED53DB4438C12167]:0)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:515)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)

[jira] [Comment Edited] (SOLR-8807) NPE during spell checking when result collapsing is activated and index got more than one segment.

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8807 at 3/9/16 10:36 PM:
---

If you stop setting spellcheck.collateMaxCollectDocs it should turn off the 
early termination. Not sure if this will kill your performance, but it should 
make the NPE go away.


was (Author: joel.bernstein):
If you stop setting spellcheck.collateMaxCollectDocs it should turn off the 
early termination. Not if this will kill your performance, but it should make 
the NPE go away.

> NPE during spell checking when result collapsing is activated and index got 
> more than one segment.
> --
>
> Key: SOLR-8807
> URL: https://issues.apache.org/jira/browse/SOLR-8807
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 5.4
> Environment: Solr 5.4 with an index cosisting of two segments
>Reporter: Christian Danninger
>Priority: Critical
>  Labels: collapse, spellcheck
>
> When using spellchecker with collapse/expand results, I got an NPE. Only 
> happend when the index consists of more than one segment. 
> {code}
> 11:30:33,505 WARN  [org.apache.solr.spelling.SpellCheckCollator] 
> (http-/0.0.0.0:8080-2) Exception trying to re-query to check if a spell check 
> possibility would return any hits.: java.lang.NullPointerException
> at 
> org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:631)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:681)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:213)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1672)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1491)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:557) 
> [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:525)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:147)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:238)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:203)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:281)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) 
> [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> {code}
> {code}
>   
>   
> spellchecker
>   
> 
> {code}
> The query parameters are:
> {code}
>   "spellcheck.maxCollations": "5",
>   "q.op": "AND",
>   "fq": "{!collapse field=type}",
>   "spellcheck.maxCollationTries": "10",
>   "spellcheck.collateMaxCollectDocs": "10",
>   "spellcheck.alternativeTermCount": "10",
>   "spellcheck.extendedResults": "true",
>   "spellcheck.dictionary": [
> "dest_wordbreak",
> "dest_fuzzy"
>   ],
>   "q": "kosamui thailand",
>   "defType": "edismax",
>   "expand": "true",
>   "spellcheck.maxResultsForSuggest": "3",
>   "qf": "country_name region_name",
>   "spellcheck": "true",
>   "spellcheck.accuracy": "0.5",
>   "spellcheck.count": "20",
>   "spellcheck.collate": "true",
> {code}



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

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

[jira] [Commented] (SOLR-8807) NPE during spell checking when result collapsing is activated and index got more than one segment.

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8807:
--

If you stop setting spellcheck.collateMaxCollectDocs it should turn off the 
early termination. Not if this will kill your performance, but it should make 
the NPE go away.

> NPE during spell checking when result collapsing is activated and index got 
> more than one segment.
> --
>
> Key: SOLR-8807
> URL: https://issues.apache.org/jira/browse/SOLR-8807
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 5.4
> Environment: Solr 5.4 with an index cosisting of two segments
>Reporter: Christian Danninger
>Priority: Critical
>  Labels: collapse, spellcheck
>
> When using spellchecker with collapse/expand results, I got an NPE. Only 
> happend when the index consists of more than one segment. 
> {code}
> 11:30:33,505 WARN  [org.apache.solr.spelling.SpellCheckCollator] 
> (http-/0.0.0.0:8080-2) Exception trying to re-query to check if a spell check 
> possibility would return any hits.: java.lang.NullPointerException
> at 
> org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:631)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:681)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:213)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1672)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1491)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:557) 
> [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:525)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:147)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:238)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:203)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:281)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) 
> [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> {code}
> {code}
>   
>   
> spellchecker
>   
> 
> {code}
> The query parameters are:
> {code}
>   "spellcheck.maxCollations": "5",
>   "q.op": "AND",
>   "fq": "{!collapse field=type}",
>   "spellcheck.maxCollationTries": "10",
>   "spellcheck.collateMaxCollectDocs": "10",
>   "spellcheck.alternativeTermCount": "10",
>   "spellcheck.extendedResults": "true",
>   "spellcheck.dictionary": [
> "dest_wordbreak",
> "dest_fuzzy"
>   ],
>   "q": "kosamui thailand",
>   "defType": "edismax",
>   "expand": "true",
>   "spellcheck.maxResultsForSuggest": "3",
>   "qf": "country_name region_name",
>   "spellcheck": "true",
>   "spellcheck.accuracy": "0.5",
>   "spellcheck.count": "20",
>   "spellcheck.collate": "true",
> {code}



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

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

[jira] [Comment Edited] (SOLR-8807) NPE during spell checking when result collapsing is activated and index got more than one segment.

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8807 at 3/9/16 10:29 PM:
---

Just found this line in the SpellcheckCollator:

{code}
 checkResponse.setFieldFlags(f |= SolrIndexSearcher.TERMINATE_EARLY);   
 
{code}

This is problematic for the CollapsingQParserPlugin because not all segments 
will get visited during the search. Right now the CollapsingQParserPlugin 
relies on all segments getting visited or you get the NPE that is happening in 
this ticket. There probably is a way to deal with this but it's going to take 
some looking into.


was (Author: joel.bernstein):
Just found this line in the SpellcheckCollator:

{code}
 checkResponse.setFieldFlags(f |= SolrIndexSearcher.TERMINATE_EARLY);   
 
{code}

This is problematic for the CollapsingQParserPlugin because not all segments 
will get visited during the search. Right now the CollapsingQParserPlugin 
relies on all segments getting visited or you get the NPE that is happening in 
the this ticket. There probably is a way to deal with this but it's going to 
take some looking into.

> NPE during spell checking when result collapsing is activated and index got 
> more than one segment.
> --
>
> Key: SOLR-8807
> URL: https://issues.apache.org/jira/browse/SOLR-8807
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 5.4
> Environment: Solr 5.4 with an index cosisting of two segments
>Reporter: Christian Danninger
>Priority: Critical
>  Labels: collapse, spellcheck
>
> When using spellchecker with collapse/expand results, I got an NPE. Only 
> happend when the index consists of more than one segment. 
> {code}
> 11:30:33,505 WARN  [org.apache.solr.spelling.SpellCheckCollator] 
> (http-/0.0.0.0:8080-2) Exception trying to re-query to check if a spell check 
> possibility would return any hits.: java.lang.NullPointerException
> at 
> org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:631)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:681)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:213)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1672)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1491)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:557) 
> [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:525)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:147)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:238)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:203)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:281)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) 
> [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> {code}
> {code}
>   
>   
> spellchecker
>   
> 
> {code}
> The query parameters are:
> {code}
>   "spellcheck.maxCollations": "5",
>   "q.op": "AND",
>   "fq": "{!collapse field=type}",
>   "spellcheck.maxCollationTries": "10",
>   "spellcheck.collateMaxCollectDocs": "10",
>   "spellcheck.alternativeTermCount": "10",
>   "spellcheck.extendedResults": "true",
>   

[jira] [Commented] (SOLR-8807) NPE during spell checking when result collapsing is activated and index got more than one segment.

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8807:
--

Just found this line in the SpellcheckCollator:

{code}
 checkResponse.setFieldFlags(f |= SolrIndexSearcher.TERMINATE_EARLY);   
 
{code}

This is problematic for the CollapsingQParserPlugin because not all segments 
will get visited during the search. Right now the CollapsingQParserPlugin 
relies on all segments getting visited or you get the NPE that is happening in 
the this ticket. There probably is a way to deal with this but it's going to 
take some looking into.

> NPE during spell checking when result collapsing is activated and index got 
> more than one segment.
> --
>
> Key: SOLR-8807
> URL: https://issues.apache.org/jira/browse/SOLR-8807
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 5.4
> Environment: Solr 5.4 with an index cosisting of two segments
>Reporter: Christian Danninger
>Priority: Critical
>  Labels: collapse, spellcheck
>
> When using spellchecker with collapse/expand results, I got an NPE. Only 
> happend when the index consists of more than one segment. 
> {code}
> 11:30:33,505 WARN  [org.apache.solr.spelling.SpellCheckCollator] 
> (http-/0.0.0.0:8080-2) Exception trying to re-query to check if a spell check 
> possibility would return any hits.: java.lang.NullPointerException
> at 
> org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:631)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:681)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:213)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1672)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1491)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:557) 
> [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:525)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:147)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:238)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:203)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:281)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) 
> [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> {code}
> {code}
>   
>   
> spellchecker
>   
> 
> {code}
> The query parameters are:
> {code}
>   "spellcheck.maxCollations": "5",
>   "q.op": "AND",
>   "fq": "{!collapse field=type}",
>   "spellcheck.maxCollationTries": "10",
>   "spellcheck.collateMaxCollectDocs": "10",
>   "spellcheck.alternativeTermCount": "10",
>   "spellcheck.extendedResults": "true",
>   "spellcheck.dictionary": [
> "dest_wordbreak",
> "dest_fuzzy"
>   ],
>   "q": "kosamui thailand",
>   "defType": "edismax",
>   "expand": "true",
>   "spellcheck.maxResultsForSuggest": "3",
>   "qf": "country_name region_name",
>   "spellcheck": "true",
>   "spellcheck.accuracy": "0.5",
>   "spellcheck.count": "20",
>   "spellcheck.collate": "true",
> {code}



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

-
To unsubscribe, 

[jira] [Commented] (SOLR-8677) SOLR allows creation of shards with invalid names.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8677:
--

[~anshumg] Can this be closed out?

> SOLR allows creation of shards with invalid names.
> --
>
> Key: SOLR-8677
> URL: https://issues.apache.org/jira/browse/SOLR-8677
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8677.patch, SOLR-8677.patch, SOLR-8677.patch, 
> SOLR-8677.patch
>
>
> Solr currently has "recommendations" about what constitutes a valid 
> identifier, but doesn't enforce these "recommendations" uniformly.  Core 
> (SOLR-8308) and collection (SOLR-8642) names are currently checked, but 
> shards aren't.
> {code}
> $ bin/solr -e cloud -noprompt
> 
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CREATE=coll1=implicit=1=bad+shard+name;
> HTTP/1.1 200 OK
> Content-Type: application/xml; charset=UTF-8
> Transfer-Encoding: chunked
> 
> 
> 0 name="QTime">204 name="failure">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 
> 'coll1_bad shard name_replica1': Unable to create core [coll1_bad shard 
> name_replica1] Caused by: Invalid name: 'coll1_bad shard name_replica1' 
> Identifiers must consist entirely of periods, underscores and 
> alphanumerics
> 
> {code}
> (Note that the CREATE command above returned 200-OK, and the failure was only 
> apparent when viewing the message.)
> A CLUSTERSTATUS shows that the shard was actually created, but has no 
> underlying cores.
> {code}
> $ curl -i -l -k -X GET 
> "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS=json=true;
> ...
> "collections":{
>   "coll1":{
> "replicationFactor":"1",
> "shards":{"bad shard name":{
> "range":null,
> "state":"active",
> "replicas":{}}},
> "router":{"name":"implicit"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "znodeVersion":1,
> "configName":"gettingstarted"},
> ...
> {code}
> This JIRA proposes adding a check to ensure that shard names meet SOLR's 
> identifier "recommendations".  This should prevent users from accidentally 
> putting themselves in a bad state.



--
This message was sent by Atlassian 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-8807) NPE during spell checking when result collapsing is activated and index got more than one segment.

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8807:
--

Wondering if the spellchecker is enabling the early termination collector. It 
appears that not all the segments are being visited in the search that is being 
executed. I'll dig into the spellchecker and see what I can find.

> NPE during spell checking when result collapsing is activated and index got 
> more than one segment.
> --
>
> Key: SOLR-8807
> URL: https://issues.apache.org/jira/browse/SOLR-8807
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 5.4
> Environment: Solr 5.4 with an index cosisting of two segments
>Reporter: Christian Danninger
>Priority: Critical
>  Labels: collapse, spellcheck
>
> When using spellchecker with collapse/expand results, I got an NPE. Only 
> happend when the index consists of more than one segment. 
> {code}
> 11:30:33,505 WARN  [org.apache.solr.spelling.SpellCheckCollator] 
> (http-/0.0.0.0:8080-2) Exception trying to re-query to check if a spell check 
> possibility would return any hits.: java.lang.NullPointerException
> at 
> org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:631)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:681)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:213)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1672)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1491)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:557) 
> [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:525)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:147)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:238)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:203)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:281)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) 
> [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> {code}
> {code}
>   
>   
> spellchecker
>   
> 
> {code}
> The query parameters are:
> {code}
>   "spellcheck.maxCollations": "5",
>   "q.op": "AND",
>   "fq": "{!collapse field=type}",
>   "spellcheck.maxCollationTries": "10",
>   "spellcheck.collateMaxCollectDocs": "10",
>   "spellcheck.alternativeTermCount": "10",
>   "spellcheck.extendedResults": "true",
>   "spellcheck.dictionary": [
> "dest_wordbreak",
> "dest_fuzzy"
>   ],
>   "q": "kosamui thailand",
>   "defType": "edismax",
>   "expand": "true",
>   "spellcheck.maxResultsForSuggest": "3",
>   "qf": "country_name region_name",
>   "spellcheck": "true",
>   "spellcheck.accuracy": "0.5",
>   "spellcheck.count": "20",
>   "spellcheck.collate": "true",
> {code}



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

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

[jira] [Updated] (LUCENE-7068) Retrieve ranks

[Paul Elschot (JIRA)]

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

Paul Elschot updated LUCENE-7068:
-
Attachment: LUCENE-7068.patch

Patch of 9 March 2016.
Reworked the join implementation, and added another test.

This inner join implementation has a time complexity that is linear in the 
total input size.
The memory use can be limited by giving the largest input TopDocs last.

> Retrieve ranks
> --
>
> Key: LUCENE-7068
> URL: https://issues.apache.org/jira/browse/LUCENE-7068
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/other
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-7068.patch, LUCENE-7068.patch, LUCENE-7068.patch
>
>
> Join TopDocs by docs, keep the result ranks.



--
This message was sent by Atlassian 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-8812) ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-8812:
--

The difference in the generated query appears to be the "))~2" which indicates 
a BooleanQuery with a minShouldMatch of 2 which means that both OR/SHOULD terms 
MUST match, effectively turning SHOULD/OR into MUST/AND.

I'm guessing it was this 5.5 change: SOLR-2649:

{code}
* SOLR-2649: MM ignored in edismax queries with operators.
  (Greg Pendlebury, Jan Høydahl et. al. via Erick Erickson)
{code}

I think q.op=AND simply sets MM=100%, effectively overriding the explicit OR.



> ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND
> 
>
> Key: SOLR-8812
> URL: https://issues.apache.org/jira/browse/SOLR-8812
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 5.5
>Reporter: Ryan Steinberg
>
> The edismax parser ignores Boolean OR in queries when q.op=AND. This behavior 
> is new to Solr 5.5.0 and an unexpected major change.
> Example:
>   "q": "id:12345 OR zz",
>   "defType": "edismax",
>   "q.op": "AND",
> where "12345" is a known document ID and "zz" is a string NOT present 
> in my data
> Version 5.5.0 produces zero results:
> "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+((id:12345 
> DisjunctionMaxQuery((text:zz)))~2))/no_coord",
> "parsedquery_toString": "+((id:12345 (text:zz))~2)",
> "explain": {},
> "QParser": "ExtendedDismaxQParser"
> Version 5.4.0 produces one result as expected
>   "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+(id:12345 
> DisjunctionMaxQuery((text:zz/no_coord",
> "parsedquery_toString": "+(id:12345 (text:zz))"
> "explain": {},
> "QParser": "ExtendedDismaxQParser"



--
This message was sent by Atlassian 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: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

[Nicholas Knize]

This is a heads up that I will be starting the release process no earlier
than 24 hours from now. Thanks to everyone in advance for their help during
this process.

- Nick

On Tue, Mar 8, 2016 at 3:30 AM, Vanlerberghe, Luc <
luc.vanlerber...@bvdinfo.com> wrote:

> Hi,
>
>
>
> I added two JIRA issues (Lucene:
> https://issues.apache.org/jira/browse/LUCENE-7078, Solr:
> https://issues.apache.org/jira/browse/SOLR-8802 ) concerning Query
> classes that are still mutable and should either become immutable, marked
> as @lucene.experimental or get a comment why it’s not an issue for that
> case.
>
>
>
> Since they are part of the public API, I think now is the time to update
> them.
>
>
>
> I already converted MultiPhraseQuery (
> https://issues.apache.org/jira/browse/LUCENE-7064: reviewed and committed
> by Adrien Grand).
>
>
>
> Luc Vanlerberghe
>
>
>
> *From:* Joel Bernstein [mailto:joels...@gmail.com]
> *Sent:* maandag 7 maart 2016 21:08
> *To:* lucene dev
> *Subject:* [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch
>
>
>
> "Major API and bug fixes (no features) can be committed without my
> approval before Friday as long as they're reviewed and approved by another
> committer."
>
>
>
> Hmmm, are there really major API changes underway at this point? As far as
> bug fixes needing another committer approval is not something we've done in
> the past.
>
>
> Joel Bernstein
>
> http://joelsolr.blogspot.com/
>
>
>
> On Mon, Mar 7, 2016 at 2:54 PM, Nicholas Knize  wrote:
>
> I think with all of the volatility surrounding the new Points codec that
> obvious bug/stability patches like these are OK? I know several folks have
> been working feverishly the past few days to fix serious (and simplify) 6.0
> issues and squash all of the jenkins failures to ensure stability in time
> for the major release. That being said, you're right that we don't want
> chaotic committing as we lead up to the release.
>
>
>
> So unless there are no objections I'll plan to move forward and start the
> release process this Friday. Until then, since this is a major release, as
> many people we can get to scrutinize and stabilize 6_0 over the next 3-4
> days the better. Major API and bug fixes (no features) can be committed
> without my approval before Friday as long as they're reviewed and approved
> by another committer. If there is any uncertainty ping me on this thread or
> the corresponding issue and I'll review. I will also send out an email 24
> hours before I start the release process.
>
>
>
> - Nick
>
>
>
>
>
> On Mon, Mar 7, 2016 at 9:04 AM, david.w.smi...@gmail.com <
> david.w.smi...@gmail.com> wrote:
>
> I just want to clarify you(Nick) / our expectations about this release
> branch.  It seems, based on issues I've seen like LUCENE-7072, that we can
> commit to the release branch without your permission as RM.  If this is
> true, then I presume the tacit approval is okay so long as it's not a new
> feature.  Right?
>
>
>
> On Wed, Feb 24, 2016 at 3:23 PM Nicholas Knize  wrote:
>
> With the release of 5.5 and the previous discussion re: 6.0.0 I'd like to
> keep the ball moving and volunteer as the 6.0.0 RM.
>
>
>
> If there are no objections my plan is to cut branch_6_0 early next week -
> Mon or Tues. Please mark blocker issues accordingly and/or let me know if
> there are any commits needed before cutting the branch.
>
>
>
> - Nick
>
> --
>
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>
>
>
>

[jira] [Updated] (LUCENE-7078) Make remaining mutable Queries immutable

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-7078:
---
Fix Version/s: 6.1
   trunk

> Make remaining mutable Queries immutable
> 
>
> Key: LUCENE-7078
> URL: https://issues.apache.org/jira/browse/LUCENE-7078
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Luc Vanlerberghe
>Priority: Minor
> Fix For: trunk, 6.1
>
>
> See LUCENE-6531
> Mutable queries are an issue for automatic filter caching since modifying a 
> query after it has been put into the cache will corrupt the cache. We should 
> make all queries immutable (up to the boost) to avoid this issue.
> Since they are part of the public API I would suggest splitting them in an 
> immutable class and a builder like was done for most other Queries *before* 
> releasing an official 6.x version
> I did a quick scan through all derived classes of Query and I compiled the 
> following list (ignoring sources in test or contrib folders)
> Some of them are already marked as experimental (but should perhaps receive 
> the "official" @lucene.experimental tag ?)
> For some it's possibly not an issue since they should never end up in a 
> filter cache (like MoreLikeThisQuery ?), but then a comment specifying the 
> exception to the rule should perhaps be added.
> * lucene/queries:
> ** org.apache.lucene.queries.CommonTermsQuery
> ** org.apache.lucene.queries.CustomScoreQuery (marked as @lucene.experimental)
> ** org.apache.lucene.queries.mlt.MoreLikeThisQuery
> * lucene/suggest:
> ** org.apache.lucene.search.suggest.document.ContextQuery (marked as 
> @lucene.experimental)
> * lucene/facet:
> ** org.apache.lucene.facet.DrillDownQuery (marked as @lucene.experimental)



--
This message was sent by Atlassian 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-8807) NPE during spell checking when result collapsing is activated and index got more than one segment.

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8807:
--

Are you sure this is related to the spellchecker? Does the collapse query work 
if the spellchecker is turned off?

> NPE during spell checking when result collapsing is activated and index got 
> more than one segment.
> --
>
> Key: SOLR-8807
> URL: https://issues.apache.org/jira/browse/SOLR-8807
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 5.4
> Environment: Solr 5.4 with an index cosisting of two segments
>Reporter: Christian Danninger
>Priority: Critical
>  Labels: collapse, spellcheck
>
> When using spellchecker with collapse/expand results, I got an NPE. Only 
> happend when the index consists of more than one segment. 
> {code}
> 11:30:33,505 WARN  [org.apache.solr.spelling.SpellCheckCollator] 
> (http-/0.0.0.0:8080-2) Exception trying to re-query to check if a spell check 
> possibility would return any hits.: java.lang.NullPointerException
> at 
> org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:631)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:681)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:213)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1672)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1491)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:557) 
> [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:525)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:147)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:238)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:203)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:281)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
>  [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) 
> [solr-core-5.4.0.jar:5.4.0 1718046 - upayavira - 2015-12-04 23:16:46]
> {code}
> {code}
>   
>   
> spellchecker
>   
> 
> {code}
> The query parameters are:
> {code}
>   "spellcheck.maxCollations": "5",
>   "q.op": "AND",
>   "fq": "{!collapse field=type}",
>   "spellcheck.maxCollationTries": "10",
>   "spellcheck.collateMaxCollectDocs": "10",
>   "spellcheck.alternativeTermCount": "10",
>   "spellcheck.extendedResults": "true",
>   "spellcheck.dictionary": [
> "dest_wordbreak",
> "dest_fuzzy"
>   ],
>   "q": "kosamui thailand",
>   "defType": "edismax",
>   "expand": "true",
>   "spellcheck.maxResultsForSuggest": "3",
>   "qf": "country_name region_name",
>   "spellcheck": "true",
>   "spellcheck.accuracy": "0.5",
>   "spellcheck.count": "20",
>   "spellcheck.collate": "true",
> {code}



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

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

HttpSolrClient can swallow 401 Unauthorized

[Kevin Risden]

I was looking into SOLR-8213 [1] and found that HttpSolrClient can swallow
401 unauthorized when the following line 516 evaluates to true:

processor == null || processor instanceof InputStreamResponseParser

I think that in the httpStatus switch there should be a check for 401 and
bail out sooner. It looks like the 401 is only propagated when the mime
types don't match by chance on line 530. I think adding a case to the
switch like below would be more explicit and not cause processing to
continue.

case HttpStatus.SC_UNAUTHORIZED:
  throw new RemoteSolrException(baseUrl, httpStatus,
IOUtils.toString(respBody, "UTF-8"), null);

Is there any issue with this approach?

[1] https://issues.apache.org/jira/browse/SOLR-8213

Kevin Risden
Hadoop Tech Lead | Avalon Consulting, LLC 
M: 732 213 8417
LinkedIn  | Google+
 | Twitter


-
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited.

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

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8213 at 3/9/16 9:52 PM:
--

I think it would be good to get some other committers thoughts on this. Can you 
post a question on the dev list and let's see what other committers suggest 
here.


was (Author: joel.bernstein):
I think it would be good to get some other committers thoughts on this. Can 
post a question on the dev list and let's see what other committers suggest 
here.

> SolrJ JDBC support 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: 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-8213) SolrJ JDBC support authentication

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8213:
--

I think it would be good to get some other committers thoughts on this. Can 
post a question on the dev list and let's see what other committers suggest 
here.

> SolrJ JDBC support 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: 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-8814) Support GeoJSON response format

[David Smiley (JIRA)]

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

David Smiley updated SOLR-8814:
---
Summary: Support GeoJSON response format  (was: Suppor GeoJSON response 
format)

> Support GeoJSON response format
> ---
>
> Key: SOLR-8814
> URL: https://issues.apache.org/jira/browse/SOLR-8814
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Reporter: Ryan McKinley
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8814-add-GeoJSONResponseWriter.patch
>
>
> With minor changes, we can modify the existing JSON writer to produce a 
> GeoJSON `FeatureCollection` for ever SolrDocumentList.  We can then pick a 
> field to use as the geometry type, and use that for the Feature#geometry
> {code}
> "response":{"type":"FeatureCollection","numFound":1,"start":0,"features":[
>   {"type":"Feature",
> "geometry":{"type":"Point","coordinates":[1,2]},
> "properties":{
>   ... the normal solr doc fields here ...}}]
>   }}
> {code}
> This will allow adding solr results directly to various mapping clients like 
> [Leaflet|http://leafletjs.com/]
> 
> This patch will work with Documents that have a spatial field the either:
> 1. Extends AbstractSpatialFieldType
> 2. has a stored value with geojson
> 2. has a stored value that can be parsed by spatial4j (WKT, etc)
> The spatial field is identified with the parameter `geojson.field`



--
This message was sent by Atlassian 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-8213) SolrJ JDBC support authentication

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8213:
---
Attachment: add_basic_authentication_authorization_streaming.patch
add_401_httpstatus_code_check.patch

Attached a rough patch for adding a 401 HTTP status code check to 
HttpSolrClient. Also added patch that enables basic HTTP authentication and 
authorization for streaming/jdbc. Neither of these patches fix 
authentication/authorization for streaming or JDBC, but its a rough start to 
start testing it.

> SolrJ JDBC support 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: 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] (LUCENE-7089) Add points support to flexible queryparser to replace legacy numerics support.

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7089:


Phew, lots of classes for flexible QP.

+1, thanks [~rcmuir]!

> Add points support to flexible queryparser to replace legacy numerics support.
> --
>
> Key: LUCENE-7089
> URL: https://issues.apache.org/jira/browse/LUCENE-7089
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7089.patch
>
>
> This adds 1D point ranges/terms, the exact same way legacy numerics works 
> (and marks all their classes deprecated). 



--
This message was sent by Atlassian 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 authentication

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8213:


For reference here is the block to enable basic auth username solr and password 
SolrRocks and have read authorization. I tested this block with JdbcTest, 
StreamingTest, and StreamExpressionTest. It should work with any test that 
extends AbstractFullDistribZkTestBase I think.

{code}
  @Override
  public void distribSetUp() throws Exception {
super.distribSetUp();

// Sets up basic auth with user solr and password SolrRocks
// Enables read permissions for solr user
try (ZkStateReader zkStateReader = new 
ZkStateReader(zkServer.getZkAddress(),
DEFAULT_CONNECTION_TIMEOUT, DEFAULT_CONNECTION_TIMEOUT)) {
  zkStateReader.getZkClient().create(ZkStateReader.SOLR_SECURITY_CONF_PATH,
  ("{\n" +
  "  \"authentication\":{\n" +
  "\"class\":\"solr.BasicAuthPlugin\",\n" +
  "\"credentials\":{\n" +
  "  \"solr\":\"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= 
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=\"},\n" +
  "\"\":{\"v\":1}},\n" +
  "  \"authorization\":{\n" +
  "\"class\":\"solr.RuleBasedAuthorizationPlugin\",\n" +
  "\"permissions\":[\n" +
  "  {\n" +
  "\"name\":\"read\",\n" +
  "\"role\":[\"admin\"]}],\n" +
  "
\"user-role\":{\"solr\":\"admin\"}}}").getBytes(Charsets.UTF_8),
  CreateMode.PERSISTENT, true);
}
  }
{code}

> SolrJ JDBC support 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
>
> 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-8814) Suppor GeoJSON response format

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-8814:


I left some feedback: 
https://github.com/ryantxu/lucene-solr/commit/4792f0c13cb4d99cddf92c406a127ce08e04c715#diff-6ead4e8deaf560600de90a67c0b37e57R2126

> Suppor GeoJSON response format
> --
>
> Key: SOLR-8814
> URL: https://issues.apache.org/jira/browse/SOLR-8814
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Reporter: Ryan McKinley
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8814-add-GeoJSONResponseWriter.patch
>
>
> With minor changes, we can modify the existing JSON writer to produce a 
> GeoJSON `FeatureCollection` for ever SolrDocumentList.  We can then pick a 
> field to use as the geometry type, and use that for the Feature#geometry
> {code}
> "response":{"type":"FeatureCollection","numFound":1,"start":0,"features":[
>   {"type":"Feature",
> "geometry":{"type":"Point","coordinates":[1,2]},
> "properties":{
>   ... the normal solr doc fields here ...}}]
>   }}
> {code}
> This will allow adding solr results directly to various mapping clients like 
> [Leaflet|http://leafletjs.com/]
> 
> This patch will work with Documents that have a spatial field the either:
> 1. Extends AbstractSpatialFieldType
> 2. has a stored value with geojson
> 2. has a stored value that can be parsed by spatial4j (WKT, etc)
> The spatial field is identified with the parameter `geojson.field`



--
This message was sent by Atlassian 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-7089) Add points support to flexible queryparser to replace legacy numerics support.

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7089:

Attachment: LUCENE-7089.patch

> Add points support to flexible queryparser to replace legacy numerics support.
> --
>
> Key: LUCENE-7089
> URL: https://issues.apache.org/jira/browse/LUCENE-7089
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7089.patch
>
>
> This adds 1D point ranges/terms, the exact same way legacy numerics works 
> (and marks all their classes deprecated). 



--
This message was sent by Atlassian 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-7089) Add points support to flexible queryparser to replace legacy numerics support.

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7089:
---

 Summary: Add points support to flexible queryparser to replace 
legacy numerics support.
 Key: LUCENE-7089
 URL: https://issues.apache.org/jira/browse/LUCENE-7089
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


This adds 1D point ranges/terms, the exact same way legacy numerics works (and 
marks all their classes deprecated). 



--
This message was sent by Atlassian 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-8765) Enforce required parameters in SolrJ Collection APIs

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8765: Throw SolrException rather than IAE on name validation


> Enforce required parameters in SolrJ Collection APIs
> 
>
> Key: SOLR-8765
> URL: https://issues.apache.org/jira/browse/SOLR-8765
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.1
>
> Attachments: SOLR-8765.patch, SOLR-8765.patch
>
>
> Several Collection API commands have required parameters.  We should make 
> these constructor parameters, to enforce setting these in the API.



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+107) - Build # 74 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/74/
Java: 32bit/jdk-9-ea+107 -client -XX:+UseG1GC

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

Error Message:
No live SolrServers available to handle this request:[http://127.0.0.1:55321, 
http://127.0.0.1:46992, http://127.0.0.1:38316]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:55321, http://127.0.0.1:46992, 
http://127.0.0.1:38316]
at 
__randomizedtesting.SeedInfo.seed([FC75FCFF6D5259EE:7421C325C3AE3416]: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.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.TestCollectionAPI.testCollectionCreationCollectionNameValidation(TestCollectionAPI.java:646)
at 
org.apache.solr.cloud.TestCollectionAPI.test(TestCollectionAPI.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
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 

[jira] [Commented] (SOLR-8765) Enforce required parameters in SolrJ Collection APIs

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8765: Throw SolrException rather than IAE on name validation


> Enforce required parameters in SolrJ Collection APIs
> 
>
> Key: SOLR-8765
> URL: https://issues.apache.org/jira/browse/SOLR-8765
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.1
>
> Attachments: SOLR-8765.patch, SOLR-8765.patch
>
>
> Several Collection API commands have required parameters.  We should make 
> these constructor parameters, to enforce setting these in the API.



--
This message was sent by Atlassian 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-2605) queryparser parses on whitespace

[Fuad Efendi (JIRA)]

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

Fuad Efendi commented on LUCENE-2605:
-

Is that resolved? Anyone working on it? Thanks

> queryparser parses on whitespace
> 
>
> Key: LUCENE-2605
> URL: https://issues.apache.org/jira/browse/LUCENE-2605
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Reporter: Robert Muir
> Fix For: 4.9, master
>
>
> The queryparser parses input on whitespace, and sends each whitespace 
> separated term to its own independent token stream.
> This breaks the following at query-time, because they can't see across 
> whitespace boundaries:
> * n-gram analysis
> * shingles 
> * synonyms (especially multi-word for whitespace-separated languages)
> * languages where a 'word' can contain whitespace (e.g. vietnamese)
> Its also rather unexpected, as users think their 
> charfilters/tokenizers/tokenfilters will do the same thing at index and 
> querytime, but
> in many cases they can't. Instead, preferably the queryparser would parse 
> around only real 'operators'.



--
This message was sent by Atlassian 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 authentication

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8213:


[~joel.bernstein] - Maybe you can shed some light on a 401 Unauthorized being 
swallowed in HttpSolrClient.java.

In HttpSolrClient.java, the httpStatus switch on line 497 doesn't account for 
HttpStatus.SC_UNAUTHORIZED and then the stream is returned on lines 516-524.
{code}
if (processor == null || processor instanceof InputStreamResponseParser) {
  // no processor specified, return raw stream
  NamedList rsp = new NamedList<>();
  rsp.add("stream", respBody);
  // Only case where stream should not be closed
  shouldClose = false;
  return rsp;
}
{code}

The stream returned is pure HTML from the 401 unauthorized response which looks 
like:

{code}



Error 401 


HTTP ERROR: 401
Problem accessing /collection1/select. Reason:
Unauthorized request, Response code: 401
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.6.v20151106


{code}

This then causes the JSONTupleStream to blow up in the next() method since it 
can't parse the stream. The JSONTupleStream create method doesn't throw an 
exception since the response is actually valid just the stream contains content 
we don't want.

I think the fix is to bail out earlier in HttpSolrClient on a 401 unauthorized. 
This would propagate the error back up to the JSONTupleStream and further up 
the stack during open() instead of read() for the streams.

I was able to modify the JdbcTest to enable basic authentication and rules 
based authorization to show this exception and the same modification should 
work for the StreamingTest as well. I will upload a patch in a little bit.

> SolrJ JDBC support 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
>
> 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

[JENKINS] Lucene-Solr-Tests-master - Build # 973 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 15 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
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: hudson.plugins.git.GitException: Command "git -c core.askpass=true 
fetch --tags --progress git://git.apache.org/lucene-solr.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: read error: Connection reset by peer

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1693)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1441)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:62)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:313)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to lucene(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel.call(Channel.java:781)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor407.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at com.sun.proxy.$Proxy64.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:764)
... 11 more
ERROR: null
Retrying after 10 seconds
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > git://git.apache.org/lucene-solr.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
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 

Re: Speculating about the removal of the standalone Solr mode

[Rida Benjelloun]

Personnaly I Think that is very good Idea. In Constellio we use solr cloud
and zookeeper for sharding. I think that   the way  you suggest will
simplify and normalise the code.
Regards.
Le 2016-03-09 3:57 PM, "Shawn Heisey"  a écrit :

> On 3/9/2016 10:43 AM, Joel Bernstein wrote:
> > From Alfresco's point of view this would be a bad thing. Alfresco uses
> > Solr in stand alone mode and has developed an entire sharding and
> > replication model that fit's the ECM use case. So being forced to have
> > ZooKeeper and Solr Cloud would not be ideal.
>
> I'm aware of the potential pain.  Third-party Solr support and the
> documentation that goes with it might require significant changes -- but
> those changes will already be required if those packages want to add
> support for talking to SolrCloud in general.
>
> I firmly believe that "cloud mode only" is the way Solr is headed, and
> that once we reach the other side, Solr will be better, especially
> because of documentation and API consolidation.
>
> My intent would not be to force SolrCloud's built-in sharding on
> everyone.  You could still do completely manual sharding and work with
> individual Solr nodes like before.  The difference would be that each
> "standalone" Solr node would internally use zookeeper (probably the
> embedded server) to manage itself.  We might need to invent a
> "standalone collection" concept that could be used for
> single-shard-single-replica collections, where the core name and the
> collection name are the same, instead of cores named foo_shardN_replicaN.
>
> I myself would feel a lot of the pain you mentioned in relation to
> Alfresco.  I'm also manually managing shards on standalone Solr
> instances.  I've got a significant investment in a SolrJ application to
> handle these indexes.
>
> The change should not happen before 7.0, and with a major change like
> that on the horizon, the major version *before* the change (such as 6.x)
> should remain the stable branch for quite a while, so everybody has time
> to update and support cloud mode before it becomes mandatory.  There
> will be a lot of details to iron out.  I hope to be able to help with that.
>
> Thanks,
> Shawn
>
>
> -
> 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 # 34 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 16 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
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: hudson.plugins.git.GitException: Command "git -c core.askpass=true 
fetch --tags --progress git://git.apache.org/lucene-solr.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: read error: Connection reset by peer

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1693)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1441)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:62)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:313)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to lucene(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel.call(Channel.java:781)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor407.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at com.sun.proxy.$Proxy64.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:764)
... 11 more
ERROR: null
Retrying after 10 seconds
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > git://git.apache.org/lucene-solr.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
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 

Re: Speculating about the removal of the standalone Solr mode

[Shawn Heisey]

On 3/9/2016 10:43 AM, Joel Bernstein wrote:
> From Alfresco's point of view this would be a bad thing. Alfresco uses
> Solr in stand alone mode and has developed an entire sharding and
> replication model that fit's the ECM use case. So being forced to have
> ZooKeeper and Solr Cloud would not be ideal.

I'm aware of the potential pain.  Third-party Solr support and the
documentation that goes with it might require significant changes -- but
those changes will already be required if those packages want to add
support for talking to SolrCloud in general.

I firmly believe that "cloud mode only" is the way Solr is headed, and
that once we reach the other side, Solr will be better, especially
because of documentation and API consolidation.

My intent would not be to force SolrCloud's built-in sharding on
everyone.  You could still do completely manual sharding and work with
individual Solr nodes like before.  The difference would be that each
"standalone" Solr node would internally use zookeeper (probably the
embedded server) to manage itself.  We might need to invent a
"standalone collection" concept that could be used for
single-shard-single-replica collections, where the core name and the
collection name are the same, instead of cores named foo_shardN_replicaN.

I myself would feel a lot of the pain you mentioned in relation to
Alfresco.  I'm also manually managing shards on standalone Solr
instances.  I've got a significant investment in a SolrJ application to
handle these indexes.

The change should not happen before 7.0, and with a major change like
that on the horizon, the major version *before* the change (such as 6.x)
should remain the stable branch for quite a while, so everybody has time
to update and support cloud mode before it becomes mandatory.  There
will be a lot of details to iron out.  I hope to be able to help with that.

Thanks,
Shawn


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

[jira] [Updated] (SOLR-8814) Suppor GeoJSON response format

[Ryan McKinley (JIRA)]

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

Ryan McKinley updated SOLR-8814:

Description: 
With minor changes, we can modify the existing JSON writer to produce a GeoJSON 
`FeatureCollection` for ever SolrDocumentList.  We can then pick a field to use 
as the geometry type, and use that for the Feature#geometry

{code}
"response":{"type":"FeatureCollection","numFound":1,"start":0,"features":[
  {"type":"Feature",
"geometry":{"type":"Point","coordinates":[1,2]},
"properties":{
  ... the normal solr doc fields here ...}}]
  }}
{code}

This will allow adding solr results directly to various mapping clients like 
[Leaflet|http://leafletjs.com/]




This patch will work with Documents that have a spatial field the either:
1. Extends AbstractSpatialFieldType
2. has a stored value with geojson
2. has a stored value that can be parsed by spatial4j (WKT, etc)

The spatial field is identified with the parameter `geojson.field`



  was:
With minor changes, we can modify the existing JSON writer to produce a GeoJSON 
`FeatureCollection` for ever SolrDocumentList.  We can then pick a field to use 
as the geometry type, and use that for the Feature#geometry

{code}
"response":{"type":"FeatureCollection","numFound":1,"start":0,"features":[
  {"type":"Feature",
"geometry":{"type":"Point","coordinates":[1,2]},
"properties":{
  ... the normal solr doc fields here ...}}]
  }}
{code}

This will allow adding solr results directly to various mapping clients like 
[Leaflet|http://leafletjs.com/]




This patch will work with Documents that have a spatial field the either:
1. Extends AbstractSpatialFieldType
2. has a stored value with geojson
2. has a stored value that can be parsed by spatial4j (WKT, etc)




> Suppor GeoJSON response format
> --
>
> Key: SOLR-8814
> URL: https://issues.apache.org/jira/browse/SOLR-8814
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Reporter: Ryan McKinley
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8814-add-GeoJSONResponseWriter.patch
>
>
> With minor changes, we can modify the existing JSON writer to produce a 
> GeoJSON `FeatureCollection` for ever SolrDocumentList.  We can then pick a 
> field to use as the geometry type, and use that for the Feature#geometry
> {code}
> "response":{"type":"FeatureCollection","numFound":1,"start":0,"features":[
>   {"type":"Feature",
> "geometry":{"type":"Point","coordinates":[1,2]},
> "properties":{
>   ... the normal solr doc fields here ...}}]
>   }}
> {code}
> This will allow adding solr results directly to various mapping clients like 
> [Leaflet|http://leafletjs.com/]
> 
> This patch will work with Documents that have a spatial field the either:
> 1. Extends AbstractSpatialFieldType
> 2. has a stored value with geojson
> 2. has a stored value that can be parsed by spatial4j (WKT, etc)
> The spatial field is identified with the parameter `geojson.field`



--
This message was sent by Atlassian 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-8814) Suppor GeoJSON response format

[Ryan McKinley (JIRA)]

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

Ryan McKinley updated SOLR-8814:

Description: 
With minor changes, we can modify the existing JSON writer to produce a GeoJSON 
`FeatureCollection` for ever SolrDocumentList.  We can then pick a field to use 
as the geometry type, and use that for the Feature#geometry

{code}
"response":{"type":"FeatureCollection","numFound":1,"start":0,"features":[
  {"type":"Feature",
"geometry":{"type":"Point","coordinates":[1,2]},
"properties":{
  ... the normal solr doc fields here ...}}]
  }}
{code}

This will allow adding solr results directly to various mapping clients like 
[Leaflet|http://leafletjs.com/]




This patch will work with Documents that have a spatial field the either:
1. Extends AbstractSpatialFieldType
2. has a stored value with geojson
2. has a stored value that can be parsed by spatial4j (WKT, etc)



  was:
With minor changes, we can modify the existing JSON writer to produce a GeoJSON 
`FeatureCollection` for ever SolrDocumentList.  We can then pick a field to use 
as the geometry type, and use that for the Feature#geometry

{code}
"response":{"type":"FeatureCollection","numFound":1,"start":0,"features":[
  {"type":"Feature",
"geometry":{"type":"Point","coordinates":[1,2]},
"properties":{
  ... the normal solr doc fields here ...}}]
  }}
{code}

This will allow adding solr results directly to various mapping clients like 
[Leaflet|http://leafletjs.com/]


> Suppor GeoJSON response format
> --
>
> Key: SOLR-8814
> URL: https://issues.apache.org/jira/browse/SOLR-8814
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Reporter: Ryan McKinley
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8814-add-GeoJSONResponseWriter.patch
>
>
> With minor changes, we can modify the existing JSON writer to produce a 
> GeoJSON `FeatureCollection` for ever SolrDocumentList.  We can then pick a 
> field to use as the geometry type, and use that for the Feature#geometry
> {code}
> "response":{"type":"FeatureCollection","numFound":1,"start":0,"features":[
>   {"type":"Feature",
> "geometry":{"type":"Point","coordinates":[1,2]},
> "properties":{
>   ... the normal solr doc fields here ...}}]
>   }}
> {code}
> This will allow adding solr results directly to various mapping clients like 
> [Leaflet|http://leafletjs.com/]
> 
> This patch will work with Documents that have a spatial field the either:
> 1. Extends AbstractSpatialFieldType
> 2. has a stored value with geojson
> 2. has a stored value that can be parsed by spatial4j (WKT, etc)



--
This message was sent by Atlassian 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-8740) use docValues by default

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8740:
--

I added some tests that should serve to flag if the ordering of MV fields is 
different so we can stop discussing it ;) See SOLR-8813

> use docValues by default
> 
>
> Key: SOLR-8740
> URL: https://issues.apache.org/jira/browse/SOLR-8740
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master
>Reporter: Yonik Seeley
> Fix For: master
>
>
> We should consider switching to docValues for most of our non-text fields.  
> This may be a better default since it is more NRT friendly and acts to avoid 
> OOM errors due to large field cache or UnInvertedField entries.



--
This message was sent by Atlassian 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-8813) Add test for MultiValued fields being returned in the correct order

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-8813.
--
   Resolution: Fixed
Fix Version/s: 6.1
   trunk

> Add test for MultiValued fields being returned in the correct order
> ---
>
> Key: SOLR-8813
> URL: https://issues.apache.org/jira/browse/SOLR-8813
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Fix For: trunk, 6.1
>
> Attachments: SOLR-8813.patch
>
>
> This is an outgrowth of SOLR-8740. When we move to returning fields in the 
> response from docValues fields, we _may_ break the contract we've had for 
> years that multiValued stored fields are returned in the order they were 
> inserted.
> This test is here it show the current behavior. If we change the behavior we 
> need to clearly document any breaks in back-compat.



--
This message was sent by Atlassian 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-8813) Add test for MultiValued fields being returned in the correct order

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8813: Add test for MultiValued fields being returned in the correct order


> Add test for MultiValued fields being returned in the correct order
> ---
>
> Key: SOLR-8813
> URL: https://issues.apache.org/jira/browse/SOLR-8813
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-8813.patch
>
>
> This is an outgrowth of SOLR-8740. When we move to returning fields in the 
> response from docValues fields, we _may_ break the contract we've had for 
> years that multiValued stored fields are returned in the order they were 
> inserted.
> This test is here it show the current behavior. If we change the behavior we 
> need to clearly document any breaks in back-compat.



--
This message was sent by Atlassian 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-8814) Suppor GeoJSON response format

[Ryan McKinley (JIRA)]

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

Ryan McKinley updated SOLR-8814:

Attachment: SOLR-8814-add-GeoJSONResponseWriter.patch

Here is a patch...  now i will try to figure out this git bizness!

> Suppor GeoJSON response format
> --
>
> Key: SOLR-8814
> URL: https://issues.apache.org/jira/browse/SOLR-8814
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Reporter: Ryan McKinley
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8814-add-GeoJSONResponseWriter.patch
>
>
> With minor changes, we can modify the existing JSON writer to produce a 
> GeoJSON `FeatureCollection` for ever SolrDocumentList.  We can then pick a 
> field to use as the geometry type, and use that for the Feature#geometry
> {code}
> "response":{"type":"FeatureCollection","numFound":1,"start":0,"features":[
>   {"type":"Feature",
> "geometry":{"type":"Point","coordinates":[1,2]},
> "properties":{
>   ... the normal solr doc fields here ...}}]
>   }}
> {code}
> This will allow adding solr results directly to various mapping clients like 
> [Leaflet|http://leafletjs.com/]



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

[Apache Jenkins Server]

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

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

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:41340/rqpa/p, http://127.0.0.1:33295/rqpa/p, 
http://127.0.0.1:45464/rqpa/p]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:41340/rqpa/p, 
http://127.0.0.1:33295/rqpa/p, http://127.0.0.1:45464/rqpa/p]
at 
__randomizedtesting.SeedInfo.seed([2C0E4018F461728F:A45A7FC25A9D1F77]: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.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.TestCollectionAPI.testCollectionCreationCollectionNameValidation(TestCollectionAPI.java:646)
at 
org.apache.solr.cloud.TestCollectionAPI.test(TestCollectionAPI.java:83)
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Created] (SOLR-8814) Suppor GeoJSON response format

[Ryan McKinley (JIRA)]

Ryan McKinley created SOLR-8814:
---

 Summary: Suppor GeoJSON response format
 Key: SOLR-8814
 URL: https://issues.apache.org/jira/browse/SOLR-8814
 Project: Solr
  Issue Type: New Feature
  Components: Response Writers
Reporter: Ryan McKinley
Priority: Minor
 Fix For: master, 6.1


With minor changes, we can modify the existing JSON writer to produce a GeoJSON 
`FeatureCollection` for ever SolrDocumentList.  We can then pick a field to use 
as the geometry type, and use that for the Feature#geometry

{code}
"response":{"type":"FeatureCollection","numFound":1,"start":0,"features":[
  {"type":"Feature",
"geometry":{"type":"Point","coordinates":[1,2]},
"properties":{
  ... the normal solr doc fields here ...}}]
  }}
{code}

This will allow adding solr results directly to various mapping clients like 
[Leaflet|http://leafletjs.com/]



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

[Policeman Jenkins Server]

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

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

Error Message:
No live SolrServers available to handle this 
request:[https://127.0.0.1:46150/_kvu/zh, https://127.0.0.1:38637/_kvu/zh, 
https://127.0.0.1:54669/_kvu/zh]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[https://127.0.0.1:46150/_kvu/zh, 
https://127.0.0.1:38637/_kvu/zh, https://127.0.0.1:54669/_kvu/zh]
at 
__randomizedtesting.SeedInfo.seed([29AC623EA1484E7:8ACEF9F944E8E91F]: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.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.TestCollectionAPI.testCollectionCreationCollectionNameValidation(TestCollectionAPI.java:646)
at 
org.apache.solr.cloud.TestCollectionAPI.test(TestCollectionAPI.java:83)
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 

[jira] [Updated] (SOLR-8813) Add test for MultiValued fields being returned in the correct order

[Erick Erickson (JIRA)]

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

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

Note that I removed the  and  tags from the schema file and 
re-indented.

The only substantive change to the schema is adding four very specific types...

> Add test for MultiValued fields being returned in the correct order
> ---
>
> Key: SOLR-8813
> URL: https://issues.apache.org/jira/browse/SOLR-8813
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-8813.patch
>
>
> This is an outgrowth of SOLR-8740. When we move to returning fields in the 
> response from docValues fields, we _may_ break the contract we've had for 
> years that multiValued stored fields are returned in the order they were 
> inserted.
> This test is here it show the current behavior. If we change the behavior we 
> need to clearly document any breaks in back-compat.



--
This message was sent by Atlassian 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-8777) Duplicate Solr process can cripple a running process

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-8777:
-

bq. I suppose we could spin for a while waiting for the previous ephemeral node 
to disappear, and if it doesn't, error out and refuse to start?

Yeah, spinning for say 2 * sessionTimeout should do the trick. This effectively 
removes this optimisation for fast node restarts and we can look into bringing 
it back in some form at a later date.

bq. Not completely related, but it seems like there's a bug in jetty's 
SocketConnector. It uses the ServerSocket constructor that automatically binds 
the port, then attempts to set setReuseAddress(), which makes no sense. It 
should use the other constructor, set the reuse_address option, then call 
bind() manually.

Perhaps [~joakime] or [~gregw] can chime in here?

bq. In other news, I don't know that there's a way to change Jetty's startup 
sequence.. the best I could do is try to use reflection to pull the connectors 
off the Server and start them early. But that seems ungood.

Theoretically, now that we control the app server -- we could move to using 
embedded Jetty (like we do for tests with JettySolrRunner) and control the 
lifecycle pretty much exactly but that is way overkill for this issue.

> Duplicate Solr process can cripple a running process
> 
>
> Key: SOLR-8777
> URL: https://issues.apache.org/jira/browse/SOLR-8777
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3.1
>Reporter: Shalin Shekhar Mangar
>
> Thanks to [~mewmewball] for catching this one.
> Accidentally executing the same instance of Solr twice causes the second 
> start instance to die with an "Address already in use", but not before 
> deleting the first instance's live_node entry, emitting "Found a previous 
> node that still exists while trying to register a new live node  - 
> removing existing node to create another".
> The second start instance dies and its ephemeral node is then removed, 
> causing /live_nodes/ to be empty since the first start instance's 
> live_node was deleted by the second.



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

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

Re: [JENKINS] Lucene-Solr-SmokeRelease-master - Build # 432 - Still Failing

[Michael McCandless]

+1, I'll do this in LUCENE-7086.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Mar 9, 2016 at 2:38 PM, Robert Muir  wrote:
> I think we should stop wrapping with slowwrapper in newSearcher? this
> sucks because then it silently fails on points. E.g. these tests all
> passed at least 3 times for me :)
>
> On Wed, Mar 9, 2016 at 2:10 PM, Michael McCandless
>  wrote:
>> I pushed a fix.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Wed, Mar 9, 2016 at 12:13 PM, Apache Jenkins Server
>>  wrote:
>>> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/432/
>>>
>>> No tests ran.
>>>
>>> Build Log:
>>> [...truncated 40030 lines...]
>>> prepare-release-no-sign:
>>> [mkdir] Created dir: 
>>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
>>>  [copy] Copying 476 files to 
>>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
>>>  [copy] Copying 245 files to 
>>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
>>>[smoker] Java 1.8 
>>> JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
>>>[smoker] NOTE: output encoding is UTF-8
>>>[smoker]
>>>[smoker] Load release URL 
>>> "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
>>>[smoker]
>>>[smoker] Test Lucene...
>>>[smoker]   test basics...
>>>[smoker]   get KEYS
>>>[smoker] 0.2 MB in 0.02 sec (9.5 MB/sec)
>>>[smoker]   check changes HTML...
>>>[smoker]   download lucene-7.0.0-src.tgz...
>>>[smoker] 28.5 MB in 0.04 sec (782.9 MB/sec)
>>>[smoker] verify md5/sha1 digests
>>>[smoker]   download lucene-7.0.0.tgz...
>>>[smoker] 62.8 MB in 0.07 sec (841.4 MB/sec)
>>>[smoker] verify md5/sha1 digests
>>>[smoker]   download lucene-7.0.0.zip...
>>>[smoker] 73.5 MB in 0.09 sec (824.8 MB/sec)
>>>[smoker] verify md5/sha1 digests
>>>[smoker]   unpack lucene-7.0.0.tgz...
>>>[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>>>[smoker] test demo with 1.8...
>>>[smoker]   got 6039 hits for query "lucene"
>>>[smoker] checkindex with 1.8...
>>>[smoker] check Lucene's javadoc JAR
>>>[smoker]   unpack lucene-7.0.0.zip...
>>>[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>>>[smoker] test demo with 1.8...
>>>[smoker]   got 6039 hits for query "lucene"
>>>[smoker] checkindex with 1.8...
>>>[smoker] check Lucene's javadoc JAR
>>>[smoker]   unpack lucene-7.0.0-src.tgz...
>>>[smoker] make sure no JARs/WARs in src dist...
>>>[smoker] run "ant validate"
>>>[smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
>>>[smoker]
>>>[smoker] command "export 
>>> JAVA_HOME="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8" 
>>> PATH="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8/bin:$PATH"
>>>  
>>> JAVACMD="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8/bin/java";
>>>  ant clean test -Dtests.slow=false" failed:
>>>[smoker] Buildfile: 
>>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.0.0/build.xml
>>>[smoker]
>>>[smoker] clean:
>>>[smoker][delete] Deleting directory 
>>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.0.0/build
>>>[smoker]
>>>[smoker] ivy-availability-check:
>>>[smoker]
>>>[smoker] ivy-fail:
>>>[smoker]
>>>[smoker] ivy-configure:
>>>[smoker] [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: 
>>> http://ant.apache.org/ivy/ ::
>>>[smoker] [ivy:configure] :: loading settings :: file = 
>>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.0.0/ivy-settings.xml
>>>[smoker]
>>>[smoker] -clover.load:
>>>[smoker]
>>>[smoker] resolve-groovy:
>>>[smoker] [ivy:cachepath] :: resolving dependencies :: 
>>> org.codehaus.groovy#groovy-all-caller;working
>>>[smoker] [ivy:cachepath] confs: [default]
>>>[smoker] [ivy:cachepath] found org.codehaus.groovy#groovy-all;2.4.4 
>>> in public
>>>[smoker] [ivy:cachepath] :: resolution report :: resolve 222ms :: 
>>> artifacts dl 2ms
>>>[smoker] 
>>> -
>>>[smoker] |  |modules||   
>>> artifacts   |
>>>[smoker] |   conf   | number| search|dwnlded|evicted|| 
>>> number|dwnlded|
>>>[smoker] 
>>> 

[jira] [Commented] (SOLR-8813) Add test for MultiValued fields being returned in the correct order

[ASF subversion and git services (JIRA)]

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

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

Commit 540e8010c32c600a4ec6b29f6236ba43b9d1afd6 in lucene-solr's branch 
refs/heads/master from [~erickerickson]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=540e801 ]

SOLR-8813: Add test for MultiValued fields being returned in the correct order


> Add test for MultiValued fields being returned in the correct order
> ---
>
> Key: SOLR-8813
> URL: https://issues.apache.org/jira/browse/SOLR-8813
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>
> This is an outgrowth of SOLR-8740. When we move to returning fields in the 
> response from docValues fields, we _may_ break the contract we've had for 
> years that multiValued stored fields are returned in the order they were 
> inserted.
> This test is here it show the current behavior. If we change the behavior we 
> need to clearly document any breaks in back-compat.



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

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

Re: [JENKINS] Lucene-Solr-SmokeRelease-master - Build # 432 - Still Failing

[Robert Muir]

I think we should stop wrapping with slowwrapper in newSearcher? this
sucks because then it silently fails on points. E.g. these tests all
passed at least 3 times for me :)

On Wed, Mar 9, 2016 at 2:10 PM, Michael McCandless
 wrote:
> I pushed a fix.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Mar 9, 2016 at 12:13 PM, Apache Jenkins Server
>  wrote:
>> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/432/
>>
>> No tests ran.
>>
>> Build Log:
>> [...truncated 40030 lines...]
>> prepare-release-no-sign:
>> [mkdir] Created dir: 
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
>>  [copy] Copying 476 files to 
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
>>  [copy] Copying 245 files to 
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
>>[smoker] Java 1.8 
>> JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
>>[smoker] NOTE: output encoding is UTF-8
>>[smoker]
>>[smoker] Load release URL 
>> "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
>>[smoker]
>>[smoker] Test Lucene...
>>[smoker]   test basics...
>>[smoker]   get KEYS
>>[smoker] 0.2 MB in 0.02 sec (9.5 MB/sec)
>>[smoker]   check changes HTML...
>>[smoker]   download lucene-7.0.0-src.tgz...
>>[smoker] 28.5 MB in 0.04 sec (782.9 MB/sec)
>>[smoker] verify md5/sha1 digests
>>[smoker]   download lucene-7.0.0.tgz...
>>[smoker] 62.8 MB in 0.07 sec (841.4 MB/sec)
>>[smoker] verify md5/sha1 digests
>>[smoker]   download lucene-7.0.0.zip...
>>[smoker] 73.5 MB in 0.09 sec (824.8 MB/sec)
>>[smoker] verify md5/sha1 digests
>>[smoker]   unpack lucene-7.0.0.tgz...
>>[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>>[smoker] test demo with 1.8...
>>[smoker]   got 6039 hits for query "lucene"
>>[smoker] checkindex with 1.8...
>>[smoker] check Lucene's javadoc JAR
>>[smoker]   unpack lucene-7.0.0.zip...
>>[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>>[smoker] test demo with 1.8...
>>[smoker]   got 6039 hits for query "lucene"
>>[smoker] checkindex with 1.8...
>>[smoker] check Lucene's javadoc JAR
>>[smoker]   unpack lucene-7.0.0-src.tgz...
>>[smoker] make sure no JARs/WARs in src dist...
>>[smoker] run "ant validate"
>>[smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
>>[smoker]
>>[smoker] command "export 
>> JAVA_HOME="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8" 
>> PATH="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8/bin:$PATH"
>>  
>> JAVACMD="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8/bin/java";
>>  ant clean test -Dtests.slow=false" failed:
>>[smoker] Buildfile: 
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.0.0/build.xml
>>[smoker]
>>[smoker] clean:
>>[smoker][delete] Deleting directory 
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.0.0/build
>>[smoker]
>>[smoker] ivy-availability-check:
>>[smoker]
>>[smoker] ivy-fail:
>>[smoker]
>>[smoker] ivy-configure:
>>[smoker] [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: 
>> http://ant.apache.org/ivy/ ::
>>[smoker] [ivy:configure] :: loading settings :: file = 
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.0.0/ivy-settings.xml
>>[smoker]
>>[smoker] -clover.load:
>>[smoker]
>>[smoker] resolve-groovy:
>>[smoker] [ivy:cachepath] :: resolving dependencies :: 
>> org.codehaus.groovy#groovy-all-caller;working
>>[smoker] [ivy:cachepath] confs: [default]
>>[smoker] [ivy:cachepath] found org.codehaus.groovy#groovy-all;2.4.4 
>> in public
>>[smoker] [ivy:cachepath] :: resolution report :: resolve 222ms :: 
>> artifacts dl 2ms
>>[smoker] 
>> -
>>[smoker] |  |modules||   
>> artifacts   |
>>[smoker] |   conf   | number| search|dwnlded|evicted|| 
>> number|dwnlded|
>>[smoker] 
>> -
>>[smoker] |  default |   1   |   0   |   0   |   0   ||   1   
>> |   0   |
>>[smoker] 
>> -
>>[smoker]
>>[smoker] 

[JENKINS] Lucene-Solr-Tests-6.x - Build # 33 - Still Failing

[Apache Jenkins Server]

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

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

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:38059/w/a, http://127.0.0.1:33740/w/a, 
http://127.0.0.1:41285/w/a]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:38059/w/a, http://127.0.0.1:33740/w/a, 
http://127.0.0.1:41285/w/a]
at 
__randomizedtesting.SeedInfo.seed([74DC3F8F60FD25DA:FC880055CE014822]: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.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.TestCollectionAPI.testCollectionCreationCollectionNameValidation(TestCollectionAPI.java:646)
at 
org.apache.solr.cloud.TestCollectionAPI.test(TestCollectionAPI.java:83)
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Assigned] (SOLR-8804) Race condition in ClusterStatus.getClusterStatus

[Varun Thacker (JIRA)]

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

Varun Thacker reassigned SOLR-8804:
---

Assignee: Varun Thacker

> Race condition in ClusterStatus.getClusterStatus
> 
>
> Key: SOLR-8804
> URL: https://issues.apache.org/jira/browse/SOLR-8804
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3.1
>Reporter: Alexey Serba
>Assignee: Varun Thacker
>Priority: Trivial
> Attachments: SOLR-8804.patch
>
>
> Reading cluster state information using {{/collections?action=CLUSTERSTATUS}} 
> can fail if there's a concurrent {{/collections?action=DELETE}} operation.
> The code in {{ClusterStatus.getClusterStatus}} 
> # gets collection names
> # for every collection reads its cluster state info using 
> {{ClusterState.getCollection}}
> The problem is that if there's a {{DELETE}} operation in between then 
> {{ClusterState.getCollection}} can fail thus causing the whole operation to 
> fail. It seems that it would be better to call 
> {{ClusterState.getCollectionOrNull}} and skip/ignore that collection if the 
> result is null.
> {noformat}
> 19:49:32.479 [qtp1531448569-881] ERROR org.apache.solr.core.SolrCore - 
> org.apache.solr.common.SolrException: Could not find collection : collection
> at 
> org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:165)
> at 
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:110)
> at 
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation$19.call(CollectionsHandler.java:614)
> at 
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:166)
> {noformat}



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

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

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

[Policeman Jenkins Server]

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

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

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

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


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

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

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


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

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

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


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

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 30 
seconds
at 
__randomizedtesting.SeedInfo.seed([DC9C62D5354EC58C:54C85D0F9BB2A874]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:173)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1412)
at 
org.apache.solr.cloud.AliasIntegrationTest.test(AliasIntegrationTest.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 

[jira] [Updated] (SOLR-8804) Race condition in ClusterStatus.getClusterStatus

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-8804:

Attachment: SOLR-8804.patch

Patch which fixes the problem. 

> Race condition in ClusterStatus.getClusterStatus
> 
>
> Key: SOLR-8804
> URL: https://issues.apache.org/jira/browse/SOLR-8804
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3.1
>Reporter: Alexey Serba
>Priority: Trivial
> Attachments: SOLR-8804.patch
>
>
> Reading cluster state information using {{/collections?action=CLUSTERSTATUS}} 
> can fail if there's a concurrent {{/collections?action=DELETE}} operation.
> The code in {{ClusterStatus.getClusterStatus}} 
> # gets collection names
> # for every collection reads its cluster state info using 
> {{ClusterState.getCollection}}
> The problem is that if there's a {{DELETE}} operation in between then 
> {{ClusterState.getCollection}} can fail thus causing the whole operation to 
> fail. It seems that it would be better to call 
> {{ClusterState.getCollectionOrNull}} and skip/ignore that collection if the 
> result is null.
> {noformat}
> 19:49:32.479 [qtp1531448569-881] ERROR org.apache.solr.core.SolrCore - 
> org.apache.solr.common.SolrException: Could not find collection : collection
> at 
> org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:165)
> at 
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:110)
> at 
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation$19.call(CollectionsHandler.java:614)
> at 
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:166)
> {noformat}



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

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

Re: [JENKINS] Lucene-Solr-SmokeRelease-master - Build # 432 - Still Failing

[Michael McCandless]

I pushed a fix.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Mar 9, 2016 at 12:13 PM, Apache Jenkins Server
 wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/432/
>
> No tests ran.
>
> Build Log:
> [...truncated 40030 lines...]
> prepare-release-no-sign:
> [mkdir] Created dir: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
>  [copy] Copying 476 files to 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
>  [copy] Copying 245 files to 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
>[smoker] Java 1.8 
> JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
>[smoker] NOTE: output encoding is UTF-8
>[smoker]
>[smoker] Load release URL 
> "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
>[smoker]
>[smoker] Test Lucene...
>[smoker]   test basics...
>[smoker]   get KEYS
>[smoker] 0.2 MB in 0.02 sec (9.5 MB/sec)
>[smoker]   check changes HTML...
>[smoker]   download lucene-7.0.0-src.tgz...
>[smoker] 28.5 MB in 0.04 sec (782.9 MB/sec)
>[smoker] verify md5/sha1 digests
>[smoker]   download lucene-7.0.0.tgz...
>[smoker] 62.8 MB in 0.07 sec (841.4 MB/sec)
>[smoker] verify md5/sha1 digests
>[smoker]   download lucene-7.0.0.zip...
>[smoker] 73.5 MB in 0.09 sec (824.8 MB/sec)
>[smoker] verify md5/sha1 digests
>[smoker]   unpack lucene-7.0.0.tgz...
>[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>[smoker] test demo with 1.8...
>[smoker]   got 6039 hits for query "lucene"
>[smoker] checkindex with 1.8...
>[smoker] check Lucene's javadoc JAR
>[smoker]   unpack lucene-7.0.0.zip...
>[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>[smoker] test demo with 1.8...
>[smoker]   got 6039 hits for query "lucene"
>[smoker] checkindex with 1.8...
>[smoker] check Lucene's javadoc JAR
>[smoker]   unpack lucene-7.0.0-src.tgz...
>[smoker] make sure no JARs/WARs in src dist...
>[smoker] run "ant validate"
>[smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
>[smoker]
>[smoker] command "export 
> JAVA_HOME="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8" 
> PATH="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8/bin:$PATH" 
> JAVACMD="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8/bin/java";
>  ant clean test -Dtests.slow=false" failed:
>[smoker] Buildfile: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.0.0/build.xml
>[smoker]
>[smoker] clean:
>[smoker][delete] Deleting directory 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.0.0/build
>[smoker]
>[smoker] ivy-availability-check:
>[smoker]
>[smoker] ivy-fail:
>[smoker]
>[smoker] ivy-configure:
>[smoker] [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: 
> http://ant.apache.org/ivy/ ::
>[smoker] [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.0.0/ivy-settings.xml
>[smoker]
>[smoker] -clover.load:
>[smoker]
>[smoker] resolve-groovy:
>[smoker] [ivy:cachepath] :: resolving dependencies :: 
> org.codehaus.groovy#groovy-all-caller;working
>[smoker] [ivy:cachepath] confs: [default]
>[smoker] [ivy:cachepath] found org.codehaus.groovy#groovy-all;2.4.4 in 
> public
>[smoker] [ivy:cachepath] :: resolution report :: resolve 222ms :: 
> artifacts dl 2ms
>[smoker] 
> -
>[smoker] |  |modules||   
> artifacts   |
>[smoker] |   conf   | number| search|dwnlded|evicted|| 
> number|dwnlded|
>[smoker] 
> -
>[smoker] |  default |   1   |   0   |   0   |   0   ||   1   | 
>   0   |
>[smoker] 
> -
>[smoker]
>[smoker] -init-totals:
>[smoker]
>[smoker] test-core:
>[smoker]
>[smoker] -clover.disable:
>[smoker]
>[smoker] ivy-availability-check:
>[smoker]
>[smoker] ivy-fail:
>[smoker]
>[smoker] ivy-configure:
>[smoker] [ivy:configure] :: loading settings :: file = 
> 

Re: [JENKINS] Lucene-Solr-Tests-6.x - Build # 32 - Still Failing

[Michael McCandless]

I pushed a fix.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Mar 9, 2016 at 1:51 PM, Michael McCandless
 wrote:
> I'll dig.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Mar 9, 2016 at 12:59 PM, Apache Jenkins Server
>  wrote:
>> Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/32/
>>
>> 1 tests failed.
>> FAILED:  
>> org.apache.lucene.search.join.TestBlockJoin.testBugCausedByRewritingTwice
>>
>> Error Message:
>>
>>
>> Stack Trace:
>> java.lang.NullPointerException
>> at 
>> __randomizedtesting.SeedInfo.seed([F8CC8C8B5953C710:7B05C20D26C1B69]:0)
>> at 
>> org.apache.lucene.search.join.TestBlockJoin.testBugCausedByRewritingTwice(TestBlockJoin.java:298)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:497)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
>> at 
>> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java: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 
>> 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)
>>
>>
>>
>>
>> Build Log:
>> [...truncated 7150 lines...]
>>[junit4] Suite: org.apache.lucene.search.join.TestBlockJoin
>>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestBlockJoin 
>> -Dtests.method=testBugCausedByRewritingTwice -Dtests.seed=F8CC8C8B5953C710 
>> 

[jira] [Assigned] (LUCENE-7086) SlowCompositeReaderWrapper does not support point values

[Michael McCandless (JIRA)]

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

Michael McCandless reassigned LUCENE-7086:
--

Assignee: Michael McCandless

> SlowCompositeReaderWrapper does not support point values
> 
>
> Key: LUCENE-7086
> URL: https://issues.apache.org/jira/browse/LUCENE-7086
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Michael McCandless
>
> SlowCompositeReaderWrapper.getPointValues always returns null. I think this 
> is trappy and we should either implement it or throw an 
> UnsupportedOperationException instead.



--
This message was sent by Atlassian 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-7086) SlowCompositeReaderWrapper does not support point values

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7086:


Thanks [~jpountz], I'll fix it to throw UOE.

> SlowCompositeReaderWrapper does not support point values
> 
>
> Key: LUCENE-7086
> URL: https://issues.apache.org/jira/browse/LUCENE-7086
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Michael McCandless
>
> SlowCompositeReaderWrapper.getPointValues always returns null. I think this 
> is trappy and we should either implement it or throw an 
> UnsupportedOperationException instead.



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

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

Re: [JENKINS] Lucene-Solr-Tests-6.x - Build # 32 - Still Failing

[Michael McCandless]

I'll dig.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Mar 9, 2016 at 12:59 PM, Apache Jenkins Server
 wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/32/
>
> 1 tests failed.
> FAILED:  
> org.apache.lucene.search.join.TestBlockJoin.testBugCausedByRewritingTwice
>
> Error Message:
>
>
> Stack Trace:
> java.lang.NullPointerException
> at 
> __randomizedtesting.SeedInfo.seed([F8CC8C8B5953C710:7B05C20D26C1B69]:0)
> at 
> org.apache.lucene.search.join.TestBlockJoin.testBugCausedByRewritingTwice(TestBlockJoin.java:298)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java: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 
> 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)
>
>
>
>
> Build Log:
> [...truncated 7150 lines...]
>[junit4] Suite: org.apache.lucene.search.join.TestBlockJoin
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestBlockJoin 
> -Dtests.method=testBugCausedByRewritingTwice -Dtests.seed=F8CC8C8B5953C710 
> -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sr-BA 
> -Dtests.timezone=Europe/Vienna -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   0.03s J1 | TestBlockJoin.testBugCausedByRewritingTwice <<<
>[junit4]> Throwable #1: 

[jira] [Commented] (SOLR-8770) BinaryRequestWriter interprets null object in field as literal "NULL" string

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8770:


I've gone digging into the code a little bit.  I don't entirely understand what 
I'm looking at.

For the binary writer, I cannot see anything that delves into the individual 
fields of a document, so there's nowhere to add a null check.  The code (in 
JavaBinUpdateRequestCodec) appears to use an iterator to add documents to a 
NamedList.

The code in ClientUtils#writeVal seems to indicate that there might be 
legitimate uses for a null object, as there are certain situations where a null 
will be added to the XML.  I would need to understand other areas of the code 
to know what's going on there.

If there are indeed legitimate uses for a null object in SolrInputDocument 
field, then it will not be possible to throw IAE in SolrInputDocument.


> BinaryRequestWriter interprets null object in field as literal "NULL" string
> 
>
> Key: SOLR-8770
> URL: https://issues.apache.org/jira/browse/SOLR-8770
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 5.5
>Reporter: Shawn Heisey
>
> From what I've been able to determine, if a null object is added with 
> SolrInputDocument#addField, the xml writer does not include that field in the 
> request, but the binary writer sends the literal string "NULL".
> This became apparent when upgrading SolrJ to 5.5, which uses the binary 
> writer by default.  Switching back to 5.4.1 fixed it, until I forced the 
> 5.4.1 client to use the binary writer.  My source data is MySQL.  JDBC is 
> where the null objects are coming from.
> Adding a null check to my doc.addField call has fixed my program with the 5.5 
> client, but this is likely to catch other upgrading users off guard.
> At the very least, the 5.5.1 CHANGES.txt file needs a note, but I believe the 
> behavior of the binary writer should match the behavior of the xml writer.



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

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

[jira] [Created] (SOLR-8813) Add test for MultiValued fields being returned in the correct order

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-8813:


 Summary: Add test for MultiValued fields being returned in the 
correct order
 Key: SOLR-8813
 URL: https://issues.apache.org/jira/browse/SOLR-8813
 Project: Solr
  Issue Type: Improvement
Reporter: Erick Erickson
Assignee: Erick Erickson


This is an outgrowth of SOLR-8740. When we move to returning fields in the 
response from docValues fields, we _may_ break the contract we've had for years 
that multiValued stored fields are returned in the order they were inserted.

This test is here it show the current behavior. If we change the behavior we 
need to clearly document any breaks in back-compat.



--
This message was sent by Atlassian 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-8812) ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND

[Ryan Steinberg (JIRA)]

Ryan Steinberg created SOLR-8812:


 Summary: ExtendedDismaxQParser (edismax) ignores Boolean OR when 
q.op=AND
 Key: SOLR-8812
 URL: https://issues.apache.org/jira/browse/SOLR-8812
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 5.5
Reporter: Ryan Steinberg


The edismax parser ignores Boolean OR in queries when q.op=AND. This behavior 
is new to Solr 5.5.0 and an unexpected major change.

Example:
  "q": "id:12345 OR zz",
  "defType": "edismax",
  "q.op": "AND",
where "12345" is a known document ID and "zz" is a string NOT present 
in my data

Version 5.5.0 produces zero results:
"rawquerystring": "id:12345 OR zz",
"querystring": "id:12345 OR zz",
"parsedquery": "(+((id:12345 
DisjunctionMaxQuery((text:zz)))~2))/no_coord",
"parsedquery_toString": "+((id:12345 (text:zz))~2)",
"explain": {},
"QParser": "ExtendedDismaxQParser"

Version 5.4.0 produces one result as expected
  "rawquerystring": "id:12345 OR zz",
"querystring": "id:12345 OR zz",
"parsedquery": "(+(id:12345 
DisjunctionMaxQuery((text:zz/no_coord",
"parsedquery_toString": "+(id:12345 (text:zz))"
"explain": {},
"QParser": "ExtendedDismaxQParser"




--
This message was sent by Atlassian 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-8811) Deleting inactive replicas doesn't work in non-legacy cloud mode

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8811:

Attachment: SOLR-8811.patch

Here's a patch illustrating the problem.  
DeleteReplicaTest.deleteDeadReplicaTest() fails, because the core doesn't 
notice that it has been unregistered and comes online when it's parent node 
comes back up.

I'm not sure if this is actually fixable, but I'm also not sure that it should 
work in the first place in ZK-is-truth mode.  If a node hosting a replica is 
down, then I think it's reasonable to just return an error when trying to 
delete that node.



> Deleting inactive replicas doesn't work in non-legacy cloud mode
> 
>
> Key: SOLR-8811
> URL: https://issues.apache.org/jira/browse/SOLR-8811
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, master, 6.0
>Reporter: Alan Woodward
>Priority: Minor
> Attachments: SOLR-8811.patch
>
>
> I've been trying to cut some tests over to use SolrCloudTestBase, and have 
> found that DeleteInactiveReplicaTest won't work in non-legacy mode.  This is 
> because the "don't start up if you've been unregistered" logic relies on a 
> coreNodeName not being present, but if the collection has been created via 
> the Collections API then coreNodeName is always set.



--
This message was sent by Atlassian 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-8728) Splitting a shard of a collection created with a rule fails with NPE

[ASF subversion and git services (JIRA)]

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

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

Commit 4faadb625e91b8ef323724855748258570137084 in lucene-solr's branch 
refs/heads/branch_5_5 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4faadb6 ]

SOLR-8728: ReplicaAssigner throws NPE when a partial list of nodes are only 
participating in replica
  placement. splitshard should preassign nodes using rules, if rules are present


> Splitting a shard of a collection created with a rule fails with NPE
> 
>
> Key: SOLR-8728
> URL: https://issues.apache.org/jira/browse/SOLR-8728
> Project: Solr
>  Issue Type: Bug
>Reporter: Shai Erera
>Assignee: Noble Paul
> Fix For: master, 6.0, 5.5.1, 6.1
>
> Attachments: SOLR-8728.patch, SOLR-8728.patch
>
>
> Spinoff from this discussion: http://markmail.org/message/f7liw4hqaagxo7y2
> I wrote a short test which reproduces, will upload shortly.



--
This message was sent by Atlassian 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-8728) Splitting a shard of a collection created with a rule fails with NPE

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-8728:
-
Fix Version/s: 5.5.1

> Splitting a shard of a collection created with a rule fails with NPE
> 
>
> Key: SOLR-8728
> URL: https://issues.apache.org/jira/browse/SOLR-8728
> Project: Solr
>  Issue Type: Bug
>Reporter: Shai Erera
>Assignee: Noble Paul
> Fix For: master, 6.0, 5.5.1, 6.1
>
> Attachments: SOLR-8728.patch, SOLR-8728.patch
>
>
> Spinoff from this discussion: http://markmail.org/message/f7liw4hqaagxo7y2
> I wrote a short test which reproduces, will upload shortly.



--
This message was sent by Atlassian 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-8728) Splitting a shard of a collection created with a rule fails with NPE

[ASF subversion and git services (JIRA)]

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

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

Commit c17f80a7a22a4215ebcfe08939b6c0acc30df7c2 in lucene-solr's branch 
refs/heads/branch_5_5 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c17f80a ]

SOLR-8728


> Splitting a shard of a collection created with a rule fails with NPE
> 
>
> Key: SOLR-8728
> URL: https://issues.apache.org/jira/browse/SOLR-8728
> Project: Solr
>  Issue Type: Bug
>Reporter: Shai Erera
>Assignee: Noble Paul
> Fix For: master, 6.0, 5.5.1, 6.1
>
> Attachments: SOLR-8728.patch, SOLR-8728.patch
>
>
> Spinoff from this discussion: http://markmail.org/message/f7liw4hqaagxo7y2
> I wrote a short test which reproduces, will upload shortly.



--
This message was sent by Atlassian 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-8811) Deleting inactive replicas doesn't work in non-legacy cloud mode

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-8811:
---

 Summary: Deleting inactive replicas doesn't work in non-legacy 
cloud mode
 Key: SOLR-8811
 URL: https://issues.apache.org/jira/browse/SOLR-8811
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.5, master, 6.0
Reporter: Alan Woodward
Priority: Minor


I've been trying to cut some tests over to use SolrCloudTestBase, and have 
found that DeleteInactiveReplicaTest won't work in non-legacy mode.  This is 
because the "don't start up if you've been unregistered" logic relies on a 
coreNodeName not being present, but if the collection has been created via the 
Collections API then coreNodeName is always set.



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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.lucene.search.join.TestBlockJoin.testBugCausedByRewritingTwice

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([F8CC8C8B5953C710:7B05C20D26C1B69]:0)
at 
org.apache.lucene.search.join.TestBlockJoin.testBugCausedByRewritingTwice(TestBlockJoin.java:298)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java: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 
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)




Build Log:
[...truncated 7150 lines...]
   [junit4] Suite: org.apache.lucene.search.join.TestBlockJoin
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestBlockJoin 
-Dtests.method=testBugCausedByRewritingTwice -Dtests.seed=F8CC8C8B5953C710 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sr-BA 
-Dtests.timezone=Europe/Vienna -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.03s J1 | TestBlockJoin.testBugCausedByRewritingTwice <<<
   [junit4]> Throwable #1: java.lang.NullPointerException
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([F8CC8C8B5953C710:7B05C20D26C1B69]:0)
   [junit4]>at 
org.apache.lucene.search.join.TestBlockJoin.testBugCausedByRewritingTwice(TestBlockJoin.java:298)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> NOTE: test 

[jira] [Commented] (SOLR-8728) Splitting a shard of a collection created with a rule fails with NPE

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8728:
--

I guess this should go to the 5.5 branch as well right away. Just in case there 
is a 5.5.1

> Splitting a shard of a collection created with a rule fails with NPE
> 
>
> Key: SOLR-8728
> URL: https://issues.apache.org/jira/browse/SOLR-8728
> Project: Solr
>  Issue Type: Bug
>Reporter: Shai Erera
>Assignee: Noble Paul
> Fix For: master, 6.0, 6.1
>
> Attachments: SOLR-8728.patch, SOLR-8728.patch
>
>
> Spinoff from this discussion: http://markmail.org/message/f7liw4hqaagxo7y2
> I wrote a short test which reproduces, will upload shortly.



--
This message was sent by Atlassian 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

[Alan Woodward]

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.


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

Re: Speculating about the removal of the standalone Solr mode

[Joel Bernstein]

>From Alfresco's point of view this would be a bad thing. Alfresco uses Solr
in stand alone mode and has developed an entire sharding and replication
model that fit's the ECM use case. So being forced to have ZooKeeper and
Solr Cloud would not be ideal.

Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Mar 9, 2016 at 12:34 PM, Shawn Heisey  wrote:

> I've been thinking about the fact that standalone and cloud modes in
> Solr are very different.
>
> The writing on the wall suggests that Solr will eventually (probably 7.0
> minimum) eliminate the standalone mode and always operate with
> zookeeper.  A "standalone" node would in fact be a single-node cloud
> running the embedded zookeeper.
>
> Once zk-as-truth becomes a reality, I can see a few advantages to always
> running in cloud mode.  The documentation can include one way to
> accomplish basic tasks.  The CoreAdmin API can be eliminated, and any
> required functionality fully merged into the Collections API.
> CloudSolrClient will work for all installations.  A script that works
> for cloud mode will also work for standalone mode, because that's just a
> smaller cloud.
>
> I was planning to open an issue to discuss and implement this.  If
> that's not a good idea, please let me know.
>
> None of my main Solr installations are running in cloud mode, so the
> removal of standalone mode will be an inconvenience for me, but I still
> think it's the right thing to do in the long term.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>