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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15187/
Java: 32bit/jdk1.8.0_66 -server -XX:+UseSerialGC

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

Error Message:
Error from server at http://127.0.0.1:53191/implicitcoll2: non ok status: 500, 
message:Server Error

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:53191/implicitcoll2: non ok status: 500, 
message:Server Error
at 
__randomizedtesting.SeedInfo.seed([4C1B38D0325C690A:C44F070A9CA004F2]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:509)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForNon403or404or503(AbstractFullDistribZkTestBase.java:1754)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:173)
at 
org.apache.solr.cloud.CustomCollectionTest.test(CustomCollectionTest.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Created] (SOLR-8523) ImplicitSnitch to support IPv6 based tags

[Arcadius Ahouansou (JIRA)]

Arcadius Ahouansou created SOLR-8523:


 Summary: ImplicitSnitch to support IPv6 based tags
 Key: SOLR-8523
 URL: https://issues.apache.org/jira/browse/SOLR-8523
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 5.4
Reporter: Arcadius Ahouansou
Priority: Minor


Very similar to SOLR-8522, but for IPv6



--
This message was sent by Atlassian 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-8522) ImplicitSnitch to support IPv4 based tags

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou updated SOLR-8522:
-
Summary: ImplicitSnitch to support IPv4 based tags  (was: ImplicitSnitch to 
support IP based tags)

> ImplicitSnitch to support IPv4 based tags
> -
>
> Key: SOLR-8522
> URL: https://issues.apache.org/jira/browse/SOLR-8522
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Arcadius Ahouansou
>Priority: Minor
>
> This is a description from [~noble.paul]'s comment on SOLR-8146
> Lets assume a Solr node IPv4 address is 192.93.255.255 .
> This is about enhancing the current {{ImplicitSnitch}}  to support IP based 
> tags like:
> - {{ip_1 = 192}}
> - {{ip_2 = 93}}
> - {{ip_3 = 255}}
> - {{ip_4 = 255}}
> Note that IPv6 support will be implemented by a separate ticket



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

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

[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 2948 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2948/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication

Error Message:
1

Stack Trace:
java.lang.AssertionError: 1
at 
__randomizedtesting.SeedInfo.seed([FB2B7B5566BB2A95:EF63200045BC978B]:0)
at 
org.apache.solr.core.CachingDirectoryFactory.close(CachingDirectoryFactory.java:202)
at org.apache.solr.core.SolrCore.close(SolrCore.java:1255)
at org.apache.solr.core.SolrCores.close(SolrCores.java:125)
at org.apache.solr.core.CoreContainer.shutdown(CoreContainer.java:582)
at 
org.apache.solr.servlet.SolrDispatchFilter.destroy(SolrDispatchFilter.java:175)
at 
org.eclipse.jetty.servlet.FilterHolder.destroyInstance(FilterHolder.java:173)
at org.eclipse.jetty.servlet.FilterHolder.doStop(FilterHolder.java:151)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at 
org.eclipse.jetty.servlet.ServletHandler.doStop(ServletHandler.java:241)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:162)
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
at 
org.eclipse.jetty.server.session.SessionHandler.doStop(SessionHandler.java:127)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:162)
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
at 
org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:835)
at 
org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:215)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:162)
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
at org.eclipse.jetty.server.Server.doStop(Server.java:456)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.stop(JettySolrRunner.java:444)
at 
org.apache.solr.handler.TestReplicationHandler.tearDown(TestReplicationHandler.java:137)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:929)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.lucene.index.TestDuelingCodecs.testEquals

Error Message:
string [80 0 0 0]max value [80 0 0 a4]  block fp 0 was not created from 
BytesRef.toString?

Stack Trace:
java.lang.IllegalArgumentException: string [80 0 0 0]max value [80 0 0 a4]  
block fp 0 was not created from BytesRef.toString?
at 
__randomizedtesting.SeedInfo.seed([2C3D7D2862162F55:28522EB3AC2F7F57]:0)
at 
org.apache.lucene.codecs.simpletext.SimpleTextUtil.fromBytesRefString(SimpleTextUtil.java:106)
at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalReader.initReader(SimpleTextDimensionalReader.java:97)
at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalReader.(SimpleTextDimensionalReader.java:73)
at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalFormat.fieldsReader(SimpleTextDimensionalFormat.java:45)
at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:128)
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.getReaderForMerge(ReadersAndUpdates.java:617)
at 
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3995)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3642)
at 
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1917)
at 
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2845)
at 
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2950)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2917)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:373)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:305)
at 
org.apache.lucene.index.TestDuelingCodecs.testEquals(TestDuelingCodecs.java:154)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

Re: Lucene/Solr 6.0.0 release

[Jan Høydahl]

+1 for getting the ball rolling and decide a date for branch cutting...

Regarding /v2/ api, isn’t the plan that the new api will co-exist with the old 
for some time?
If so, it would be acceptible to add the /v2/ API in 6.x and deprecate old api 
in 6.y?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 8. jan. 2016 kl. 14.38 skrev Noble Paul :
> 
> I was planning to add SOLR-8029 ( Modernize and standardize Solr APIs) to 6.0
> 
> it is at least 2-3 months away. If the release is planned after
> march I would like to get that in.
> 
> On Fri, Jan 8, 2016 at 1:10 PM, Dawid Weiss  wrote:
>>> I think we should get the ball rolling for our next major release (6.0.0)?
>> 
>> I'd love it to be the first git-based release. :)
>> It'd be a nice milestone change (from infrastructural point of view).
>> Not a blocker, of course.
>> 
>> Dawid
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 
> 
> 
> -- 
> -
> Noble Paul
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[JENKINS] Lucene-Solr-Tests-5.3-Java7 - Build # 18 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.3-Java7/18/

1 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.test

Error Message:
There should be one document because overwrite=true expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: There should be one document because overwrite=true 
expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([A6AF4756EBC10EA1:2EFB788C453D6359]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testOverwriteOption(CloudSolrClientTest.java:141)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
  

Re:svn commit: r1723682 - in /lucene/dev/trunk/lucene: ./ codecs/src/java/org/apache/lucene/codecs/simpletext/ core/src/java/org/apache/lucene/codecs/ core/src/java/org/apache/lucene/codecs/lucene60/

[Christine Poerschke (BLOOMBERG/ LONDON)]

Hello.

Might there be a min-versus-max copy/paste mistake in getMaxPackedValue?

I will try next to see if that fixes recent
org.apache.lucene.index.TestDuelingCodecs test failures.

Christine

- Original Message -
From: dev@lucene.apache.org
To: comm...@lucene.apache.org
At: Jan  8 2016 10:52:29

Author: mikemccand
Date: Fri Jan  8 10:52:15 2016
New Revision: 1723682

URL: http://svn.apache.org/viewvc?rev=1723682=rev
Log:
LUCENE-6962: add min/max per dimension to dimensional values

Modified:
lucene/dev/trunk/lucene/CHANGES.txt

lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextBKDReader.java

lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextDimensionalReader.java

lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextDimensionalWriter.java

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/codecs/DimensionalFormat.java

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/codecs/DimensionalWriter.java

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/codecs/lucene60/Lucene60DimensionalReader.java

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/DimensionalValues.java

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/DimensionalValuesWriter.java

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/MultiDimensionalValues.java

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/ParallelLeafReader.java

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/SlowCodecReaderWrapper.java

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/util/bkd/BKDReader.java

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/util/bkd/BKDWriter.java

lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/index/TestDimensionalValues.java

lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/util/bkd/TestBKD.java

lucene/dev/trunk/lucene/misc/src/java/org/apache/lucene/index/SortingLeafReader.java

lucene/dev/trunk/lucene/test-framework/src/java/org/apache/lucene/codecs/asserting/AssertingDimensionalFormat.java

Modified: lucene/dev/trunk/lucene/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/CHANGES.txt?rev=1723682=1723681=1723682=diff
==
--- lucene/dev/trunk/lucene/CHANGES.txt (original)
+++ lucene/dev/trunk/lucene/CHANGES.txt Fri Jan  8 10:52:15 2016
@@ -55,6 +55,9 @@ New Features
 * LUCENE-6837: Add N-best output support to JapaneseTokenizer.
   (Hiroharu Konno via Christian Moen)
 
+* LUCENE-6962: Add per-dimension min/max to dimensional values
+  (Mike McCandless)
+
 API Changes
 
 * LUCENE-3312: The API of oal.document was restructured to

Modified: 
lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextBKDReader.java
URL: 
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextBKDReader.java?rev=1723682=1723681=1723682=diff
==
--- 
lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextBKDReader.java
 (original)
+++ 
lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextBKDReader.java
 Fri Jan  8 10:52:15 2016
@@ -33,8 +33,9 @@ import static org.apache.lucene.codecs.s
 
 class SimpleTextBKDReader extends BKDReader {
 
-  public SimpleTextBKDReader(IndexInput datIn, int numDims, int 
maxPointsInLeafNode, int bytesPerDim, long[] leafBlockFPs, byte[] 
splitPackedValues) throws IOException {
-super(datIn, numDims, maxPointsInLeafNode, bytesPerDim, leafBlockFPs, 
splitPackedValues);
+  public SimpleTextBKDReader(IndexInput datIn, int numDims, int 
maxPointsInLeafNode, int bytesPerDim, long[] leafBlockFPs, byte[] 
splitPackedValues,
+ byte[] minPackedValue, byte[] maxPackedValue) 
throws IOException {
+super(datIn, numDims, maxPointsInLeafNode, bytesPerDim, leafBlockFPs, 
splitPackedValues, minPackedValue, maxPackedValue);
   }
 
   @Override

Modified: 
lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextDimensionalReader.java
URL: 
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextDimensionalReader.java?rev=1723682=1723681=1723682=diff
==
--- 
lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextDimensionalReader.java
 (original)
+++ 
lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextDimensionalReader.java
 Fri Jan  8 10:52:15 2016
@@ -43,6 +43,8 @@ import static org.apache.lucene.codecs.s
 import static 

Re: Lucene/Solr 6.0.0 release

[Noble Paul]

I was planning to add SOLR-8029 ( Modernize and standardize Solr APIs) to 6.0

 it is at least 2-3 months away. If the release is planned after
march I would like to get that in.

On Fri, Jan 8, 2016 at 1:10 PM, Dawid Weiss  wrote:
>> I think we should get the ball rolling for our next major release (6.0.0)?
>
> I'd love it to be the first git-based release. :)
> It'd be a nice milestone change (from infrastructural point of view).
> Not a blocker, of course.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



-- 
-
Noble Paul

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

[jira] [Updated] (SOLR-8184) Negative tests for JDBC Connection String

[Jason Gerlowski (JIRA)]

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

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

Updated patch takes the approach mentioned in the comments above (drop 
duplicate test, move tests into JdbcDriverTest where possible, fold remaining 
test into same test case of JdbcTest).

Should be ready to go as far as I know, unless anyone knows of error cases 
they'd like covered by this story?

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>Reporter: Susheel Kumar
>Priority: Minor
> Attachments: SOLR-8184.patch, SOLR-8184.patch, SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
This message was sent by Atlassian 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-8479) Add JDBCStream for integration with external data sources

[ASF subversion and git services (JIRA)]

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

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

Commit 1723749 from dpg...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1723749 ]

OLR-8479: Add JDBCStream to Streaming API and Streaming Expressions for 
integration with external data sources
SOLR-8479: Add JDBCStream to Streaming API and Streaming Expressions for 
integration with external data sources

> Add JDBCStream for integration with external data sources
> -
>
> Key: SOLR-8479
> URL: https://issues.apache.org/jira/browse/SOLR-8479
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-8479.patch, SOLR-8479.patch, SOLR-8479.patch, 
> SOLR-8479.patch, SOLR-8479.patch
>
>
> Given that the Streaming API can merge and join multiple incoming SolrStreams 
> to perform complex operations on the resulting combined datasets I think it 
> would be beneficial to also support incoming streams from other data sources. 
> The JDBCStream will provide a Streaming API interface to any data source 
> which provides a JDBC driver.



--
This message was sent by Atlassian 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-8514) Implement StatementImpl.execute(String sql), StatementImpl.getResultSet(), and StatementImpl.getUpdateCount()

[Kevin Risden (JIRA)]

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

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

Added initial implementation. This reuses executeQuery() and just stores the 
last SQL statement to come in. Solr doesn't have a way to currently execute a 
query and then get the results back later.

> Implement StatementImpl.execute(String sql), StatementImpl.getResultSet(), 
> and StatementImpl.getUpdateCount()
> -
>
> Key: SOLR-8514
> URL: https://issues.apache.org/jira/browse/SOLR-8514
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8514.patch
>
>
> Currently only StatementImpl.executeQuery is implemented.



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

[Dennis Gove]

Thanks Erick. It appears that the following was able to work for me

$ svn propedit -r 1723749 --revprop svn:log
[[ make edit in vi and save/close ]]
Set new value for property 'svn:log' on revision 1723749

On Fri, Jan 8, 2016 at 11:18 AM, Erick Erickson 
wrote:

> Personally since the comment is in the JIRA I can live with it ;)
>
> WARNING: I haven't tried this myself, but I did find:
>
> svn propedit svn:log --revprop -r NNN
>
> see: http://subversion.apache.org/faq.html#change-log-msg
>
> From a quick scan there might be permissions or some such
> necessary so it may give you some kind of "access denied".
>
> I'd try it and if it didn't work after 10 minutes give up.
> The information is in the message so it doesn't seem worth
> too much effort IMO.
>
> Best,
> Erick
>
> On Fri, Jan 8, 2016 at 8:06 AM, Dennis Gove  wrote:
> > Is it possible to update an svn commit message? In commit 1723749 for
> > https://issues.apache.org/jira/browse/SOLR-8479 I accidentally
> double-posted
> > my commit message in the vi editor (though the first line is missing the
> > first character) and didn't notice before committing.
> >
> > Any chance I can edit the commit message now without screwing anything
> up?
> >
> > Thanks - Dennis
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (LUCENE-6854) Provide extraction of more metrics from confusion matrix

[ASF subversion and git services (JIRA)]

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

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

Commit 1723759 from [~teofili] in branch 'dev/trunk'
[ https://svn.apache.org/r1723759 ]

LUCENE-6854 - adjusted precision calculation, minor fix in SNBC test

> Provide extraction of more metrics from confusion matrix
> 
>
> Key: LUCENE-6854
> URL: https://issues.apache.org/jira/browse/LUCENE-6854
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/classification
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Trunk
>
>
> {{ConfusionMatrix}} only provides a general accuracy measure while it'd be 
> good to be able to extract more metrics from it, for specific classes, like 
> precision, recall, f-measure, 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] [Assigned] (SOLR-8479) Add JDBCStream for integration with external data sources

[Dennis Gove (JIRA)]

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

Dennis Gove reassigned SOLR-8479:
-

Assignee: Dennis Gove

> Add JDBCStream for integration with external data sources
> -
>
> Key: SOLR-8479
> URL: https://issues.apache.org/jira/browse/SOLR-8479
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-8479.patch, SOLR-8479.patch, SOLR-8479.patch, 
> SOLR-8479.patch, SOLR-8479.patch
>
>
> Given that the Streaming API can merge and join multiple incoming SolrStreams 
> to perform complex operations on the resulting combined datasets I think it 
> would be beneficial to also support incoming streams from other data sources. 
> The JDBCStream will provide a Streaming API interface to any data source 
> which provides a JDBC driver.



--
This message was sent by Atlassian 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-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6908:


[~nknize] can this be resolved?

> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
> 
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch, LUCENE-6908.patch, 
> LUCENE-6908.patch, LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of 
> GeoPoint*Query as its using the BKD split technique (instead of quad cell 
> division) to divide the space on each pass. For "large" distance queries this 
> can create a lot of irregular rectangles producing large radial distortion 
> error when using the cartesian approximation methods provided by 
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian 
> approximation methods on irregular rectangles without having to cut over to 
> an expensive oblate geometry approach.



--
This message was sent by Atlassian 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-8515) Implement StatementImpl.getConnection

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8515:


Requires ConnectionImpl.getCatalog() from SOLR-8503

> Implement StatementImpl.getConnection
> -
>
> Key: SOLR-8515
> URL: https://issues.apache.org/jira/browse/SOLR-8515
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>




--
This message was sent by Atlassian 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-8516) Implement ResultSetImpl.getStatement

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8516:
---
Flags: Patch

> Implement ResultSetImpl.getStatement
> 
>
> Key: SOLR-8516
> URL: https://issues.apache.org/jira/browse/SOLR-8516
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8516.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] (SOLR-8516) Implement ResultSetImpl.getStatement

[Kevin Risden (JIRA)]

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

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

Added initial implementation patch. Passes the StatementImpl object into the 
ResultSet to enable getStatement().

> Implement ResultSetImpl.getStatement
> 
>
> Key: SOLR-8516
> URL: https://issues.apache.org/jira/browse/SOLR-8516
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8516.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] [Commented] (SOLR-8502) Improve Solr JDBC Driver to support SQL Clients like DBVisualizer

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8502:
--

It looks like the jira filter is private. You can also just list the jira's 
that are ready for review.

This is a high priority for Solr 6. So I'll definitely work with you to get the 
code reviewed and ready to be committed.  


> Improve Solr JDBC Driver to support SQL Clients like DBVisualizer
> -
>
> Key: SOLR-8502
> URL: https://issues.apache.org/jira/browse/SOLR-8502
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>  Labels: jdbc
>
> Currently when trying to connect to Solr with the JDBC driver with a SQL 
> client the driver must implement more methods and metadata to allow 
> connections. This JIRA is designed to act as an umbrella for the JDBC changes.
> An initial pass from a few months ago is here: 
> https://github.com/risdenk/lucene-solr/tree/expand-jdbc. This needs to be 
> broken up and create patches for the related sub tasks.



--
This message was sent by Atlassian 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-6944) BooleanWeight.bulkScorer should not build any sub bulk scorer if there are required/prohibited clauses

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6944:


[~jpountz] can this be resolved now?

> BooleanWeight.bulkScorer should not build any sub bulk scorer if there are 
> required/prohibited clauses
> --
>
> Key: LUCENE-6944
> URL: https://issues.apache.org/jira/browse/LUCENE-6944
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: LUCENE-6944.patch
>
>
> BooleanWeight.bulkScorer creates a sub bulk scorer for all clauses until it 
> meets a clause that is not optional (the only kind of clause it can deal 
> with). However the Weight.bulkScorer method is sometimes costly, so 
> BooleanWeight.bulkScorer should first inspect all clauses to see if any of 
> them is not optional to avoid creating costly bulk scorers to only trash them 
> later.



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

[Shawn Heisey]

On 1/8/2016 8:13 AM, Shawn Heisey wrote:
> I've only been paying attention to commits for one new major release, so
> I can offer some info on 5.0, but not any of the previous major releases.
> 
> Robert created branch_5x on 2014/09/18.  Version 5.0.0 was released on
> 2015/02/20.  That's five months from new branch to new major release.

Turns out I *do* have information in my email history for 4.x.  Robert
created branch_4x on 2012/05/29.  The 4.0.0 release was announced on
2012/10/12 -- four and a half months later.

Thanks,
Shawn


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

[jira] [Updated] (SOLR-8514) Implement StatementImpl.execute(String sql), StatementImpl.getResultSet(), and StatementImpl.getUpdateCount()

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8514:
---
Summary: Implement StatementImpl.execute(String sql), 
StatementImpl.getResultSet(), and StatementImpl.getUpdateCount()  (was: 
Implement StatementImpl.execute(String sql) and StatementImpl.getResultSet())

> Implement StatementImpl.execute(String sql), StatementImpl.getResultSet(), 
> and StatementImpl.getUpdateCount()
> -
>
> Key: SOLR-8514
> URL: https://issues.apache.org/jira/browse/SOLR-8514
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>
> Currently only StatementImpl.executeQuery is implemented.



--
This message was sent by Atlassian 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-8515) Implement StatementImpl.getConnection

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8515:
---
Flags: Patch

> Implement StatementImpl.getConnection
> -
>
> Key: SOLR-8515
> URL: https://issues.apache.org/jira/browse/SOLR-8515
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8515.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] (SOLR-8526) Reuse Lucene.FieldType instances

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-8526:
---
Description: 
When lucene created FieldType (not to be confused with Solr's FieldType), Solr 
was ported by simply creating a new lucene.FieldType instance for every field 
indexed (see solr.FieldType.createField())

To avoid creating every time, Solr's SchemaField (which is already analagous to 
lucene.FieldType) can simply implement that interface.

  was:
When lucene created FieldType (not to be confused with Solr's FieldType), Solr 
was ported by simply creating a new lucene.FieldType instance for every field 
indexed.

To avoid creating every time, Solr's SchemaField (which is already analagous to 
lucene.FieldType) can simply implement that interface.


> Reuse Lucene.FieldType instances
> 
>
> Key: SOLR-8526
> URL: https://issues.apache.org/jira/browse/SOLR-8526
> Project: Solr
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>
> When lucene created FieldType (not to be confused with Solr's FieldType), 
> Solr was ported by simply creating a new lucene.FieldType instance for every 
> field indexed (see solr.FieldType.createField())
> To avoid creating every time, Solr's SchemaField (which is already analagous 
> to lucene.FieldType) can simply implement that interface.



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+95) - Build # 15484 - Still Failing!

[Policeman Jenkins Server]

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

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

Error Message:
Didn't see all replicas for shard shard1 in c8n_1x2 come up within 3 ms! 
ClusterState: {   "collection1":{ "replicationFactor":"1", "shards":{   
"shard1":{ "range":"8000-", "state":"active",   
  "replicas":{"core_node2":{ "core":"collection1", 
"base_url":"http://127.0.0.1:37914;, 
"node_name":"127.0.0.1:37914_", "state":"active", 
"leader":"true"}}},   "shard2":{ "range":"0-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"collection1", "base_url":"http://127.0.0.1:42728;,  
   "node_name":"127.0.0.1:42728_", "state":"active", 
"leader":"true"},   "core_node3":{ "core":"collection1",
 "base_url":"http://127.0.0.1:33470;, 
"node_name":"127.0.0.1:33470_", "state":"active", 
"router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false", "autoCreated":"true"},   "control_collection":{  
   "replicationFactor":"1", "shards":{"shard1":{ 
"range":"8000-7fff", "state":"active", 
"replicas":{"core_node1":{ "core":"collection1", 
"base_url":"http://127.0.0.1:54641;, 
"node_name":"127.0.0.1:54641_", "state":"active", 
"leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false", 
"autoCreated":"true"},   "c8n_1x2":{ "replicationFactor":"2", 
"shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"c8n_1x2_shard1_replica2", 
"base_url":"http://127.0.0.1:37914;, 
"node_name":"127.0.0.1:37914_", "state":"recovering"},   
"core_node2":{ "core":"c8n_1x2_shard1_replica1", 
"base_url":"http://127.0.0.1:54641;, 
"node_name":"127.0.0.1:54641_", "state":"active", 
"leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false"},   "collMinRf_1x3":{ 
"replicationFactor":"3", "shards":{"shard1":{ 
"range":"8000-7fff", "state":"active", "replicas":{ 
  "core_node1":{ "core":"collMinRf_1x3_shard1_replica3",
 "base_url":"http://127.0.0.1:54641;, 
"node_name":"127.0.0.1:54641_", "state":"active"},   
"core_node2":{ "core":"collMinRf_1x3_shard1_replica2", 
"base_url":"http://127.0.0.1:33470;, 
"node_name":"127.0.0.1:33470_", "state":"active"},   
"core_node3":{ "core":"collMinRf_1x3_shard1_replica1", 
"base_url":"http://127.0.0.1:42728;, 
"node_name":"127.0.0.1:42728_", "state":"active", 
"leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false"}}

Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in c8n_1x2 
come up within 3 ms! ClusterState: {
  "collection1":{
"replicationFactor":"1",
"shards":{
  "shard1":{
"range":"8000-",
"state":"active",
"replicas":{"core_node2":{
"core":"collection1",
"base_url":"http://127.0.0.1:37914;,
"node_name":"127.0.0.1:37914_",
"state":"active",
"leader":"true"}}},
  "shard2":{
"range":"0-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:42728;,
"node_name":"127.0.0.1:42728_",
"state":"active",
"leader":"true"},
  "core_node3":{
"core":"collection1",
"base_url":"http://127.0.0.1:33470;,
"node_name":"127.0.0.1:33470_",
"state":"active",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true"},
  "control_collection":{
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:54641;,
"node_name":"127.0.0.1:54641_",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",

[jira] [Updated] (SOLR-8515) Implement StatementImpl.getConnection

[Kevin Risden (JIRA)]

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

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

Fixed issue with JdbcTest and getting properties.

> Implement StatementImpl.getConnection
> -
>
> Key: SOLR-8515
> URL: https://issues.apache.org/jira/browse/SOLR-8515
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8515.patch, SOLR-8515.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] [Comment Edited] (SOLR-8184) Negative tests for JDBC Connection String

[Kevin Risden (JIRA)]

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

Kevin Risden edited comment on SOLR-8184 at 1/8/16 3:15 PM:


What is this testing for exactly? It looks like the connection string will be 
valid? A SQLException will be thrown because it can't connect to the cluster 
though.
{code}
+  @Test(expected = SQLException.class)
+  public void testConnectionStringJumbled() throws Exception {
+final String sampleZkHost="zoo1:9983/foo";
+DriverManager.getConnection("solr:jdbc://" + sampleZkHost + 
"?collection=collection1", new Properties());
+  }
{code}


was (Author: risdenk):
What is this testing for exactly? It looks like the connection string will be 
valid? A SQLException will be thrown because it can't connect to the cluster 
though.
{quote}
+  \@Test(expected = SQLException.class)
+  public void testConnectionStringJumbled() throws Exception \{
+final String sampleZkHost="zoo1:9983/foo";
+DriverManager.getConnection("solr:jdbc://" + sampleZkHost + 
"?collection=collection1", new Properties());
+  }
{quote}

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>Reporter: Susheel Kumar
>Priority: Minor
> Attachments: SOLR-8184.patch, SOLR-8184.patch, SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
This message was sent by Atlassian 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-8184) Negative tests for JDBC Connection String

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-8184:
---

My understanding is that a legit connection string starts with: 
{{jdbc://solr}}.  This test has the position of "solr" and "jdbc" swapped (i.e. 
{{solr:jdbc://}}).  So this connection string *will* cause an exception, even 
before the ZK host is parsed out and a connection is attempted.

If you think this isn't clear enough, I'm happy to rename the method name (I 
kept the name from the initial patch).  Or maybe assert on the exception 
message to make it clear that this isn't zk-related.

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>Reporter: Susheel Kumar
>Priority: Minor
> Attachments: SOLR-8184.patch, SOLR-8184.patch, SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
This message was sent by Atlassian 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-6938) Convert build to work with Git rather than SVN.

[Mark Miller (JIRA)]

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

Mark Miller commented on LUCENE-6938:
-

bq. I think this is an improvement, not a requirement? 

I think because we had this feature with svn and there is no consensus about 
dropping it and it affects releases, we want it before the move. I'm sure it 
will be simple to add.

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



--
This message was sent by Atlassian 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-8184) Negative tests for JDBC Connection String

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8184:


Yea whats really happening is that the DriverManager can't actually find a 
driver that supports that url string. The method that is getting tested is 
Driver#acceptsURL.

{code}
java.sql.SQLException: No suitable driver found for 
solr:jdbc://zoo1:9983/foo?collection=collection1
{code}

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>Reporter: Susheel Kumar
>Priority: Minor
> Attachments: SOLR-8184.patch, SOLR-8184.patch, SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
This message was sent by Atlassian 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-6951) GeoPointInPolygonQuery can be improved

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6951:


[~nknize] can this issue be resolved now?

> GeoPointInPolygonQuery can be improved
> --
>
> Key: LUCENE-6951
> URL: https://issues.apache.org/jira/browse/LUCENE-6951
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6951.patch
>
>
> {{GeoRelationutils}} uses a basic algebraic approach for computing if (and 
> where) a rectangle crosses a polygon by checking the line segments of both 
> the polygon and rectangle. The current suboptimal line crossing approach can 
> be greatly improved by exploiting the orientation of the lines and endpoints. 
> If the endpoints of one line are on different "sides" of the line segment 
> then  the two may cross. 



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

[Erick Erickson]

What do people thing about waiting to cut the branch until someone has
something that shouldn't go into 6.0? Committing will be easier that
way.

No biggie, maybe Mike's purpose is served by the notice "get your
stuff in trunk that you want to go in 6.0 Real Soon Now" ;)

As always, since I'm not volunteering to be the RM, I'll be happy with
whatever people decide

On Fri, Jan 8, 2016 at 7:51 AM, Shawn Heisey  wrote:
> On 1/8/2016 8:13 AM, Shawn Heisey wrote:
>> I've only been paying attention to commits for one new major release, so
>> I can offer some info on 5.0, but not any of the previous major releases.
>>
>> Robert created branch_5x on 2014/09/18.  Version 5.0.0 was released on
>> 2015/02/20.  That's five months from new branch to new major release.
>
> Turns out I *do* have information in my email history for 4.x.  Robert
> created branch_4x on 2012/05/29.  The 4.0.0 release was announced on
> 2012/10/12 -- four and a half months later.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Commented] (SOLR-8505) core/DirectoryFactory.LOCK_TYPE_HDFS - add & use it instead of String literals

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8505: core/DirectoryFactory.LOCK_TYPE_HDFS - add & use it instead of 
String literals (merge in revision 1723751 from trunk)

> core/DirectoryFactory.LOCK_TYPE_HDFS - add & use it instead of String literals
> --
>
> Key: SOLR-8505
> URL: https://issues.apache.org/jira/browse/SOLR-8505
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8505.patch
>
>
> * Add {{core/DirectoryFactory.LOCK_TYPE_HDFS}}, other 
> {{core/DirectoryFactory.LOCK_TYPE_*}} values already exist.
> * Extend {{DirectoryFactoryTest.testLockTypesUnchanged}} to account for 
> LOCK_TYPE_HDFS.
> * Change {{SolrIndexConfigTest.testToMap}} to also consider 
> "hdfs"/LOCK_TYPE_HDFS.



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

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

[jira] [Closed] (SOLR-8485) SelectStream only works with all lowercase field names and doesn't handle quoted selected fields

[Dennis Gove (JIRA)]

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

Dennis Gove closed SOLR-8485.
-
   Resolution: Fixed
Fix Version/s: Trunk

> SelectStream only works with all lowercase field names and doesn't handle 
> quoted selected fields
> 
>
> Key: SOLR-8485
> URL: https://issues.apache.org/jira/browse/SOLR-8485
> Project: Solr
>  Issue Type: Bug
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Minor
>  Labels: streaming
> Fix For: Trunk
>
> Attachments: SOLR-8485.patch, SOLR-8485.patch, SOLR-8485.patch
>
>
> Three issues exist if one creates a SelectStream with an expression.
> {code}
> select(
>   search(collection1, fl="personId_i,rating_f", q="rating_f:*", 
> sort="personId_i asc"),
>   personId_i as personId,
>   rating_f as rating
> )
> {code}
> "personId_i as personId" will be parsed as "personid_i as personid"
> 1. The incoming tuple will contain a field "personId_i" but the selection 
> will be looking for a field "personid_i". This field won't be found in the 
> incoming tuple (notice the case difference) and as such no field personId 
> will exist in the outgoing tuple.
> 2. If (1) wasn't an issue, the outgoing tuple would have in a field 
> "personid" and not the expected "personId" (notice the case difference). This 
> can lead to other down-the-road issues.
> 3. Also, if one were to quote the selected fields such as in
> {code}
> select(
>   search(collection1, fl="personId_i,rating_f", q="rating_f:*", 
> sort="personId_i asc"),
>   "personId_i as personId",
>   "rating_f as rating"
> )
> {code}
> then the quotes would be included in the field name. Wrapping quotes should 
> be handled properly such that they are removed from the parameters before 
> they are parsed.



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

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

[jira] [Resolved] (LUCENE-6960) TestUninvertingReader.testFieldInfos() failure

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-6960.

   Resolution: Fixed
Fix Version/s: Trunk
   5.5

Thanks [~ichattopadhyaya], I just committed your patch.

This seed uses SimpleText codec which does not set the per-field field infos 
att.

> TestUninvertingReader.testFieldInfos() failure
> --
>
> Key: LUCENE-6960
> URL: https://issues.apache.org/jira/browse/LUCENE-6960
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.5, Trunk
>Reporter: Steve Rowe
> Fix For: 5.5, Trunk
>
> Attachments: LUCENE-6960.patch
>
>
> My Jenkins found a reproducible seed for 
> {{TestUninvertingReader.testFieldInfos()}} - fails on both branch_5x and 
> trunk:
> {noformat}
>[junit4] Suite: org.apache.lucene.uninverting.TestUninvertingReader
>[junit4]   2> NOTE: download the large Jenkins line-docs file by running 
> 'ant get-jenkins-line-docs' in the lucene directory.
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestUninvertingReader -Dtests.method=testFieldInfos 
> -Dtests.seed=349A6776161E26B5 -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=sr_ME -Dtests.timezone=US/Indiana-Starke -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.31s | TestUninvertingReader.testFieldInfos <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<0> but 
> was:
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([349A6776161E26B5:24AE58B19B3CAD1C]:0)
>[junit4]>at 
> org.apache.lucene.uninverting.TestUninvertingReader.testFieldInfos(TestUninvertingReader.java:385)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: codec=SimpleText, 
> sim=ClassicSimilarity, locale=sr_ME, timezone=US/Indiana-Starke
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_45 (64-bit)/cpus=16,threads=1,free=412590336,total=514850816
>[junit4]   2> NOTE: All tests run in this JVM: [TestUninvertingReader]
>[junit4] Completed [1/1 (1!)] in 0.47s, 1 test, 1 failure <<< FAILURES!
> {noformat}



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

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

[jira] [Created] (SOLR-8524) group.field= gives weird values in groupValue

[Tadas Dailyda (JIRA)]

Tadas Dailyda created SOLR-8524:
---

 Summary: group.field= gives weird values in 
groupValue
 Key: SOLR-8524
 URL: https://issues.apache.org/jira/browse/SOLR-8524
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 5.3.1
 Environment: CentOS 7
Reporter: Tadas Dailyda
Priority: Minor


I have field *first_letter* of type *ICUCollationField* and I do group query 
like so:

q=*:*=true=first_letter=first_letter=first_letter+asc

And get smth like this:
{code:javascript}
"grouped": {
"first_letter": {
  "matches": 138,
  "groups": [
{
  "groupValue": ")\u",
  "doclist": {
"numFound": 3,
"start": 0,
"docs": [
  {
"first_letter": "A"
  }
]
  }
},
{
  "groupValue": "+\u",
  "doclist": {
"numFound": 27,
"start": 0,
"docs": [
  {
"first_letter": "B"
  }
]
  }
},

{code}

Letters are obviously stored as they shoud be, and sorting works fine.



--
This message was sent by Atlassian 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: how to search miilions of record in Lucene query

[Mugeesh Husain]

@Uwe Schindler thank for your reply,

if i search (1,6,9...upto millions ) of files , response time will be too
late,

if i use TermsQuery, response time near about 1.2 second , but i am looking
for a solution, response will be 50-100 mili second.


Please suggest me how i will solve these issue or i should write custom
query parser n how ? 



--
View this message in context: 
http://lucene.472066.n3.nabble.com/how-to-search-miilions-of-record-in-Lucene-query-tp4249341p4249441.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

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

[jira] [Commented] (LUCENE-6922) Improve svn to git workaround script

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6922:


Thanks [~paul.elsc...@xs4all.nl], I committed your last patch.

> Improve svn to git workaround script
> 
>
> Key: LUCENE-6922
> URL: https://issues.apache.org/jira/browse/LUCENE-6922
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: -tools
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-6922.patch, svnBranchToGit.py, svnBranchToGit.py
>
>
> As the git-svn mirror for Lucene/Solr will be turned off near the end of 
> 2015, try and improve the workaround script to become more usable.



--
This message was sent by Atlassian 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-6922) Improve svn to git workaround script

[ASF subversion and git services (JIRA)]

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

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

Commit 1723748 from [~mikemccand] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1723748 ]

LUCENE-6922: more improvements in the svn to git mirror workaround tool

> Improve svn to git workaround script
> 
>
> Key: LUCENE-6922
> URL: https://issues.apache.org/jira/browse/LUCENE-6922
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: -tools
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-6922.patch, svnBranchToGit.py, svnBranchToGit.py
>
>
> As the git-svn mirror for Lucene/Solr will be turned off near the end of 
> 2015, try and improve the workaround script to become more usable.



--
This message was sent by Atlassian 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-8479) Add JDBCStream for integration with external data sources

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-8479:
---

This looks awesome.

Only comment would be that we might regret not having a test chaining 
JDBCStream and UpdateStream together.

As Joel mentioned, one of the interesting possibilities here is quick 
data-import using those two streams.  Just thought it might be nice to have a 
test to catch any future regressions there.

Maybe it's not worth it though, or adding tests should be pushed to a different 
JIRA (since it looks like you're already working on committing this, and I'm 
commenting at the 11th hour here).

> Add JDBCStream for integration with external data sources
> -
>
> Key: SOLR-8479
> URL: https://issues.apache.org/jira/browse/SOLR-8479
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-8479.patch, SOLR-8479.patch, SOLR-8479.patch, 
> SOLR-8479.patch, SOLR-8479.patch
>
>
> Given that the Streaming API can merge and join multiple incoming SolrStreams 
> to perform complex operations on the resulting combined datasets I think it 
> would be beneficial to also support incoming streams from other data sources. 
> The JDBCStream will provide a Streaming API interface to any data source 
> which provides a JDBC driver.



--
This message was sent by Atlassian 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-8479) Add JDBCStream for integration with external data sources

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski edited comment on SOLR-8479 at 1/8/16 4:01 PM:
---

This looks awesome.

Only comment would be that we might regret not having a test chaining 
JDBCStream and UpdateStream together.

As Joel mentioned, one of the interesting possibilities here is quick 
data-import using those two streams.  Just thought it might be nice to have a 
test to catch any future regressions there.

Maybe it's not worth it though, or adding tests should be pushed to a different 
JIRA (since it looks like you're already working on committing this, and I'm 
commenting at the 11th hour here).

Oops, looks like I'm too late here.  Nevermind then : )


was (Author: gerlowskija):
This looks awesome.

Only comment would be that we might regret not having a test chaining 
JDBCStream and UpdateStream together.

As Joel mentioned, one of the interesting possibilities here is quick 
data-import using those two streams.  Just thought it might be nice to have a 
test to catch any future regressions there.

Maybe it's not worth it though, or adding tests should be pushed to a different 
JIRA (since it looks like you're already working on committing this, and I'm 
commenting at the 11th hour here).

> Add JDBCStream for integration with external data sources
> -
>
> Key: SOLR-8479
> URL: https://issues.apache.org/jira/browse/SOLR-8479
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-8479.patch, SOLR-8479.patch, SOLR-8479.patch, 
> SOLR-8479.patch, SOLR-8479.patch
>
>
> Given that the Streaming API can merge and join multiple incoming SolrStreams 
> to perform complex operations on the resulting combined datasets I think it 
> would be beneficial to also support incoming streams from other data sources. 
> The JDBCStream will provide a Streaming API interface to any data source 
> which provides a JDBC driver.



--
This message was sent by Atlassian 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-8514) Implement StatementImpl.execute(String sql), StatementImpl.getResultSet(), and StatementImpl.getUpdateCount()

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8514:
---
Flags: Patch

> Implement StatementImpl.execute(String sql), StatementImpl.getResultSet(), 
> and StatementImpl.getUpdateCount()
> -
>
> Key: SOLR-8514
> URL: https://issues.apache.org/jira/browse/SOLR-8514
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8514.patch
>
>
> Currently only StatementImpl.executeQuery is implemented.



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

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

Update commit message

[Dennis Gove]

Is it possible to update an svn commit message? In commit 1723749 for
https://issues.apache.org/jira/browse/SOLR-8479 I accidentally
double-posted my commit message in the vi editor (though the first line is
missing the first character) and didn't notice before committing.

Any chance I can edit the commit message now without screwing anything up?

Thanks - Dennis

Re: Update commit message

[Erick Erickson]

Personally since the comment is in the JIRA I can live with it ;)

WARNING: I haven't tried this myself, but I did find:

svn propedit svn:log --revprop -r NNN

see: http://subversion.apache.org/faq.html#change-log-msg

>From a quick scan there might be permissions or some such
necessary so it may give you some kind of "access denied".

I'd try it and if it didn't work after 10 minutes give up.
The information is in the message so it doesn't seem worth
too much effort IMO.

Best,
Erick

On Fri, Jan 8, 2016 at 8:06 AM, Dennis Gove  wrote:
> Is it possible to update an svn commit message? In commit 1723749 for
> https://issues.apache.org/jira/browse/SOLR-8479 I accidentally double-posted
> my commit message in the vi editor (though the first line is missing the
> first character) and didn't notice before committing.
>
> Any chance I can edit the commit message now without screwing anything up?
>
> Thanks - Dennis

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

Re: Lucene/Solr 6.0.0 release

[Ishan Chattopadhyaya]

Couple of items that I am working on that I would like to see in 6.0:
SOLR-5944: Updatable DocValues in Solr
SOLR-8396: Using Dimensional values in Solr

The first one needs some more tests, maybe some refactoring and reviews.
The second one requires some dev work, it is at a very early stage. I think
(please correct me if I'm wrong) we should have dimensional fields in for
Solr 6.0 since the regular numeric fields are now deprecated and
dimensional fields are the way forward.

Regards,
Ishan


On Fri, Jan 8, 2016 at 9:41 PM, Erick Erickson 
wrote:

> What do people thing about waiting to cut the branch until someone has
> something that shouldn't go into 6.0? Committing will be easier that
> way.
>
> No biggie, maybe Mike's purpose is served by the notice "get your
> stuff in trunk that you want to go in 6.0 Real Soon Now" ;)
>
> As always, since I'm not volunteering to be the RM, I'll be happy with
> whatever people decide
>
> On Fri, Jan 8, 2016 at 7:51 AM, Shawn Heisey  wrote:
> > On 1/8/2016 8:13 AM, Shawn Heisey wrote:
> >> I've only been paying attention to commits for one new major release, so
> >> I can offer some info on 5.0, but not any of the previous major
> releases.
> >>
> >> Robert created branch_5x on 2014/09/18.  Version 5.0.0 was released on
> >> 2015/02/20.  That's five months from new branch to new major release.
> >
> > Turns out I *do* have information in my email history for 4.x.  Robert
> > created branch_4x on 2012/05/29.  The 4.0.0 release was announced on
> > 2012/10/12 -- four and a half months later.
> >
> > Thanks,
> > Shawn
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Lucene/Solr 6.0.0 release

[Erick Erickson]

OK, does this sound like an umbrella JIRA (maybe one for Lucene and
one for Solr) for "Things to add for 6.0" to anybody else as a way of
organizing?

On Fri, Jan 8, 2016 at 8:21 AM, Ishan Chattopadhyaya
 wrote:
> Couple of items that I am working on that I would like to see in 6.0:
> SOLR-5944: Updatable DocValues in Solr
> SOLR-8396: Using Dimensional values in Solr
>
> The first one needs some more tests, maybe some refactoring and reviews.
> The second one requires some dev work, it is at a very early stage. I think
> (please correct me if I'm wrong) we should have dimensional fields in for
> Solr 6.0 since the regular numeric fields are now deprecated and dimensional
> fields are the way forward.
>
> Regards,
> Ishan
>
>
> On Fri, Jan 8, 2016 at 9:41 PM, Erick Erickson 
> wrote:
>>
>> What do people thing about waiting to cut the branch until someone has
>> something that shouldn't go into 6.0? Committing will be easier that
>> way.
>>
>> No biggie, maybe Mike's purpose is served by the notice "get your
>> stuff in trunk that you want to go in 6.0 Real Soon Now" ;)
>>
>> As always, since I'm not volunteering to be the RM, I'll be happy with
>> whatever people decide
>>
>> On Fri, Jan 8, 2016 at 7:51 AM, Shawn Heisey  wrote:
>> > On 1/8/2016 8:13 AM, Shawn Heisey wrote:
>> >> I've only been paying attention to commits for one new major release,
>> >> so
>> >> I can offer some info on 5.0, but not any of the previous major
>> >> releases.
>> >>
>> >> Robert created branch_5x on 2014/09/18.  Version 5.0.0 was released on
>> >> 2015/02/20.  That's five months from new branch to new major release.
>> >
>> > Turns out I *do* have information in my email history for 4.x.  Robert
>> > created branch_4x on 2012/05/29.  The 4.0.0 release was announced on
>> > 2012/10/12 -- four and a half months later.
>> >
>> > Thanks,
>> > Shawn
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

[jira] [Commented] (SOLR-8453) Jetty update from 9.2 to 9.3 causes the server to reset formerly legitimate client connections.

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8453:


bq.  I guess the HttpClient could potentially do better by making the status 
received in the response available, but then it is in a race because the close 
may occur prior to the response being read/parsed/processed.

Not sure I understand this part.  At the OS/socket level, the server can send 
the response and immediately close the socket, and the client (if written 
properly) can always read the response.

> Jetty update from 9.2 to 9.3 causes the server to reset formerly legitimate 
> client connections.
> ---
>
> Key: SOLR-8453
> URL: https://issues.apache.org/jira/browse/SOLR-8453
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-8453.patch, SOLR-8453.patch, SOLR-8453.patch, 
> SOLR-8453.patch, SOLR-8453.patch, SOLR-8453.patch, SOLR-8453.patch, 
> SOLR-8453.patch, SOLR-8453_test.patch, SOLR-8453_test.patch, jetty9.2.pcapng, 
> jetty9.3.pcapng
>
>
> The basic problem is that when we are streaming in updates via a client, an 
> update can fail in a way that further updates in the request will not be 
> processed, but not in a way that causes the client to stop and finish up the 
> request before the server does something else with that connection.
> This seems to mean that even after the server stops processing the request, 
> the concurrent update client is still in the process of sending the request. 
> It seems previously, Jetty would not go after the connection very quickly 
> after the server processing thread was stopped via exception, and the client 
> (usually?) had time to clean up properly. But after the Jetty upgrade from 
> 9.2 to 9.3, Jetty closes the connection on the server sooner than previous 
> versions (?), and the client does not end up getting notified of the original 
> exception at all and instead hits a connection reset exception. The result 
> was random fails due to connection reset throughout our tests and one 
> particular test failing consistently. Even before this update, it does not 
> seem like we are acting in a safe or 'behaved' manner, but our version of 
> Jetty was relaxed enough (or a bug was fixed?) for our tests to work out.



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

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

Re: Lucene/Solr 6.0.0 release

[Shawn Heisey]

On 1/8/2016 7:52 AM, Upayavira wrote:
> I'd like to see some visible improvements to the Solr UI before then.
> Notably a "nodes" pane and a couple of others, so a timescale of "a few
> months" would be great.

I've only been paying attention to commits for one new major release, so
I can offer some info on 5.0, but not any of the previous major releases.

Robert created branch_5x on 2014/09/18.  Version 5.0.0 was released on
2015/02/20.  That's five months from new branch to new major release.

I do not know if that is typical, but I bet it is.  Prepping a new major
release takes quite a while.  You'll likely have all the time you need
to get your UI changes in.

Thanks,
Shawn


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

[jira] [Created] (SOLR-8526) Reuse Lucene.FieldType instances

[Yonik Seeley (JIRA)]

Yonik Seeley created SOLR-8526:
--

 Summary: Reuse Lucene.FieldType instances
 Key: SOLR-8526
 URL: https://issues.apache.org/jira/browse/SOLR-8526
 Project: Solr
  Issue Type: Improvement
Reporter: Yonik Seeley


When lucene created FieldType (not to be confused with Solr's FieldType), Solr 
was ported by simply creating a new lucene.FieldType instance for every field 
indexed.

To avoid creating every time, Solr's SchemaField (which is already analagous to 
lucene.FieldType) can simply implement that interface.



--
This message was sent by Atlassian 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-8040) Upgrade httpclient and httpmime to 4.5.1, httpcore to 4.4.3

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8040:
---

Release Notes:
http://www.apache.org/dist/httpcomponents/httpcore/RELEASE_NOTES-4.4.x.txt
http://www.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.5.x.txt

> Upgrade httpclient and httpmime to 4.5.1, httpcore to 4.4.3
> ---
>
> Key: SOLR-8040
> URL: https://issues.apache.org/jira/browse/SOLR-8040
> Project: Solr
>  Issue Type: Task
>  Components: clients - java
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8040.patch, SOLR-8040.patch
>
>
> Upgrade the httpcomponents jars to the newest versions.  For httpclient and 
> httpmime, that's 4.5.1.  For httpcore, that's 4.4.3.



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

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

[jira] [Commented] (LUCENE-6948) ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6948:


+1 to the patch.

> ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill
> 
>
> Key: LUCENE-6948
> URL: https://issues.apache.org/jira/browse/LUCENE-6948
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 4.10.4
>Reporter: Michael Lawley
> Attachments: LUCENE-6948.patch
>
>
> With a very large index (in our case > 10G), we are seeing exceptions like:
> java.lang.ArrayIndexOutOfBoundsException: -62400
>   at org.apache.lucene.util.PagedBytes$Reader.fill(PagedBytes.java:116)
>   at 
> org.apache.lucene.search.FieldCacheImpl$BinaryDocValuesImpl$1.get(FieldCacheImpl.java:1342)
>   at 
> org.apache.lucene.search.join.TermsCollector$SV.collect(TermsCollector.java:106)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:193)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:309)
> The code in question is trying to allocate an array with a negative size.  We 
> believe the source of the error is in 
> org.apache.lucene.search.FieldCacheImpl$BinaryDocValuesImpl$1.get where the 
> following code occurs:
>   final int pointer = (int) docToOffset.get(docID);
>   if (pointer == 0) {
> term.length = 0;
>   } else {
> bytes.fill(term, pointer);
>   }
> The cast to int will break if the (long) result of docToOffset.get is too 
> large, and is unnecessary in the first place since bytes.fill takes a long as 
> its second parameter.
> Proposed fix:
>   final long pointer = docToOffset.get(docID);
>   if (pointer == 0) {
> term.length = 0;
>   } else {
> bytes.fill(term, pointer);
>   }



--
This message was sent by Atlassian 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-8505) core/DirectoryFactory.LOCK_TYPE_HDFS - add & use it instead of String literals

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8505: core/DirectoryFactory.LOCK_TYPE_HDFS - add & use it instead of 
String literals

> core/DirectoryFactory.LOCK_TYPE_HDFS - add & use it instead of String literals
> --
>
> Key: SOLR-8505
> URL: https://issues.apache.org/jira/browse/SOLR-8505
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8505.patch
>
>
> * Add {{core/DirectoryFactory.LOCK_TYPE_HDFS}}, other 
> {{core/DirectoryFactory.LOCK_TYPE_*}} values already exist.
> * Extend {{DirectoryFactoryTest.testLockTypesUnchanged}} to account for 
> LOCK_TYPE_HDFS.
> * Change {{SolrIndexConfigTest.testToMap}} to also consider 
> "hdfs"/LOCK_TYPE_HDFS.



--
This message was sent by Atlassian 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-8502) Improve Solr JDBC Driver to support SQL Clients like DBVisualizer

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8502:


The following filter can be used to look at the tickets that have patches, but 
are not committed/closed yet.

https://issues.apache.org/jira/issues/?filter=12334493=project%20%3D%20SOLR%20AND%20parent%20%3D%20SOLR-8502%20AND%20Flags%20%3D%20patch%20AND%20status%20not%20in%20(Fixed%2C%20Closed%2C%20Done%2C%20Invalid)%20and%20attachments%20is%20not%20EMPTY%20order%20by%20created%20ASC

[~joel.bernstein] - Can you take a look at these when you get a chance?

> Improve Solr JDBC Driver to support SQL Clients like DBVisualizer
> -
>
> Key: SOLR-8502
> URL: https://issues.apache.org/jira/browse/SOLR-8502
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>  Labels: jdbc
>
> Currently when trying to connect to Solr with the JDBC driver with a SQL 
> client the driver must implement more methods and metadata to allow 
> connections. This JIRA is designed to act as an umbrella for the JDBC changes.
> An initial pass from a few months ago is here: 
> https://github.com/risdenk/lucene-solr/tree/expand-jdbc. This needs to be 
> broken up and create patches for the related sub tasks.



--
This message was sent by Atlassian 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-8184) Negative tests for JDBC Connection String

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8184:


What is this testing for exactly? It looks like the connection string will be 
valid? A SQLException will be thrown because it can't connect to the cluster 
though.
{quote}
+  @Test(expected = SQLException.class)
+  public void testConnectionStringJumbled() throws Exception {
+final String sampleZkHost="zoo1:9983/foo";
+DriverManager.getConnection("solr:jdbc://" + sampleZkHost + 
"?collection=collection1", new Properties());
+  }
{quote}

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>Reporter: Susheel Kumar
>Priority: Minor
> Attachments: SOLR-8184.patch, SOLR-8184.patch, SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
This message was sent by Atlassian 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-8184) Negative tests for JDBC Connection String

[Kevin Risden (JIRA)]

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

Kevin Risden edited comment on SOLR-8184 at 1/8/16 3:15 PM:


What is this testing for exactly? It looks like the connection string will be 
valid? A SQLException will be thrown because it can't connect to the cluster 
though.
{quote}
+  \@Test(expected = SQLException.class)
+  public void testConnectionStringJumbled() throws Exception {
+final String sampleZkHost="zoo1:9983/foo";
+DriverManager.getConnection("solr:jdbc://" + sampleZkHost + 
"?collection=collection1", new Properties());
+  }
{quote}


was (Author: risdenk):
What is this testing for exactly? It looks like the connection string will be 
valid? A SQLException will be thrown because it can't connect to the cluster 
though.
{quote}
+  @Test(expected = SQLException.class)
+  public void testConnectionStringJumbled() throws Exception {
+final String sampleZkHost="zoo1:9983/foo";
+DriverManager.getConnection("solr:jdbc://" + sampleZkHost + 
"?collection=collection1", new Properties());
+  }
{quote}

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>Reporter: Susheel Kumar
>Priority: Minor
> Attachments: SOLR-8184.patch, SOLR-8184.patch, SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
This message was sent by Atlassian 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-8184) Negative tests for JDBC Connection String

[Kevin Risden (JIRA)]

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

Kevin Risden edited comment on SOLR-8184 at 1/8/16 3:15 PM:


What is this testing for exactly? It looks like the connection string will be 
valid? A SQLException will be thrown because it can't connect to the cluster 
though.
{quote}
+  \@Test(expected = SQLException.class)
+  public void testConnectionStringJumbled() throws Exception \{
+final String sampleZkHost="zoo1:9983/foo";
+DriverManager.getConnection("solr:jdbc://" + sampleZkHost + 
"?collection=collection1", new Properties());
+  }
{quote}


was (Author: risdenk):
What is this testing for exactly? It looks like the connection string will be 
valid? A SQLException will be thrown because it can't connect to the cluster 
though.
{quote}
+  \@Test(expected = SQLException.class)
+  public void testConnectionStringJumbled() throws Exception {
+final String sampleZkHost="zoo1:9983/foo";
+DriverManager.getConnection("solr:jdbc://" + sampleZkHost + 
"?collection=collection1", new Properties());
+  }
{quote}

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>Reporter: Susheel Kumar
>Priority: Minor
> Attachments: SOLR-8184.patch, SOLR-8184.patch, SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
This message was sent by Atlassian 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-8184) Negative tests for JDBC Connection String

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8184:


nvm I see that jdbc and solr are switched now.

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>Reporter: Susheel Kumar
>Priority: Minor
> Attachments: SOLR-8184.patch, SOLR-8184.patch, SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
This message was sent by Atlassian 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-6960) TestUninvertingReader.testFieldInfos() failure

[ASF subversion and git services (JIRA)]

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

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

Commit 1723742 from [~mikemccand] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1723742 ]

LUCENE-6960: fix test bug: SimpleText does not use per-field format

> TestUninvertingReader.testFieldInfos() failure
> --
>
> Key: LUCENE-6960
> URL: https://issues.apache.org/jira/browse/LUCENE-6960
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.5, Trunk
>Reporter: Steve Rowe
> Attachments: LUCENE-6960.patch
>
>
> My Jenkins found a reproducible seed for 
> {{TestUninvertingReader.testFieldInfos()}} - fails on both branch_5x and 
> trunk:
> {noformat}
>[junit4] Suite: org.apache.lucene.uninverting.TestUninvertingReader
>[junit4]   2> NOTE: download the large Jenkins line-docs file by running 
> 'ant get-jenkins-line-docs' in the lucene directory.
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestUninvertingReader -Dtests.method=testFieldInfos 
> -Dtests.seed=349A6776161E26B5 -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=sr_ME -Dtests.timezone=US/Indiana-Starke -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.31s | TestUninvertingReader.testFieldInfos <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<0> but 
> was:
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([349A6776161E26B5:24AE58B19B3CAD1C]:0)
>[junit4]>at 
> org.apache.lucene.uninverting.TestUninvertingReader.testFieldInfos(TestUninvertingReader.java:385)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: codec=SimpleText, 
> sim=ClassicSimilarity, locale=sr_ME, timezone=US/Indiana-Starke
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_45 (64-bit)/cpus=16,threads=1,free=412590336,total=514850816
>[junit4]   2> NOTE: All tests run in this JVM: [TestUninvertingReader]
>[junit4] Completed [1/1 (1!)] in 0.47s, 1 test, 1 failure <<< FAILURES!
> {noformat}



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

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

[jira] [Commented] (LUCENE-6960) TestUninvertingReader.testFieldInfos() failure

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6960: fix test bug: SimpleText does not use per-field format

> TestUninvertingReader.testFieldInfos() failure
> --
>
> Key: LUCENE-6960
> URL: https://issues.apache.org/jira/browse/LUCENE-6960
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.5, Trunk
>Reporter: Steve Rowe
> Attachments: LUCENE-6960.patch
>
>
> My Jenkins found a reproducible seed for 
> {{TestUninvertingReader.testFieldInfos()}} - fails on both branch_5x and 
> trunk:
> {noformat}
>[junit4] Suite: org.apache.lucene.uninverting.TestUninvertingReader
>[junit4]   2> NOTE: download the large Jenkins line-docs file by running 
> 'ant get-jenkins-line-docs' in the lucene directory.
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestUninvertingReader -Dtests.method=testFieldInfos 
> -Dtests.seed=349A6776161E26B5 -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=sr_ME -Dtests.timezone=US/Indiana-Starke -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.31s | TestUninvertingReader.testFieldInfos <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<0> but 
> was:
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([349A6776161E26B5:24AE58B19B3CAD1C]:0)
>[junit4]>at 
> org.apache.lucene.uninverting.TestUninvertingReader.testFieldInfos(TestUninvertingReader.java:385)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: codec=SimpleText, 
> sim=ClassicSimilarity, locale=sr_ME, timezone=US/Indiana-Starke
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_45 (64-bit)/cpus=16,threads=1,free=412590336,total=514850816
>[junit4]   2> NOTE: All tests run in this JVM: [TestUninvertingReader]
>[junit4] Completed [1/1 (1!)] in 0.47s, 1 test, 1 failure <<< FAILURES!
> {noformat}



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

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

[jira] [Updated] (SOLR-8513) Implement ResultSetImpl.getMetaData()

[Kevin Risden (JIRA)]

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

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

Added new file ResultSetMetaDataImpl that is just a bare bones implementation. 
It will be filled in with related JIRAs linked to SOLR-8502.

> Implement ResultSetImpl.getMetaData()
> -
>
> Key: SOLR-8513
> URL: https://issues.apache.org/jira/browse/SOLR-8513
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8513.patch
>
>
> SQL clients typically ask about metadata for the result set this is 
> implemented by ResultSetImpl.getMetaData() and will require a new 
> ResultSetMetaDataImpl class.



--
This message was sent by Atlassian 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-8479) Add JDBCStream for integration with external data sources

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-8479:
---

I think a test like that is a great idea. I'll add it at some point in the 
future (perhaps under the guise of cleaning up our tests which was mentioned in 
the UpdateStream ticket).

> Add JDBCStream for integration with external data sources
> -
>
> Key: SOLR-8479
> URL: https://issues.apache.org/jira/browse/SOLR-8479
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-8479.patch, SOLR-8479.patch, SOLR-8479.patch, 
> SOLR-8479.patch, SOLR-8479.patch
>
>
> Given that the Streaming API can merge and join multiple incoming SolrStreams 
> to perform complex operations on the resulting combined datasets I think it 
> would be beneficial to also support incoming streams from other data sources. 
> The JDBCStream will provide a Streaming API interface to any data source 
> which provides a JDBC driver.



--
This message was sent by Atlassian 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-8515) Implement StatementImpl.getConnection

[Kevin Risden (JIRA)]

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

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

Initial patch that improves the passing of the ConnectionImpl object to allow 
for getConnection().

> Implement StatementImpl.getConnection
> -
>
> Key: SOLR-8515
> URL: https://issues.apache.org/jira/browse/SOLR-8515
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8515.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] [Commented] (SOLR-8479) Add JDBCStream for integration with external data sources

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8479:
--

This is a great ticket!

One thing we can think about doing in the future is handling the defined sort 
differently. Possibly parsing it from the SQL statement.

One of the cool things about this is it allows you to distribute a SQL database 
as well. For example you could send the same query to multiple SQL servers then 
stream it all back together.

> Add JDBCStream for integration with external data sources
> -
>
> Key: SOLR-8479
> URL: https://issues.apache.org/jira/browse/SOLR-8479
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-8479.patch, SOLR-8479.patch, SOLR-8479.patch, 
> SOLR-8479.patch, SOLR-8479.patch
>
>
> Given that the Streaming API can merge and join multiple incoming SolrStreams 
> to perform complex operations on the resulting combined datasets I think it 
> would be beneficial to also support incoming streams from other data sources. 
> The JDBCStream will provide a Streaming API interface to any data source 
> which provides a JDBC driver.



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

[Jack Krupansky]

+1 for a 5.x deprecation release so 6.0 can remove old stuff.

+1 for a git-based release

+1 for at least 3 months for people to finish and stabilize work in
progress - April to July seems like the right window to target

-- Jack Krupansky

On Fri, Jan 8, 2016 at 10:09 AM, Anshum Gupta 
wrote:

> +1 to that ! Do you have a planned timeline for this?
>
> I would want some time to clean up code and also have a deprecation
> release (5.5 or 5.6) out so we don't have to carry all the cruft through
> the 6x series.
>
> On Fri, Jan 8, 2016 at 4:37 AM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> I think we should get the ball rolling for our next major release (6.0.0)?
>>
>> E.g., dimensional values is a big new feature for 6.x, and I think
>> it's nearly ready except maybe fixing up the API so it's easier for
>> the 1D case.
>>
>> I think we should maybe remove StorableField before releasing?  I.e.,
>> go back to what we have in 5.x.  This change also caused challenges in
>> the 5.0 release, and we just kicked the can down the road, but I think
>> now we should just kick the can off the road...
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
>
> --
> Anshum Gupta
>