[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+147) - Build # 2664 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2664/
Java: 32bit/jdk-9-ea+147 -client -XX:+UseConcMarkSweepGC

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

Error Message:
PeerSynced node did not become leader expected:https://127.0.0.1:37515/collection1]> but was:https://127.0.0.1:34760/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:https://127.0.0.1:37515/collection1]> but 
was:https://127.0.0.1:34760/collection1]>
at 
__randomizedtesting.SeedInfo.seed([F3B038A8586B5F85:7BE40772F697327D]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:538)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+147) - Build # 18771 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18771/
Java: 64bit/jdk-9-ea+147 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.lucene.index.TestFixBrokenOffsets

Error Message:
file handle leaks: 
[FileChannel(/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/J1/temp/lucene.index.TestFixBrokenOffsets_C4DCCD440F46E8EA-001/brokenoffsets-001/_0.cfs),
 
FileChannel(/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/J1/temp/lucene.index.TestFixBrokenOffsets_C4DCCD440F46E8EA-001/brokenoffsets-001/_1.cfs)]

Stack Trace:
java.lang.RuntimeException: file handle leaks: 
[FileChannel(/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/J1/temp/lucene.index.TestFixBrokenOffsets_C4DCCD440F46E8EA-001/brokenoffsets-001/_0.cfs),
 
FileChannel(/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/J1/temp/lucene.index.TestFixBrokenOffsets_C4DCCD440F46E8EA-001/brokenoffsets-001/_1.cfs)]
at __randomizedtesting.SeedInfo.seed([C4DCCD440F46E8EA]:0)
at org.apache.lucene.mockfile.LeakFS.onClose(LeakFS.java:63)
at 
org.apache.lucene.mockfile.FilterFileSystem.close(FilterFileSystem.java:77)
at 
org.apache.lucene.mockfile.FilterFileSystem.close(FilterFileSystem.java:78)
at 
org.apache.lucene.mockfile.FilterFileSystem.close(FilterFileSystem.java:78)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:228)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.Exception
at org.apache.lucene.mockfile.LeakFS.onOpen(LeakFS.java:46)
at 
org.apache.lucene.mockfile.HandleTrackingFS.callOpenHook(HandleTrackingFS.java:81)
at 
org.apache.lucene.mockfile.HandleTrackingFS.newFileChannel(HandleTrackingFS.java:197)
at 
org.apache.lucene.mockfile.HandleTrackingFS.newFileChannel(HandleTrackingFS.java:166)
at 
org.apache.lucene.mockfile.FilterFileSystemProvider.newFileChannel(FilterFileSystemProvider.java:202)
at java.base/java.nio.channels.FileChannel.open(FileChannel.java:287)
at java.base/java.nio.channels.FileChannel.open(FileChannel.java:335)
at 
org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:81)
at 
org.apache.lucene.codecs.lucene50.Lucene50CompoundReader.(Lucene50CompoundReader.java:78)
at 
org.apache.lucene.codecs.lucene50.Lucene50CompoundFormat.getCompoundReader(Lucene50CompoundFormat.java:71)
at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:96)
at org.apache.lucene.index.SegmentReader.(SegmentReader.java:74)
at 
org.apache.lucene.index.StandardDirectoryReader$1.doBody(StandardDirectoryReader.java:62)
at 
org.apache.lucene.index.StandardDirectoryReader$1.doBody(StandardDirectoryReader.java:54)
at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:664)
at 
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:77)
at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:63)
at 
org.apache.lucene.index.TestFixBrokenOffsets.testFixBrokenOffsetsIndex(TestFixBrokenOffsets.java:90)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:538)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 

[jira] [Commented] (SOLR-9835) Create another replication mode for SolrCloud

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9835:
-

Thanks Dat. I have started reviewing your patch.

> Create another replication mode for SolrCloud
> -
>
> Key: SOLR-9835
> URL: https://issues.apache.org/jira/browse/SOLR-9835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch
>
>
> The current replication mechanism of SolrCloud is called state machine, which 
> replicas start in same initial state and for each input, the input is 
> distributed across replicas so all replicas will end up with same next state. 
> But this type of replication have some drawbacks
> - The commit (which costly) have to run on all replicas
> - Slow recovery, because if replica miss more than N updates on its down 
> time, the replica have to download entire index from its leader.
> So we create create another replication mode for SolrCloud called state 
> transfer, which acts like master/slave replication. In basically
> - Leader distribute the update to other replicas, but the leader only apply 
> the update to IW, other replicas just store the update to UpdateLog (act like 
> replication).
> - Replicas frequently polling the latest segments from leader.
> Pros:
> - Lightweight for indexing, because only leader are running the commit, 
> updates.
> - Very fast recovery, replicas just have to download the missing segments.
> To use this new replication mode, a new collection must be created with an 
> additional parameter {{liveReplicas=1}}
> {code}
> http://localhost:8983/solr/admin/collections?action=CREATE=newCollection=2=1=1
> {code}



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

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 643 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/643/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
PeerSynced node did not become leader expected:http://127.0.0.1:59055/collection1]> but was:http://127.0.0.1:59051/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:http://127.0.0.1:59055/collection1]> but 
was:http://127.0.0.1:59051/collection1]>
at 
__randomizedtesting.SeedInfo.seed([26E6890BDEB23199:AEB2B6D1704E5C61]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Comment Edited] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[jefferyyuan (JIRA)]

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

jefferyyuan edited comment on SOLR-6246 at 1/14/17 5:15 AM:


I tested with the latest build - solr-6.4.0-222,reloading collection/cores with 
AnalyzingInfixSuggester still failed with LockObtainFailedException.
It failed with same error even after after solr.

It can be easily reproduced, add a suggest component, then ***build the 
suggester***: suggest?suggest.build=true. Then reload collection or cores.

- Seems the key to reproduce the issue is we need build the suggester.



infixSuggester
BlendedInfixLookupFactory
DocumentDictionaryFactory
position_linear
suggester
suggesterContextField
4
textSuggest
infix_suggestions
true
false
false





true
infixSuggester
true
10
true


suggest




was (Author: yuanyun.cn):
I tested with the latest build - solr-6.4.0-222,reloading collection/cores with 
AnalyzingInfixSuggester still failed with LockObtainFailedException.
It failed with same error even after after solr.
It can be easily reproduced, add a suggest component, then build the suggester: 
suggest?suggest.build=true. Then reload collection or cores/



infixSuggester
BlendedInfixLookupFactory
DocumentDictionaryFactory
position_linear
suggester
suggesterContextField
4
textSuggest
infix_suggestions
true
false
false





true
infixSuggester
true
10
true


suggest



> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
> Attachments: SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



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

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

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[jefferyyuan (JIRA)]

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

jefferyyuan commented on SOLR-6246:
---

I tested with the latest build - solr-6.4.0-222,reloading collection/cores with 
AnalyzingInfixSuggester still failed with LockObtainFailedException.
It failed with same error even after after solr.
It can be easily reproduced, add a suggest component, then build the suggester: 
suggest?suggest.build=true. Then reload collection or cores/



infixSuggester
BlendedInfixLookupFactory
DocumentDictionaryFactory
position_linear
suggester
suggesterContextField
4
textSuggest
infix_suggestions
true
false
false





true
infixSuggester
true
10
true


suggest



> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
> Attachments: SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



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

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

Re: 6.4 release

[Mark Miller]

Create a jira and someone will update it for the next release.
On Fri, Jan 13, 2017 at 7:47 PM S G  wrote:

> Probably too late for this release, but can we consider using Zookeeper
> 3.4.9 for the next
> release as it brings in a lot of stability improvements (
> http://zookeeper.apache.org/releases.html) and
> Solr guide is still recommending zookeeper 3.4.6 (
> https://cwiki.apache.org/confluence/display/solr/Setting+Up+an+External+ZooKeeper+Ensemble
> )
>
> On Fri, Jan 13, 2017 at 11:46 AM, jim ferenczi 
> wrote:
>
> Great news Uwe! I'll cut the branch this week end if nobody disagree.
>
> Le 13 janv. 2017 20:24, "Uwe Schindler"  a écrit :
>
> Hi Jim,
>
>
>
> I updated Groovy. I’d like to run Solr tests this evening through Jenkins
> with Java 9 EA build 151 to get a list of all tests that have to be
> disabled for Java 9, but otherwise we are ready.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* jim ferenczi [mailto:jim.feren...@gmail.com]
> *Sent:* Monday, January 9, 2017 12:37 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: 6.4 release
>
>
>
> Thanks for sharing Uwe. It would be wonderful to make latest java9 works
> with the released version. I can delay the branching until
> https://issues.apache.org/jira/browse/LUCENE-7596 is closed ?
>
> In the mean time I am trying to create the release notes in the wiki but I
> don't have the permissions to create the pages. Where can I get such
> permissions ?
>
>
>
> 2017-01-09 11:13 GMT+01:00 Uwe Schindler :
>
> Hi,
>
>
>
> I am fine with the start of release process, but I would like to add one
> thing:
>
>
>
> I know that Elasticsearch wants to be compatible with recent Java 9 for
> the continuous delievery process. The new Lucene release is compatible with
> that (mmap unmapping works), but you cannot build the release with Java 9
> 148+. Currently the release vote of Groovy 2.4.8 is ongoing and should
> finish the next few days. So I’d suggest to delay a bit, so I can update
> common-build.xml and raise the Groovy version:
> https://issues.apache.org/jira/browse/LUCENE-7596
>
>
>
> This does not make Solr Tests work with Java 9, but that’s a different
> discussion (mocking frameworks broke with recent Java 9):
> https://issues.apache.org/jira/browse/SOLR-9893
>
> I will fix this by disabling those tests with Java 9, but that a bit of
> work to set those assumeFalse(Constants.JAVA9….). I don’t see this as a
> blocker!
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* jim ferenczi [mailto:jim.feren...@gmail.com]
> *Sent:* Tuesday, January 3, 2017 5:23 PM
> *To:* dev@lucene.apache.org
> *Subject:* 6.4 release
>
>
>
> Hi,
> I would like to volunteer to release 6.4. I can cut the release branch
> next Monday if everybody agrees.
>
>
>
> Jim
>
>
>
>
> --
- Mark
about.me/markrmiller

Re: 6.4 release

[S G]

Probably too late for this release, but can we consider using Zookeeper
3.4.9 for the next
release as it brings in a lot of stability improvements (
http://zookeeper.apache.org/releases.html) and
Solr guide is still recommending zookeeper 3.4.6 (
https://cwiki.apache.org/confluence/display/solr/Setting+Up+an+External+ZooKeeper+Ensemble
)

On Fri, Jan 13, 2017 at 11:46 AM, jim ferenczi 
wrote:

> Great news Uwe! I'll cut the branch this week end if nobody disagree.
>
> Le 13 janv. 2017 20:24, "Uwe Schindler"  a écrit :
>
>> Hi Jim,
>>
>>
>>
>> I updated Groovy. I’d like to run Solr tests this evening through Jenkins
>> with Java 9 EA build 151 to get a list of all tests that have to be
>> disabled for Java 9, but otherwise we are ready.
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* jim ferenczi [mailto:jim.feren...@gmail.com]
>> *Sent:* Monday, January 9, 2017 12:37 PM
>> *To:* dev@lucene.apache.org
>> *Subject:* Re: 6.4 release
>>
>>
>>
>> Thanks for sharing Uwe. It would be wonderful to make latest java9 works
>> with the released version. I can delay the branching until
>> https://issues.apache.org/jira/browse/LUCENE-7596 is closed ?
>>
>> In the mean time I am trying to create the release notes in the wiki but
>> I don't have the permissions to create the pages. Where can I get such
>> permissions ?
>>
>>
>>
>> 2017-01-09 11:13 GMT+01:00 Uwe Schindler :
>>
>> Hi,
>>
>>
>>
>> I am fine with the start of release process, but I would like to add one
>> thing:
>>
>>
>>
>> I know that Elasticsearch wants to be compatible with recent Java 9 for
>> the continuous delievery process. The new Lucene release is compatible with
>> that (mmap unmapping works), but you cannot build the release with Java 9
>> 148+. Currently the release vote of Groovy 2.4.8 is ongoing and should
>> finish the next few days. So I’d suggest to delay a bit, so I can update
>> common-build.xml and raise the Groovy version:
>> https://issues.apache.org/jira/browse/LUCENE-7596
>>
>>
>>
>> This does not make Solr Tests work with Java 9, but that’s a different
>> discussion (mocking frameworks broke with recent Java 9):
>> https://issues.apache.org/jira/browse/SOLR-9893
>>
>> I will fix this by disabling those tests with Java 9, but that a bit of
>> work to set those assumeFalse(Constants.JAVA9….). I don’t see this as a
>> blocker!
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* jim ferenczi [mailto:jim.feren...@gmail.com]
>> *Sent:* Tuesday, January 3, 2017 5:23 PM
>> *To:* dev@lucene.apache.org
>> *Subject:* 6.4 release
>>
>>
>>
>> Hi,
>> I would like to volunteer to release 6.4. I can cut the release branch
>> next Monday if everybody agrees.
>>
>>
>>
>> Jim
>>
>>
>>
>

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3777 - Still Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
PeerSynced node did not become leader expected:https://127.0.0.1:54661/sdj/collection1]> but was:https://127.0.0.1:54649/sdj/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:https://127.0.0.1:54661/sdj/collection1]> but 
was:https://127.0.0.1:54649/sdj/collection1]>
at 
__randomizedtesting.SeedInfo.seed([A64676032B9D4F06:2E1249D9856122FE]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
 

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+147) - Build # 18770 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18770/
Java: 32bit/jdk-9-ea+147 -server -XX:+UseConcMarkSweepGC

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

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([8D036D73AF5E7804:55752A901A215FC]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:538)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
   

[jira] [Commented] (SOLR-9922) Write buffering updates to another tlog

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-9922:


[~markrmil...@gmail.com] : I think this will be fine if we run PeerSync after 
the upgrade because at the end of PeerSync, we do the fingerprint comparison 
which I think it's a very strong defensive check!

> Write buffering updates to another tlog
> ---
>
> Key: SOLR-9922
> URL: https://issues.apache.org/jira/browse/SOLR-9922
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
> Attachments: SOLR-9922.patch, SOLR-9922.patch, SOLR-9922.patch
>
>
> Currently, we write buffering logs to current tlog and not apply that updates 
> to index. Then we rely on replay log to apply that updates to index. But at 
> the same time there are some updates also write to current tlog and applied 
> to the index. 
> For example, during peersync, if new updates come to replica we will end up 
> with this tlog
> tlog : old1, new1, new2, old2, new3, old3
> old updates belong to peersync, and these updates are applied to the index.
> new updates belong to buffering updates, and these updates are not applied to 
> the index.
> But writing all the updates to same current tlog make code base very complex. 
> We should write buffering updates to another tlog file.
> By doing this, it will help our code base simpler. It also makes replica 
> recovery for SOLR-9835 more easier. Because after peersync success we can 
> copy new updates from temporary file to current tlog, for example
> tlog : old1, old2, old3
> temporary tlog : new1, new2, new3
> -->
> tlog : old1, old2, old3, new1, new2, new3



--
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-9872) raf.setLength(0) in transactionLog is unreachable

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat edited comment on SOLR-9872 at 1/14/17 2:29 AM:
-

[~markrmil...@gmail.com] : Do you have any idea about this problem? It seems 
added on SOLR-7113


was (Author: caomanhdat):
[~markrmil...@gmail.com] : Do you have any idea about this problem?

> raf.setLength(0) in transactionLog is unreachable
> -
>
> Key: SOLR-9872
> URL: https://issues.apache.org/jira/browse/SOLR-9872
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>
> When I look at {{TransactionLog.java}} I found these lines of code in 
> constructor
> {code}
> if (start > 0) {
>   log.warn("New transaction log already exists:" + tlogFile + " 
> size=" + raf.length());
>   return;
> }
>
> if (start > 0) {
>   raf.setLength(0);
> }
> addGlobalStrings(globalStrings);
> {code}
> It seems, we will never reach {{raf.setLength(0)}}?



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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1619 - Unstable

[Apache Jenkins Server]

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

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

Error Message:
Captured an uncaught exception in thread: Thread[id=1300, 
name=SocketProxy-Response-52213:49221, state=RUNNABLE, 
group=TGRP-HttpPartitionTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=1300, name=SocketProxy-Response-52213:49221, 
state=RUNNABLE, group=TGRP-HttpPartitionTest]
at 
__randomizedtesting.SeedInfo.seed([ADBA315ABED9F0B5:25EE0E8010259D4D]:0)
Caused by: java.lang.RuntimeException: java.net.SocketException: Socket is 
closed
at __randomizedtesting.SeedInfo.seed([ADBA315ABED9F0B5]:0)
at 
org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:347)
Caused by: java.net.SocketException: Socket is closed
at java.net.Socket.setSoTimeout(Socket.java:1137)
at 
org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:344)




Build Log:
[...truncated 10937 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/solr-core/test/J0/temp/solr.cloud.HttpPartitionTest_ADBA315ABED9F0B5-001/init-core-data-001
   [junit4]   2> 99010 INFO  
(SUITE-HttpPartitionTest-seed#[ADBA315ABED9F0B5]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-5776)
   [junit4]   2> 99010 INFO  
(SUITE-HttpPartitionTest-seed#[ADBA315ABED9F0B5]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /dqb/rm
   [junit4]   2> 99029 INFO  
(TEST-HttpPartitionTest.test-seed#[ADBA315ABED9F0B5]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 99031 INFO  (Thread-100) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 99031 INFO  (Thread-100) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 99131 INFO  
(TEST-HttpPartitionTest.test-seed#[ADBA315ABED9F0B5]) [] 
o.a.s.c.ZkTestServer start zk server on port:60620
   [junit4]   2> 99202 INFO  
(TEST-HttpPartitionTest.test-seed#[ADBA315ABED9F0B5]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 99204 INFO  
(TEST-HttpPartitionTest.test-seed#[ADBA315ABED9F0B5]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/schema.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 99205 INFO  
(TEST-HttpPartitionTest.test-seed#[ADBA315ABED9F0B5]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 99206 INFO  
(TEST-HttpPartitionTest.test-seed#[ADBA315ABED9F0B5]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 99207 INFO  
(TEST-HttpPartitionTest.test-seed#[ADBA315ABED9F0B5]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/protwords.txt
 to /configs/conf1/protwords.txt
   [junit4]   2> 99208 INFO  
(TEST-HttpPartitionTest.test-seed#[ADBA315ABED9F0B5]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/currency.xml
 to /configs/conf1/currency.xml
   [junit4]   2> 99209 INFO  
(TEST-HttpPartitionTest.test-seed#[ADBA315ABED9F0B5]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/enumsConfig.xml
 to /configs/conf1/enumsConfig.xml
   [junit4]   2> 99210 INFO  
(TEST-HttpPartitionTest.test-seed#[ADBA315ABED9F0B5]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/open-exchange-rates.json
 to /configs/conf1/open-exchange-rates.json
   [junit4]   2> 99210 INFO  
(TEST-HttpPartitionTest.test-seed#[ADBA315ABED9F0B5]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/mapping-ISOLatin1Accent.txt
 to /configs/conf1/mapping-ISOLatin1Accent.txt
   [junit4]   2> 99211 INFO  
(TEST-HttpPartitionTest.test-seed#[ADBA315ABED9F0B5]) [] 
o.a.s.c.AbstractZkTestCase put 

[jira] [Commented] (SOLR-9872) raf.setLength(0) in transactionLog is unreachable

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-9872:


[~markrmil...@gmail.com] : Do you have any idea about this problem?

> raf.setLength(0) in transactionLog is unreachable
> -
>
> Key: SOLR-9872
> URL: https://issues.apache.org/jira/browse/SOLR-9872
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>
> When I look at {{TransactionLog.java}} I found these lines of code in 
> constructor
> {code}
> if (start > 0) {
>   log.warn("New transaction log already exists:" + tlogFile + " 
> size=" + raf.length());
>   return;
> }
>
> if (start > 0) {
>   raf.setLength(0);
> }
> addGlobalStrings(globalStrings);
> {code}
> It seems, we will never reach {{raf.setLength(0)}}?



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

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

[jira] [Updated] (LUCENE-7631) Enforce javac warnings

[Mike Drob (JIRA)]

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

Mike Drob updated LUCENE-7631:
--
Attachment: LUCENE-7631.patch

Patch that ensures we won't add any new compiler warnings in several categories 
(that we're pretty good on already) in the future. We can deal with fixing 
existing rawtypes or a few other classes of warning in the future.

[~dsmiley] - you seemed interested in this conversation last time it came up.

> Enforce javac warnings
> --
>
> Key: LUCENE-7631
> URL: https://issues.apache.org/jira/browse/LUCENE-7631
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Mike Drob
> Attachments: LUCENE-7631.patch
>
>
> Robert's comment on LUCENE-3973 suggested to take an incremental approach to 
> static analysis and leverage the java compiler warnings. I think this is easy 
> to do and is a reasonable change to make to protect the code base for the 
> future.
> We currently have many fewer warnings than we did a year or two years ago and 
> should ensure that we do not slide backwards.



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

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

[jira] [Created] (LUCENE-7631) Enforce javac warnings

[Mike Drob (JIRA)]

Mike Drob created LUCENE-7631:
-

 Summary: Enforce javac warnings
 Key: LUCENE-7631
 URL: https://issues.apache.org/jira/browse/LUCENE-7631
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/build
Reporter: Mike Drob


Robert's comment on LUCENE-3973 suggested to take an incremental approach to 
static analysis and leverage the java compiler warnings. I think this is easy 
to do and is a reasonable change to make to protect the code base for the 
future.

We currently have many fewer warnings than we did a year or two years ago and 
should ensure that we do not slide backwards.



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

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

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_112) - Build # 689 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/689/
Java: 64bit/jdk1.8.0_112 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.SolrXmlInZkTest_263F3AD061785798-001\tempDir-003\home\myCollect:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.SolrXmlInZkTest_263F3AD061785798-001\tempDir-003\home\myCollect

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.SolrXmlInZkTest_263F3AD061785798-001\tempDir-003\home:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.SolrXmlInZkTest_263F3AD061785798-001\tempDir-003\home

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.SolrXmlInZkTest_263F3AD061785798-001\tempDir-003:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.SolrXmlInZkTest_263F3AD061785798-001\tempDir-003
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.SolrXmlInZkTest_263F3AD061785798-001\tempDir-003\home\myCollect:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.SolrXmlInZkTest_263F3AD061785798-001\tempDir-003\home\myCollect
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.SolrXmlInZkTest_263F3AD061785798-001\tempDir-003\home:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.SolrXmlInZkTest_263F3AD061785798-001\tempDir-003\home
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.SolrXmlInZkTest_263F3AD061785798-001\tempDir-003:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.SolrXmlInZkTest_263F3AD061785798-001\tempDir-003

at __randomizedtesting.SeedInfo.seed([263F3AD061785798]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:323)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
timed out waiting for collection1 startAt time to exceed: Fri Jan 13 19:33:22 
EST 2017

Stack Trace:
java.lang.AssertionError: timed out waiting for collection1 startAt time to 
exceed: Fri Jan 13 19:33:22 EST 2017
at 
__randomizedtesting.SeedInfo.seed([263F3AD061785798:FD943A1664503E2B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.TestReplicationHandler.watchCoreStartAt(TestReplicationHandler.java:1526)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:867)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2662/
Java: 64bit/jdk-9-ea+147 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.search.join.BlockJoinFacetDistribTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.search.join.BlockJoinFacetDistribTest: 1) Thread[id=25184, 
name=OverseerHdfsCoreFailoverThread-97278684641558541-127.0.0.1:46671_solr-n_02,
 state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.] at 
java.base/java.lang.Thread.sleep(Native Method) at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:139)
 at java.base/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.search.join.BlockJoinFacetDistribTest: 
   1) Thread[id=25184, 
name=OverseerHdfsCoreFailoverThread-97278684641558541-127.0.0.1:46671_solr-n_02,
 state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.]
at java.base/java.lang.Thread.sleep(Native Method)
at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:139)
at java.base/java.lang.Thread.run(Thread.java:844)
at __randomizedtesting.SeedInfo.seed([60F981BE3E6F147D]:0)




Build Log:
[...truncated 13008 lines...]
   [junit4] Suite: org.apache.solr.search.join.BlockJoinFacetDistribTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J2/temp/solr.search.join.BlockJoinFacetDistribTest_60F981BE3E6F147D-001/init-core-data-001
   [junit4]   2> 2160453 INFO  
(SUITE-BlockJoinFacetDistribTest-seed#[60F981BE3E6F147D]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason="", value=0.0/0.0, ssl=0.0/0.0, 
clientAuth=0.0/0.0)
   [junit4]   2> 2160454 INFO  
(SUITE-BlockJoinFacetDistribTest-seed#[60F981BE3E6F147D]-worker) [] 
o.a.s.c.MiniSolrCloudCluster Starting cluster of 6 servers in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J2/temp/solr.search.join.BlockJoinFacetDistribTest_60F981BE3E6F147D-001/tempDir-001
   [junit4]   2> 2160454 INFO  
(SUITE-BlockJoinFacetDistribTest-seed#[60F981BE3E6F147D]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 2160455 INFO  (Thread-3294) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 2160455 INFO  (Thread-3294) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 2160555 INFO  
(SUITE-BlockJoinFacetDistribTest-seed#[60F981BE3E6F147D]-worker) [] 
o.a.s.c.ZkTestServer start zk server on port:41471
   [junit4]   2> 2160564 INFO  (jetty-launcher-5785-thread-1) [] 
o.e.j.s.Server jetty-9.3.14.v20161028
   [junit4]   2> 2160566 INFO  (jetty-launcher-5785-thread-2) [] 
o.e.j.s.Server jetty-9.3.14.v20161028
   [junit4]   2> 2160568 INFO  (jetty-launcher-5785-thread-3) [] 
o.e.j.s.Server jetty-9.3.14.v20161028
   [junit4]   2> 2160575 INFO  (jetty-launcher-5785-thread-1) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@5147246{/solr,null,AVAILABLE}
   [junit4]   2> 2160576 INFO  (jetty-launcher-5785-thread-1) [] 
o.e.j.s.AbstractConnector Started ServerConnector@16208f6e{SSL,[ssl, 
http/1.1]}{127.0.0.1:46464}
   [junit4]   2> 2160576 INFO  (jetty-launcher-5785-thread-1) [] 
o.e.j.s.Server Started @2163327ms
   [junit4]   2> 2160576 INFO  (jetty-launcher-5785-thread-1) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr, 
hostPort=46464}
   [junit4]   2> 2160576 ERROR (jetty-launcher-5785-thread-1) [] 
o.a.s.s.StartupLoggingUtils Missing Java Option solr.log.dir. Logging may be 
missing or incomplete.
   [junit4]   2> 2160577 INFO  (jetty-launcher-5785-thread-1) [] 
o.a.s.s.SolrDispatchFilter  ___  _   Welcome to Apache Solr? version 
6.4.0
   [junit4]   2> 2160577 INFO  (jetty-launcher-5785-thread-1) [] 
o.a.s.s.SolrDispatchFilter / __| ___| |_ _   Starting in cloud mode on port null
   [junit4]   2> 2160577 INFO  (jetty-launcher-5785-thread-1) [] 
o.a.s.s.SolrDispatchFilter \__ \/ _ \ | '_|  Install dir: null
   [junit4]   2> 2160577 INFO  (jetty-launcher-5785-thread-1) [] 
o.a.s.s.SolrDispatchFilter |___/\___/_|_|Start time: 
2017-01-14T00:48:49.344334Z
   [junit4]   2> 2160585 INFO  (jetty-launcher-5785-thread-5) [] 
o.e.j.s.Server jetty-9.3.14.v20161028
   [junit4]   2> 2160586 INFO  (jetty-launcher-5785-thread-4) [] 
o.e.j.s.Server jetty-9.3.14.v20161028
   [junit4]   2> 2160586 INFO  (jetty-launcher-5785-thread-1) [] 
o.a.s.s.SolrDispatchFilter solr.xml found in ZooKeeper. Loading...
   [junit4]   2> 2160619 INFO  (jetty-launcher-5785-thread-6) [] 
o.e.j.s.Server jetty-9.3.14.v20161028
   [junit4]   2> 2160620 INFO  

[jira] [Commented] (SOLR-9869) MiniSolrCloudCluster does not always remove jettys from running list after stopping them

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-9869:
-

Bump - this is behaviour is potentially a trap for anybody writing unit tests.

> MiniSolrCloudCluster does not always remove jettys from running list after 
> stopping them
> 
>
> Key: SOLR-9869
> URL: https://issues.apache.org/jira/browse/SOLR-9869
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mike Drob
> Attachments: SOLR-9869.patch
>
>
> MiniSolrCloudCluster has two {{stopJettySolrRunner}} methods that behave 
> differently.
> The {{int}} version calls {{jettys.remove(index);}} to remove the now stopped 
> jetty from the list of running jettys.
> The version that takes a {{JettySolrRunner}}, however, does not modify the 
> running list.
> This can cause calls to {{getReplicaJetty}} to fail after a call to {{stop}} 
> because we will try to get the base url of a stopped jetty.



--
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-9893) EasyMock/Mockito no longer works with Java 9 b148+

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-9893:

Attachment: SOLR-9893-Mockito-update.patch

Here is the patch for the Mockito Update to be Java 9 compatible (Thanks to 
Rafael Winterhalter for fixing Bytebuddy).

> EasyMock/Mockito no longer works with Java 9 b148+
> --
>
> Key: SOLR-9893
> URL: https://issues.apache.org/jira/browse/SOLR-9893
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: 6.x, master (7.0)
>Reporter: Uwe Schindler
>Priority: Blocker
> Attachments: SOLR-9893-Mockito-update.patch
>
>
> EasyMock does not work anymore with latest Java 9, because it uses cglib 
> behind that is trying to access a protected method inside the runtime using 
> setAccessible. This is no longer allowed by Java 9.
> Actually this is really stupid. Instead of forcefully making the protected 
> defineClass method available to the outside, it is much more correct to just 
> subclass ClassLoader (like the Lucene expressions module does).
> I tried updating to easymock/mockito, but all that does not work, approx 25 
> tests fail. The only way is to disable all Mocking tests in Java 9. The 
> underlying issue in cglib is still not solved, master's code is here: 
> https://github.com/cglib/cglib/blob/master/cglib/src/main/java/net/sf/cglib/core/ReflectUtils.java#L44-L62
> As we use an old stone-aged version of mockito (1.x), a fix is not expected 
> to happen, although cglib might fix this!
> What should we do? This stupid issue prevents us from testing Java 9 with 
> Solr completely! 



--
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-9893) EasyMock/Mockito no longer works with Java 9 b148+

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9893:
-

Hi,
I was able to update Solr-Code's Test Dependencies to latest Mockito/Bytebuddy. 
This makes most Mocking tests works again.
But Easymock did not release a new version (and seems no longer maintained). If 
somemody has time to rewrite those tests (about 13 Suites with 23 tests, 
only) to use Mockito, too - we would be able to run our tests with Java 9:

Some of those tests that failed in my local run may be unrelated, this is just 
the output:

[junit4] Tests with failures [seed: A99FA98E35E3349A] (first 10 out of 23):
   [junit4]   - 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail
   [junit4]   - 
org.apache.solr.core.BlobRepositoryMockingTest.testGetBlobIncrRefStringDecoder
   [junit4]   - 
org.apache.solr.core.BlobRepositoryMockingTest.testGetBlobIncrRefString
   [junit4]   - org.apache.solr.core.BlobRepositoryMockingTest.testCachedAlready
   [junit4]   - org.apache.solr.core.BlobRepositoryMockingTest.testCloudOnly
   [junit4]   - org.apache.solr.cloud.SyncSliceTest (suite)
   [junit4]   - org.apache.solr.cloud.OverseerCollectionConfigSetProcessorTest 
(suite)
   [junit4]   - 
org.apache.solr.handler.component.DistributedFacetPivotWhiteBoxTest (suite)
   [junit4]   - 
org.apache.solr.servlet.SolrRequestParserTest.testStandardFormdataUploadLimit
   [junit4]   - 
org.apache.solr.servlet.SolrRequestParserTest.testStandardParseParamsAndFillStreamsISO88591

The problem with Easymock is: Old versions (Solr uses 3.0) depend on outdated 
cglib that has no Java 9 compatible release. Newer versions (3.4) ships with 
CGLIB bundled and shaded. So even if CGLIB releases a newer version, it won't 
help, because Easymock uses the shaded and bundled broken version. Easymock 
seems dead to me. So let's nuke it. Mockito is the way to go.

For now my only chance is to disable all Easymock based tests, they are 
incompatible to Java 9.

> EasyMock/Mockito no longer works with Java 9 b148+
> --
>
> Key: SOLR-9893
> URL: https://issues.apache.org/jira/browse/SOLR-9893
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: 6.x, master (7.0)
>Reporter: Uwe Schindler
>Priority: Blocker
>
> EasyMock does not work anymore with latest Java 9, because it uses cglib 
> behind that is trying to access a protected method inside the runtime using 
> setAccessible. This is no longer allowed by Java 9.
> Actually this is really stupid. Instead of forcefully making the protected 
> defineClass method available to the outside, it is much more correct to just 
> subclass ClassLoader (like the Lucene expressions module does).
> I tried updating to easymock/mockito, but all that does not work, approx 25 
> tests fail. The only way is to disable all Mocking tests in Java 9. The 
> underlying issue in cglib is still not solved, master's code is here: 
> https://github.com/cglib/cglib/blob/master/cglib/src/main/java/net/sf/cglib/core/ReflectUtils.java#L44-L62
> As we use an old stone-aged version of mockito (1.x), a fix is not expected 
> to happen, although cglib might fix this!
> What should we do? This stupid issue prevents us from testing Java 9 with 
> Solr completely! 



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

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

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_112) - Build # 6356 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6356/
Java: 32bit/jdk1.8.0_112 -client -XX:+UseParallelGC

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

Error Message:
document count mismatch.  control=875 sum(shards)=874 cloudClient=874

Stack Trace:
java.lang.AssertionError: document count mismatch.  control=875 sum(shards)=874 
cloudClient=874
at 
__randomizedtesting.SeedInfo.seed([503762F889A1CBA:8D5749F526667142]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1323)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:231)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Resolved] (LUCENE-7626) IndexWriter shouldn't accept broken offsets

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-7626.

Resolution: Fixed

> IndexWriter shouldn't accept broken offsets
> ---
>
> Key: LUCENE-7626
> URL: https://issues.apache.org/jira/browse/LUCENE-7626
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: LUCENE-7626.patch, LUCENE-7626.patch
>
>
> I think we should do this in 7.0 (not 6.x).
> Long ago we stopped accepting broken offsets (where the start offset
> for a token is before the start offset of the last token) in postings
> (LUCENE-4127), but we are still lenient with term vectors.
> I think we should also check for term vectors: this would let users
> know that their analysis chain is producing offsets that cannot be
> used properly at search time.



--
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-7626) IndexWriter shouldn't accept broken offsets

[ASF subversion and git services (JIRA)]

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

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

Commit 64b86331c29d074fa7b257d65d3fda3b662bf96a in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=64b8633 ]

LUCENE-7626: IndexWriter no longer accepts broken offsets


> IndexWriter shouldn't accept broken offsets
> ---
>
> Key: LUCENE-7626
> URL: https://issues.apache.org/jira/browse/LUCENE-7626
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: LUCENE-7626.patch, LUCENE-7626.patch
>
>
> I think we should do this in 7.0 (not 6.x).
> Long ago we stopped accepting broken offsets (where the start offset
> for a token is before the start offset of the last token) in postings
> (LUCENE-4127), but we are still lenient with term vectors.
> I think we should also check for term vectors: this would let users
> know that their analysis chain is producing offsets that cannot be
> used properly at search time.



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
expected:<152> but was:<140>

Stack Trace:
java.lang.AssertionError: expected:<152> but was:<140>
at 
__randomizedtesting.SeedInfo.seed([5428A2DE548F879D:DC7C9D04FA73EA65]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:286)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:538)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)

Re: Solr Ref Guide, Highlighting

[David Smiley]

Thanks Tim; this is good!
I'll incorporate the changes sometimes this weekend.

> On Jan 13, 2017, at 4:29 PM, Timothy Rodriguez (BLOOMBERG/ 120 PARK) 
>  wrote:
> 
> I've made some edits and additions in word with tracked changes to the Solr 
> Ref guide.  I couldn't think of a better way to send out the changes.  Let me 
> know if you'd like me to send in some other fashion.
> 
> -Tim
> 
> 
> 
> From: dev@lucene.apache.org At: 01/11/17 15:53:39
> To: dev@lucene.apache.org 
> Cc: Timothy Rodriguez (BLOOMBERG/ 120 PARK) 
> 
> Subject: Re: Solr Ref Guide, Highlighting
> Yes, I can help - I meant to try today, but tomorrow looks much
> clearer schedule-wise to focus on Ref Guide.
> 
> On Wed, Jan 11, 2017 at 12:32 AM, David Smiley  > wrote:
> > I made some progress... I'm having flashbacks to book-writing; ugh. If you
> > wish to help Cassandra, I think a great spot would be the "Basic Usage"
> > section I inserted.  I'll save that for last if nobody gets to it.  I need
> > to do the end of the page, and then add a UH page and deal with the other
> > highlighter pages.
> >
> > On Tue, Jan 10, 2017 at 12:20 PM David Smiley  > >
> > wrote:
> >>
> >> Thanks for your input Cassandra.
> >> Within the code, DefaultSolrHighlighter.java can be renamed; it's not set
> >> in stone unlike code in SolrJ where there needs to be much more care.  Not
> >> sure what it would be named though... any way it's another issue perhaps 
> >> for
> >> 7.0.
> >> I'll work on the ref guide tonight.
> >> ~ David
> >>
> >> On Tue, Jan 10, 2017 at 11:57 AM Cassandra Targett  >> >
> >> wrote:
> >>>
> >>> (note: I replied to this thread earlier not noticing that dev@l.a.o 
> >>> 
> >>> was removed from the message I replied to...reposting the relevant
> >>> part here for posterity or whatever...)
> >>>
> >>> [Regarding] reworking the Highlighting section, I'm +1 on the changes you
> >>> propose, David. It's a bit of a mess, and not very consistent in the
> >>> ways configuration options are described for each of the
> >>> implementations.
> >>>
> >>> I generally prefer to name things along the lines they are named in
> >>> the code, but in this case there's already a disconnect between
> >>> "Standard Highlighter" and the DefaultSolrHighlighter. I wonder,
> >>> though, if it would be a good idea to rename the
> >>> DefaultSolrHighlighter? Perhaps it's too early to make such a change,
> >>> but it's worth a moment's thought if you haven't already.
> >>>
> >>> Thanks for taking this on - I was briefly looking at UH yesterday and
> >>> considering how to integrate it with the current docs. I didn't get
> >>> very far, and found it a bit daunting, so I appreciate your assistance
> >>> for sure. Please let me know if you need any help or review from me.
> >>>
> >>> On Mon, Jan 9, 2017 at 11:17 PM, David Smiley  >>> >
> >>> wrote:
> >>> > Unfortunately, The Solr Ref Guide is only editable by committers.  In
> >>> > the
> >>> > near future it's going to move to a different platform that will allow
> >>> > you
> >>> > to contribute via pull-request; that will be very nice.  In the mean
> >>> > time,
> >>> > your feedback is highly appreciated.
> >>> >
> >>> > ~ David
> >>> >
> >>> > On Mon, Jan 9, 2017 at 6:21 PM Timothy Rodriguez (BLOOMBERG/ 120 PARK)
> >>> > > wrote:
> >>> >>
> >>> >> +1, I'll be happy to offer assistance with edits or some of the
> >>> >> sections
> >>> >> if needed. We're glad to see this out there.
> >>> >>
> >>> >> From: dev@lucene.apache.org  At: 
> >>> >> 01/09/17 18:03:32
> >>> >> To: Timothy Rodriguez (BLOOMBERG/ 120 PARK), dev@lucene.apache.org 
> >>> >> 
> >>> >> Subject: Re:Solr Ref Guide, Highlighting
> >>> >>
> >>> >> Solr 6.4 is the first release to introduce the UnifiedHighlighter as a
> >>> >> new
> >>> >> highlighter option.  I want to get it documented reasonably well in
> >>> >> the Solr
> >>> >> Ref Guide.  The Highlighters section is here: Highlighting   (lets see
> >>> >> if
> >>> >> this formatted email expands to the URL when it lands on the list)
> >>> >>
> >>> >> Unless anyone objects, I'd like to rename the "Standard Highlighter"
> >>> >> as
> >>> >> "Original Highlighter" in the ref guide.  The original Highlighter has
> >>> >> no
> >>> >> actual name qualifications as it was indeed Lucene's original
> >>> >> Highlighter.
> >>> >> "Standard Highlighter" as a name purely exists as-such within the Solr
> >>> >> Reference Guide only.  In our code it's used by
> >>> >> "DefaultSolrHighlighter"
> >>> >> which is really a combo of the original 

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[jefferyyuan (JIRA)]

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

jefferyyuan commented on SOLR-6246:
---

>From 
>https://builds.apache.org/job/Solr-Artifacts-6.x/lastSuccessfulBuild/artifact/solr/package/
- it was build 195 when I downloaded at that time

I will try the newest build and check whether this works

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
> Attachments: SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



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

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

Re: Solr Ref Guide, Highlighting

[Timothy Rodriguez (BLOOMBERG/ 120 PARK)]

I've made some edits and additions in word with tracked changes to the Solr Ref 
guide.  I couldn't think of a better way to send out the changes.  Let me know 
if you'd like me to send in some other fashion.

-Tim


From: dev@lucene.apache.org At: 01/11/17 15:53:39
To: dev@lucene.apache.org
Cc: Timothy Rodriguez (BLOOMBERG/ 120 PARK)
Subject: Re: Solr Ref Guide, Highlighting

Yes, I can help - I meant to try today, but tomorrow looks much
clearer schedule-wise to focus on Ref Guide.

On Wed, Jan 11, 2017 at 12:32 AM, David Smiley  wrote:
> I made some progress... I'm having flashbacks to book-writing; ugh. If you
> wish to help Cassandra, I think a great spot would be the "Basic Usage"
> section I inserted.  I'll save that for last if nobody gets to it.  I need
> to do the end of the page, and then add a UH page and deal with the other
> highlighter pages.
>
> On Tue, Jan 10, 2017 at 12:20 PM David Smiley 
> wrote:
>>
>> Thanks for your input Cassandra.
>> Within the code, DefaultSolrHighlighter.java can be renamed; it's not set
>> in stone unlike code in SolrJ where there needs to be much more care.  Not
>> sure what it would be named though... any way it's another issue perhaps for
>> 7.0.
>> I'll work on the ref guide tonight.
>> ~ David
>>
>> On Tue, Jan 10, 2017 at 11:57 AM Cassandra Targett 
>> wrote:
>>>
>>> (note: I replied to this thread earlier not noticing that dev@l.a.o
>>> was removed from the message I replied to...reposting the relevant
>>> part here for posterity or whatever...)
>>>
>>> [Regarding] reworking the Highlighting section, I'm +1 on the changes you
>>> propose, David. It's a bit of a mess, and not very consistent in the
>>> ways configuration options are described for each of the
>>> implementations.
>>>
>>> I generally prefer to name things along the lines they are named in
>>> the code, but in this case there's already a disconnect between
>>> "Standard Highlighter" and the DefaultSolrHighlighter. I wonder,
>>> though, if it would be a good idea to rename the
>>> DefaultSolrHighlighter? Perhaps it's too early to make such a change,
>>> but it's worth a moment's thought if you haven't already.
>>>
>>> Thanks for taking this on - I was briefly looking at UH yesterday and
>>> considering how to integrate it with the current docs. I didn't get
>>> very far, and found it a bit daunting, so I appreciate your assistance
>>> for sure. Please let me know if you need any help or review from me.
>>>
>>> On Mon, Jan 9, 2017 at 11:17 PM, David Smiley 
>>> wrote:
>>> > Unfortunately, The Solr Ref Guide is only editable by committers.  In
>>> > the
>>> > near future it's going to move to a different platform that will allow
>>> > you
>>> > to contribute via pull-request; that will be very nice.  In the mean
>>> > time,
>>> > your feedback is highly appreciated.
>>> >
>>> > ~ David
>>> >
>>> > On Mon, Jan 9, 2017 at 6:21 PM Timothy Rodriguez (BLOOMBERG/ 120 PARK)
>>> >  wrote:
>>> >>
>>> >> +1, I'll be happy to offer assistance with edits or some of the
>>> >> sections
>>> >> if needed. We're glad to see this out there.
>>> >>
>>> >> From: dev@lucene.apache.org At: 01/09/17 18:03:32
>>> >> To: Timothy Rodriguez (BLOOMBERG/ 120 PARK), dev@lucene.apache.org
>>> >> Subject: Re:Solr Ref Guide, Highlighting
>>> >>
>>> >> Solr 6.4 is the first release to introduce the UnifiedHighlighter as a
>>> >> new
>>> >> highlighter option.  I want to get it documented reasonably well in
>>> >> the Solr
>>> >> Ref Guide.  The Highlighters section is here: Highlighting   (lets see
>>> >> if
>>> >> this formatted email expands to the URL when it lands on the list)
>>> >>
>>> >> Unless anyone objects, I'd like to rename the "Standard Highlighter"
>>> >> as
>>> >> "Original Highlighter" in the ref guide.  The original Highlighter has
>>> >> no
>>> >> actual name qualifications as it was indeed Lucene's original
>>> >> Highlighter.
>>> >> "Standard Highlighter" as a name purely exists as-such within the Solr
>>> >> Reference Guide only.  In our code it's used by
>>> >> "DefaultSolrHighlighter"
>>> >> which is really a combo of the original Highlighter and
>>> >> FastVectorHighlighter.   DSH ought to be refactored perhaps... but I
>>> >> digress.
>>> >>
>>> >> For those that haven't read CHANGES.txt yet, there is a new
>>> >> "hl.method"
>>> >> parameter which can be used to pick your highlighter.  Here I
>>> >> purposely
>>> >> chose a possible value of "original" to choose the original
>>> >> Highlighter (not
>>> >> "standard").
>>> >>
>>> >> I haven't started documenting yet but I plan to refactor the
>>> >> highlighter
>>> >> docs a bit.  The intro page will better discuss the highlighter
>>> >> options and
>>> >> also how to configure both term vectors and offsets in postings.  Then
>>> >> the
>>> >> highlighter implementation specific pages will document the parameters
>>> >> and

[jira] [Commented] (LUCENE-7628) Add a getMatchingChildren() method to DisjunctionScorer

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-7628:
--

Hopefully this is not getting too far off topic.

In case there is interest in taking DocIdSetIterator out of Spans, please let 
me know, I have version that passes the lucene tests.
I don't know whether it speeds up Spans.
The split makes a lot of the Spans code more readable.

> Add a getMatchingChildren() method to DisjunctionScorer
> ---
>
> Key: LUCENE-7628
> URL: https://issues.apache.org/jira/browse/LUCENE-7628
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-7628.patch
>
>
> This one is a bit convoluted, so bear with me...
> The luwak highlighter works by rewriting queries into their Span-equivalents, 
> and then running them with a special Collector.  At each matching doc, the 
> highlighter gathers all the Spans objects positioned on the current doc and 
> collects their positions using the SpanCollection API.
> Some queries can't be translated into Spans.  For those queries that generate 
> Scorers with ChildScorers, like BooleanQuery, we can call .getChildren() on 
> the Scorer and see if any of them are SpanScorers, and for those that aren't 
> we can call .getChildren() again and recurse down.  For each child scorer, we 
> check that it's positioned on the current document, so non-matching 
> subscorers can be skipped.
> This all works correctly *except* in the case of a DisjunctionScorer where 
> one of the children is a two-phase iterator that has matched its 
> approximation, but not its refinement query.  A SpanScorer in this situation 
> will be correctly positioned on the current document, but its Spans will be 
> in an undefined state, meaning the highlighter will either collect incorrect 
> hits, or it will throw an Exception and prevent hits being collected from 
> other subspans.
> We've tried various ways around this (including forking SpanNearQuery and 
> adding a bunch of slow position checks to it that are used only by the 
> highlighting code), but it turns out that the simplest fix is to add a new 
> method to DisjunctionScorer that only returns the currently matching child 
> Scorers.  It's a bit of a hack, and it won't be used anywhere else, but it's 
> a fairly small and contained hack.



--
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-9952) S3BackupRepository

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-9952:


Ah that makes sense! That is good to know. Thanks [~hgadre]!

> S3BackupRepository
> --
>
> Key: SOLR-9952
> URL: https://issues.apache.org/jira/browse/SOLR-9952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: Running Solr on S3.pdf
>
>
> I'd like to have a backup repository implementation allows to snapshot to AWS 
> S3



--
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-9952) S3BackupRepository

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9952:


Ok let me take my statement back. The problem is that we are *reusing* system 
properties in the solr.xml. May be if we use absolute params, we should be OK.

{noformat}


  ${solr.hdfs.home:}
  ${solr.hdfs.confdir:}
  ${solr.hdfs.security.kerberos.enabled:false}
  ${solr.hdfs.security.kerberos.keytabfile:}
  ${solr.hdfs.security.kerberos.principal:}
  ${solr.hdfs.permissions.umask-mode:000}

  
{noformat}

> S3BackupRepository
> --
>
> Key: SOLR-9952
> URL: https://issues.apache.org/jira/browse/SOLR-9952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: Running Solr on S3.pdf
>
>
> I'd like to have a backup repository implementation allows to snapshot to AWS 
> S3



--
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-9952) S3BackupRepository

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre edited comment on SOLR-9952 at 1/13/17 9:21 PM:
-

Ok let me take my statement back. The problem is that we are *reusing* system 
properties in the solr.xml. If we use absolute params, we should be OK.

{noformat}


  ${solr.hdfs.home:}
  ${solr.hdfs.confdir:}
  ${solr.hdfs.security.kerberos.enabled:false}
  ${solr.hdfs.security.kerberos.keytabfile:}
  ${solr.hdfs.security.kerberos.principal:}
  ${solr.hdfs.permissions.umask-mode:000}

  
{noformat}


was (Author: hgadre):
Ok let me take my statement back. The problem is that we are *reusing* system 
properties in the solr.xml. May be if we use absolute params, we should be OK.

{noformat}


  ${solr.hdfs.home:}
  ${solr.hdfs.confdir:}
  ${solr.hdfs.security.kerberos.enabled:false}
  ${solr.hdfs.security.kerberos.keytabfile:}
  ${solr.hdfs.security.kerberos.principal:}
  ${solr.hdfs.permissions.umask-mode:000}

  
{noformat}

> S3BackupRepository
> --
>
> Key: SOLR-9952
> URL: https://issues.apache.org/jira/browse/SOLR-9952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: Running Solr on S3.pdf
>
>
> I'd like to have a backup repository implementation allows to snapshot to AWS 
> S3



--
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-7628) Add a getMatchingChildren() method to DisjunctionScorer

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-7628:
--

To continue about using Spans directly for this
(earlier posted on github, see 
https://github.com/flaxsearch/luwak/commit/36c91e8bdd3ab0d07578b76359d1f2a87eb53797)

Other than AND and OR in the same field, what is also still needed is dealing 
with multiple fields.
For this we need a Spans that can share its DocIdSetIterator with another Spans.

Iirc that is what LUCENE-2878 is about, so I'm finally beginning to understand 
the real point of that issue, and why it is still open.

Meanwhile we had DocIdSetIterator split off from Searcher (for speed).
How about doing something similar for Spans? I think that would leave Spans 
pretty close to the Positions of LUCENE-2787. The only change in semantics for 
Spans would be that at least one of the Spans that share a DocIdSetIterator 
should provide a real position in a document. Maybe we could have sth like 
MultiFieldSpans for that.

> Add a getMatchingChildren() method to DisjunctionScorer
> ---
>
> Key: LUCENE-7628
> URL: https://issues.apache.org/jira/browse/LUCENE-7628
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-7628.patch
>
>
> This one is a bit convoluted, so bear with me...
> The luwak highlighter works by rewriting queries into their Span-equivalents, 
> and then running them with a special Collector.  At each matching doc, the 
> highlighter gathers all the Spans objects positioned on the current doc and 
> collects their positions using the SpanCollection API.
> Some queries can't be translated into Spans.  For those queries that generate 
> Scorers with ChildScorers, like BooleanQuery, we can call .getChildren() on 
> the Scorer and see if any of them are SpanScorers, and for those that aren't 
> we can call .getChildren() again and recurse down.  For each child scorer, we 
> check that it's positioned on the current document, so non-matching 
> subscorers can be skipped.
> This all works correctly *except* in the case of a DisjunctionScorer where 
> one of the children is a two-phase iterator that has matched its 
> approximation, but not its refinement query.  A SpanScorer in this situation 
> will be correctly positioned on the current document, but its Spans will be 
> in an undefined state, meaning the highlighter will either collect incorrect 
> hits, or it will throw an Exception and prevent hits being collected from 
> other subspans.
> We've tried various ways around this (including forking SpanNearQuery and 
> adding a bunch of slow position checks to it that are used only by the 
> highlighting code), but it turns out that the simplest fix is to add a new 
> method to DisjunctionScorer that only returns the currently matching child 
> Scorers.  It's a bit of a hack, and it won't be used anywhere else, but it's 
> a fairly small and contained hack.



--
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-9952) S3BackupRepository

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-9952:


It would mean that you would need different namespaces per each repository so 
that two HdfsBackupRepositories don't interfere with each other.

> S3BackupRepository
> --
>
> Key: SOLR-9952
> URL: https://issues.apache.org/jira/browse/SOLR-9952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: Running Solr on S3.pdf
>
>
> I'd like to have a backup repository implementation allows to snapshot to AWS 
> S3



--
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-9952) S3BackupRepository

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9952:


Yes I was about to say that! How about modifying HdfsBackupRepository to use 
different configuration namespace ?

> S3BackupRepository
> --
>
> Key: SOLR-9952
> URL: https://issues.apache.org/jira/browse/SOLR-9952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: Running Solr on S3.pdf
>
>
> I'd like to have a backup repository implementation allows to snapshot to AWS 
> S3



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/617/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)  
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:202)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94)  at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:102)
  at sun.reflect.GeneratedConstructorAccessor182.newInstance(Unknown Source)  
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)  at 
org.apache.solr.core.SolrCore.createInstance(SolrCore.java:753)  at 
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:815)  at 
org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1065)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:930)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:823)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:889)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:541)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [HdfsTransactionLog]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:202)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94)
at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:102)
at sun.reflect.GeneratedConstructorAccessor182.newInstance(Unknown 
Source)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:753)
at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:815)
at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1065)
at org.apache.solr.core.SolrCore.(SolrCore.java:930)
at org.apache.solr.core.SolrCore.(SolrCore.java:823)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:889)
at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:541)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


at __randomizedtesting.SeedInfo.seed([E2FA96AD0169BB22]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:269)
at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-9952) S3BackupRepository

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-9952:


Hmmm that seems to be not a great idea. Does that mean right now its not 
possible to provide two different HDFS Backup Repositories each pointing to a 
different cluster?

> S3BackupRepository
> --
>
> Key: SOLR-9952
> URL: https://issues.apache.org/jira/browse/SOLR-9952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: Running Solr on S3.pdf
>
>
> I'd like to have a backup repository implementation allows to snapshot to AWS 
> S3



--
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-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-6246:
--

[~jefferyyuan], Solr 6.4 has not yet been released - where did "solr-6.4.0-195" 
come from?

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
> Attachments: SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



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

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

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[jefferyyuan (JIRA)]

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

jefferyyuan commented on SOLR-6246:
---

I am running on Solr 6.4 - solr-6.4.0-195.
But the problem still exists. Even restarting solr doesn't work - after restart 
solr and reload collection or current node still fails with 
LockObtainFailedException.

I even tried to manually delete the write.lock, then call 
reload-collection/cores , it still failed again with same error.

INFO  - 2017-01-12 16:55:42.392; [c:myCollection s:shard2 r:core_node3 
x:searchItems_shard2_replica1] org.apache.solr.servlet.HttpSolrCall; [admin] 
webapp=null path=/admin/cores 
params={core=searchItems_shard2_replica1=/admin/cores=RELOAD=javabin=2}
 status=500 QTime=592
ERROR - 2017-01-12 16:55:42.393; [c:myCollection s:shard2 r:core_node3 
x:searchItems_shard2_replica1] org.apache.solr.common.SolrException; 
null:org.apache.solr.common.SolrException: Error handling 'reload' action
at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$2(CoreAdminOperation.java:114)
at 
org.apache.solr.handler.admin.CoreAdminOperation$$Lambda$23/265321659.execute(Unknown
 Source)
at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:377)
at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:365)
at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:156)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:152)
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:664)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:445)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.solr.common.SolrException: Unable to reload core 
[searchItems_shard2_replica1]
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:950)
at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$2(CoreAdminOperation.java:112)
... 34 more
Caused by: org.apache.solr.common.SolrException: 
org.apache.lucene.store.LockObtainFailedException: Lock held by this virtual 
machine: 
/Applications/solr-6.4.0/example/cloud/node2/solr/searchItems_shard2_replica1/data/infix_suggestions/write.lock
at org.apache.solr.core.SolrCore.(SolrCore.java:899)
at 

[jira] [Commented] (SOLR-9952) S3BackupRepository

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9952:


[~risdenk] [~cahilltr] Please note that HDFS backup repository implementation 
reuses the configuration parameters required by the HdfsDirectory 
implementation. Hence the suggested approach won't work if you are using 
HdfsDirectory to store the Solr collection data. While we should certainly use 
the HDFS/S3 connector for S3BackupRepository, we need to have a separate 
implementation of BackupRepository interface which has *different* 
configuration namespace. That will allow everyone (including Solr + HDFS users) 
to use this functionality.


> S3BackupRepository
> --
>
> Key: SOLR-9952
> URL: https://issues.apache.org/jira/browse/SOLR-9952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: Running Solr on S3.pdf
>
>
> I'd like to have a backup repository implementation allows to snapshot to AWS 
> S3



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_112) - Build # 18768 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18768/
Java: 64bit/jdk1.8.0_112 -XX:+UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestCoreContainer

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

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


FAILED:  org.apache.solr.core.TestCoreContainer.testLogWatcherEnabledByDefault

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([1BDBB1887CBC749C]:0)




Build Log:
[...truncated 13017 lines...]
   [junit4] Suite: org.apache.solr.core.TestCoreContainer
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.core.TestCoreContainer_1BDBB1887CBC749C-001/init-core-data-001
   [junit4]   2> 931568 INFO  
(SUITE-TestCoreContainer-seed#[1BDBB1887CBC749C]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 931570 INFO  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
] o.a.s.SolrTestCaseJ4 ###Starting testClassLoaderHierarchy
   [junit4]   2> 931598 INFO  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
] o.a.s.c.CorePropertiesLocator Found 0 core definitions underneath 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.core.TestCoreContainer_1BDBB1887CBC749C-001/tempDir-001
   [junit4]   2> 931612 INFO  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
x:core1] o.a.s.c.SolrConfig Using Lucene MatchVersion: 7.0.0
   [junit4]   2> 931617 INFO  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
x:core1] o.a.s.s.IndexSchema [core1] Schema name=minimal
   [junit4]   2> 931618 WARN  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
x:core1] o.a.s.s.IndexSchema no uniqueKey specified in schema.
   [junit4]   2> 931618 INFO  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
x:core1] o.a.s.s.IndexSchema Loaded schema minimal/1.1 with uniqueid field null
   [junit4]   2> 931620 INFO  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
x:core1] o.a.s.c.CoreContainer Creating SolrCore 'core1' using configuration 
from configset 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/configsets/minimal
   [junit4]   2> 931620 INFO  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
x:core1] o.a.s.c.SolrCore [[core1] ] Opening new SolrCore at 
[/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/configsets/minimal],
 
dataDir=[/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.core.TestCoreContainer_1BDBB1887CBC749C-001/tempDir-001/core1/data/]
   [junit4]   2> 931630 INFO  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
x:core1] o.a.s.u.CommitTracker Hard AutoCommit: disabled
   [junit4]   2> 931630 INFO  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
x:core1] o.a.s.u.CommitTracker Soft AutoCommit: disabled
   [junit4]   2> 931631 INFO  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
x:core1] o.a.s.s.SolrIndexSearcher Opening [Searcher@730139a5[core1] main]
   [junit4]   2> 931631 WARN  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
x:core1] o.a.s.r.ManagedResourceStorage Cannot write to config directory 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/configsets/minimal/conf;
 switching to use InMemory storage instead.
   [junit4]   2> 931631 INFO  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
x:core1] o.a.s.h.ReplicationHandler Commits will be reserved for  1
   [junit4]   2> 931631 INFO  
(searcherExecutor-5392-thread-1-processing-x:core1) [x:core1] 
o.a.s.c.SolrCore [core1] Registered new searcher Searcher@730139a5[core1] 
main{ExitableDirectoryReader(UninvertingDirectoryReader())}
   [junit4]   2> 931632 INFO  
(TEST-TestCoreContainer.testClassLoaderHierarchy-seed#[1BDBB1887CBC749C]) [
x:core1] o.a.s.c.CoreContainer Shutting down CoreContainer instance=770348671
   [junit4]   2> 931632 INFO  
(coreCloseExecutor-5396-thread-1-processing-x:core1) [x:core1] 
o.a.s.c.SolrCore [core1]  CLOSING SolrCore 
org.apache.solr.core.SolrCore@3d2c9b8b
   [junit4]   2> 931633 INFO  
(coreCloseExecutor-5396-thread-1-processing-x:core1) [x:core1] 
o.a.s.m.SolrMetricManager Closing metric 

[jira] [Commented] (SOLR-9954) SnapShooter createSnapshot can swallow an exception raised by the underlying backup repo

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9954:


[~thelabdude] [~varunthacker] Should we check file-permissions upfront ? Seems 
better from usability perspective...

> SnapShooter createSnapshot can swallow an exception raised by the underlying 
> backup repo
> 
>
> Key: SOLR-9954
> URL: https://issues.apache.org/jira/browse/SOLR-9954
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration
>Affects Versions: 6.2.1, 6.3
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9954.patch
>
>
> While configuring the HdfsBackupRepository to use Google compute storage, I 
> misconfigured the permissions on my bucket. Unfortunately, the exception that 
> would have pointed me in the right direction gets squelched by the finally 
> block in createSnapshot:
> {code}
> } finally {
>   if (!success) {
> backupRepo.deleteDirectory(snapshotDirPath);
>   }
> }
> {code}
> If there's a permissions issue, then the deleteDelectory is going to fail and 
> raise another exception from the finally block, which swallows the original 
> exception. For example:
> {code}
> ERROR - 2017-01-10 18:38:52.650; [c:gettingstarted s:shard1 r:core_node1 
> x:gettingstarted_shard1_replica1] org.apache.solr.handler.SnapShooter; 
> Exception while creating snapshot
> java.io.IOException: GoogleHadoopFileSystem has been closed or not 
> initialized.
> at 
> com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase.checkOpen(GoogleHadoopFileSystemBase.java:1927)
> at 
> com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase.delete(GoogleHadoopFileSystemBase.java:1255)
> at 
> org.apache.solr.core.backup.repository.HdfsBackupRepository.deleteDirectory(HdfsBackupRepository.java:160)
> at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:234)
> at 
> org.apache.solr.handler.SnapShooter.lambda$createSnapAsync$1(SnapShooter.java:186)
> at org.apache.solr.handler.SnapShooter$$Lambda$89/43739789.run(Unknown 
> Source)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> That's merely the symptom and not the actual cause of the failure.



--
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-9961) RestoreCore needs the option to download files in parallel.

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9961:


[~thelabdude] I think this is a great improvement! Couple of comments,

bq. But as stated in the description, this now causes the various FileSystem 
already closed issue, so would need to be used with hdfs cache disabled.

I think the root cause of this problem is the fact that HdfsDirectory is using 
FileSystem.get(...) API. If we change that to FileSystem.newInstance(...) that 
problem will most likely go away. I think this would be a better solution than 
disabling HDFS caching. [~markrmil...@gmail.com] any thoughts?

bq. adds an option for BackupRepository implementations to download in parallel 
using a thread pool.

It seems a bit odd to add this configuration to BackupRepository interface. If 
we can ensure that all BackupRepository implementations to support concurrent 
copy operations then we can make the thread-pool and time out configurations 
global. For this to be feasible, the BackupRepository implementation just needs 
to make sure that the client state kept separate for each copy operation (which 
I think is doable)

The other approach could be to add another API in BackupRepository interface 
which accepts a list of files to be copied. The implementation of this API can 
choose to use multi-threaded (or a sequential) execution. This can even benefit 
backup operation. What do you think ?

Also as a minor comment, did you think about using CompletionService to fetch 
the results of completed tasks? Seems a bit cleaner...
   


> RestoreCore needs the option to download files in parallel.
> ---
>
> Key: SOLR-9961
> URL: https://issues.apache.org/jira/browse/SOLR-9961
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 6.2.1
>Reporter: Timothy Potter
> Attachments: SOLR-9961.patch, SOLR-9961.patch
>
>
> My backup to cloud storage (Google cloud storage in this case, but I think 
> this is a general problem) takes 8 minutes ... the restore of the same core 
> takes hours. The restore loop in RestoreCore is serial and doesn't allow me 
> to parallelize the expensive part of this operation (the IO from the remote 
> cloud storage service). We need the option to parallelize the download (like 
> distcp). 
> Also, I tried downloading the same directory using gsutil and it was very 
> fast, like 2 minutes. So I know it's not the pipe that's limiting perf here.
> Here's a very rough patch that does the parallelization. We may also want to 
> consider a two-step approach: 1) download in parallel to a temp dir, 2) 
> perform all the of the checksum validation against the local temp dir. That 
> will save round trips to the remote cloud storage.



--
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: 6.4 release

[jim ferenczi]

Great news Uwe! I'll cut the branch this week end if nobody disagree.

Le 13 janv. 2017 20:24, "Uwe Schindler"  a écrit :

> Hi Jim,
>
>
>
> I updated Groovy. I’d like to run Solr tests this evening through Jenkins
> with Java 9 EA build 151 to get a list of all tests that have to be
> disabled for Java 9, but otherwise we are ready.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* jim ferenczi [mailto:jim.feren...@gmail.com]
> *Sent:* Monday, January 9, 2017 12:37 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: 6.4 release
>
>
>
> Thanks for sharing Uwe. It would be wonderful to make latest java9 works
> with the released version. I can delay the branching until
> https://issues.apache.org/jira/browse/LUCENE-7596 is closed ?
>
> In the mean time I am trying to create the release notes in the wiki but I
> don't have the permissions to create the pages. Where can I get such
> permissions ?
>
>
>
> 2017-01-09 11:13 GMT+01:00 Uwe Schindler :
>
> Hi,
>
>
>
> I am fine with the start of release process, but I would like to add one
> thing:
>
>
>
> I know that Elasticsearch wants to be compatible with recent Java 9 for
> the continuous delievery process. The new Lucene release is compatible with
> that (mmap unmapping works), but you cannot build the release with Java 9
> 148+. Currently the release vote of Groovy 2.4.8 is ongoing and should
> finish the next few days. So I’d suggest to delay a bit, so I can update
> common-build.xml and raise the Groovy version: https://issues.apache.org/
> jira/browse/LUCENE-7596
>
>
>
> This does not make Solr Tests work with Java 9, but that’s a different
> discussion (mocking frameworks broke with recent Java 9):
> https://issues.apache.org/jira/browse/SOLR-9893
>
> I will fix this by disabling those tests with Java 9, but that a bit of
> work to set those assumeFalse(Constants.JAVA9….). I don’t see this as a
> blocker!
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* jim ferenczi [mailto:jim.feren...@gmail.com]
> *Sent:* Tuesday, January 3, 2017 5:23 PM
> *To:* dev@lucene.apache.org
> *Subject:* 6.4 release
>
>
>
> Hi,
> I would like to volunteer to release 6.4. I can cut the release branch
> next Monday if everybody agrees.
>
>
>
> Jim
>
>
>

[jira] [Updated] (SOLR-9961) RestoreCore needs the option to download files in parallel.

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-9961:
-
Attachment: SOLR-9961.patch

Here's an updated patch (created against 6.3.0 tag) -p0 style that adds an 
option for {{BackupRepository}} implementations to download in parallel using a 
thread pool. But as stated in the description, this now causes the various 
FileSystem already closed issue, so would need to be used with hdfs cache 
disabled.

I've tested this on a 10G index in Google cloud storage and it completed in ~30 
mins vs. hours or not at all.

> RestoreCore needs the option to download files in parallel.
> ---
>
> Key: SOLR-9961
> URL: https://issues.apache.org/jira/browse/SOLR-9961
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 6.2.1
>Reporter: Timothy Potter
> Attachments: SOLR-9961.patch, SOLR-9961.patch
>
>
> My backup to cloud storage (Google cloud storage in this case, but I think 
> this is a general problem) takes 8 minutes ... the restore of the same core 
> takes hours. The restore loop in RestoreCore is serial and doesn't allow me 
> to parallelize the expensive part of this operation (the IO from the remote 
> cloud storage service). We need the option to parallelize the download (like 
> distcp). 
> Also, I tried downloading the same directory using gsutil and it was very 
> fast, like 2 minutes. So I know it's not the pipe that's limiting perf here.
> Here's a very rough patch that does the parallelization. We may also want to 
> consider a two-step approach: 1) download in parallel to a temp dir, 2) 
> perform all the of the checksum validation against the local temp dir. That 
> will save round trips to the remote cloud storage.



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

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1077 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1077/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

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

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([4D52461D5849BB5:8C811BBB7B78F64D]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

RE: 6.4 release

[Uwe Schindler]

Hi Jim,

 

I updated Groovy. I’d like to run Solr tests this evening through Jenkins with 
Java 9 EA build 151 to get a list of all tests that have to be disabled for 
Java 9, but otherwise we are ready.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: jim ferenczi [mailto:jim.feren...@gmail.com] 
Sent: Monday, January 9, 2017 12:37 PM
To: dev@lucene.apache.org
Subject: Re: 6.4 release

 

Thanks for sharing Uwe. It would be wonderful to make latest java9 works with 
the released version. I can delay the branching until 
https://issues.apache.org/jira/browse/LUCENE-7596 is closed ? 

In the mean time I am trying to create the release notes in the wiki but I 
don't have the permissions to create the pages. Where can I get such 
permissions ? 

 

2017-01-09 11:13 GMT+01:00 Uwe Schindler  >:

Hi,

 

I am fine with the start of release process, but I would like to add one thing:

 

I know that Elasticsearch wants to be compatible with recent Java 9 for the 
continuous delievery process. The new Lucene release is compatible with that 
(mmap unmapping works), but you cannot build the release with Java 9 148+. 
Currently the release vote of Groovy 2.4.8 is ongoing and should finish the 
next few days. So I’d suggest to delay a bit, so I can update common-build.xml 
and raise the Groovy version: https://issues.apache.org/jira/browse/LUCENE-7596

 

This does not make Solr Tests work with Java 9, but that’s a different 
discussion (mocking frameworks broke with recent Java 9): 
https://issues.apache.org/jira/browse/SOLR-9893

I will fix this by disabling those tests with Java 9, but that a bit of work to 
set those assumeFalse(Constants.JAVA9….). I don’t see this as a blocker!

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de  

 

From: jim ferenczi [mailto:jim.feren...@gmail.com 
 ] 
Sent: Tuesday, January 3, 2017 5:23 PM
To: dev@lucene.apache.org  
Subject: 6.4 release

 

Hi,
I would like to volunteer to release 6.4. I can cut the release branch next 
Monday if everybody agrees.

 

Jim

 

[jira] [Commented] (LUCENE-7596) Update Groovy to 2.4.8 in build system

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7596: Update Groovy to version 2.4.8 to allow building with Java 9 build 
148+. Also update JGit version for working-copy checks.


> Update Groovy to 2.4.8 in build system
> --
>
> Key: LUCENE-7596
> URL: https://issues.apache.org/jira/browse/LUCENE-7596
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: 6.x, master (7.0), 6.4
>
>
> The current version of Groovy used by several Ant components is incompatible 
> with Java 9 build 148+. We need to update to 2.4.8 once it is released: 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-December/010474.html



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

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

[jira] [Resolved] (LUCENE-7596) Update Groovy to 2.4.8 in build system

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved LUCENE-7596.
---
Resolution: Fixed

> Update Groovy to 2.4.8 in build system
> --
>
> Key: LUCENE-7596
> URL: https://issues.apache.org/jira/browse/LUCENE-7596
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: 6.x, master (7.0), 6.4
>
>
> The current version of Groovy used by several Ant components is incompatible 
> with Java 9 build 148+. We need to update to 2.4.8 once it is released: 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-December/010474.html



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

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

[jira] [Commented] (LUCENE-7596) Update Groovy to 2.4.8 in build system

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7596: Update Groovy to version 2.4.8 to allow building with Java 9 build 
148+. Also update JGit version for working-copy checks.


> Update Groovy to 2.4.8 in build system
> --
>
> Key: LUCENE-7596
> URL: https://issues.apache.org/jira/browse/LUCENE-7596
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: 6.x, master (7.0), 6.4
>
>
> The current version of Groovy used by several Ant components is incompatible 
> with Java 9 build 148+. We need to update to 2.4.8 once it is released: 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-December/010474.html



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

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

[jira] [Commented] (SOLR-9961) RestoreCore needs the option to download files in parallel.

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-9961:
--

The other thing I found here is HdfsDirectory is closing a shared FileSystem 
object because HdfsBackupRepository uses try with resources:

{code}
  @Override
  public void copyFileTo(URI sourceRepo, String fileName, Directory dest) 
throws IOException {
try (HdfsDirectory dir = new HdfsDirectory(new Path(sourceRepo), 
NoLockFactory.INSTANCE,
hdfsConfig, HdfsDirectory.DEFAULT_BUFFER_SIZE * 10)) {
  dest.copyFrom(dir, fileName, fileName, 
DirectoryFactory.IOCONTEXT_NO_CACHE);
}
  }
{code}

This closes the FileSystem object that was retrieved with FileSystem.get. 
Because of this (I think), I'm seeing lots of errors like the following while 
doing the restore:
{code}
WARN  - 2017-01-13 14:09:44.249; [   ] org.apache.solr.handler.RestoreCore; 
Exception while restoring the backup index 
java.lang.RuntimeException: Problem creating directory: 
gs://hd-fusion/aggr_solr/myAggr3/snapshot.shard1
at 
org.apache.solr.store.hdfs.HdfsDirectory.(HdfsDirectory.java:91)
at 
org.apache.solr.core.backup.repository.HdfsBackupRepository.copyFileTo(HdfsBackupRepository.java:175)
at 
org.apache.solr.handler.RestoreCore.downloadFile(RestoreCore.java:196)
at org.apache.solr.handler.RestoreCore.access$000(RestoreCore.java:47)
at org.apache.solr.handler.RestoreCore$1.call(RestoreCore.java:101)
at org.apache.solr.handler.RestoreCore$1.call(RestoreCore.java:99)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: GoogleHadoopFileSystem has been closed or not 
initialized.
at 
com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase.checkOpen(GoogleHadoopFileSystemBase.java:1802)
at 
com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase.getFileStatus(GoogleHadoopFileSystemBase.java:1284)
at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1424)
at 
org.apache.solr.store.hdfs.HdfsDirectory.(HdfsDirectory.java:83)
... 9 more
{code}

There's a handy prop that allows you to disable the cache (add to 
core-site.xml), which makes this error go away:
{code}
  
fs.gs.impl.disable.cache
true
  
{code}

> RestoreCore needs the option to download files in parallel.
> ---
>
> Key: SOLR-9961
> URL: https://issues.apache.org/jira/browse/SOLR-9961
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 6.2.1
>Reporter: Timothy Potter
> Attachments: SOLR-9961.patch
>
>
> My backup to cloud storage (Google cloud storage in this case, but I think 
> this is a general problem) takes 8 minutes ... the restore of the same core 
> takes hours. The restore loop in RestoreCore is serial and doesn't allow me 
> to parallelize the expensive part of this operation (the IO from the remote 
> cloud storage service). We need the option to parallelize the download (like 
> distcp). 
> Also, I tried downloading the same directory using gsutil and it was very 
> fast, like 2 minutes. So I know it's not the pipe that's limiting perf here.
> Here's a very rough patch that does the parallelization. We may also want to 
> consider a two-step approach: 1) download in parallel to a temp dir, 2) 
> perform all the of the checksum validation against the local temp dir. That 
> will save round trips to the remote cloud storage.



--
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-9963) Add Calcite Avatica handler to Solr

[Kevin Risden (JIRA)]

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

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

First patch that demonstrates that this is possible.

> Add Calcite Avatica handler to Solr
> ---
>
> Key: SOLR-9963
> URL: https://issues.apache.org/jira/browse/SOLR-9963
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Reporter: Kevin Risden
> Attachments: SOLR-9963.patch
>
>
> Calcite Avatica has an http endpoint which allows Avatica drivers to connect 
> to the server. This can be wired in as a handler to Solr. This would allow 
> Solr to be used by any Avatica JDBC/ODBC driver. This depends on the Calcite 
> work from SOLR-8593.



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

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

[jira] [Updated] (LUCENE-7596) Update Groovy to 2.4.8 in build system

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-7596:
--
Fix Version/s: 6.4
   master (7.0)
   6.x

> Update Groovy to 2.4.8 in build system
> --
>
> Key: LUCENE-7596
> URL: https://issues.apache.org/jira/browse/LUCENE-7596
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: 6.x, master (7.0), 6.4
>
>
> The current version of Groovy used by several Ant components is incompatible 
> with Java 9 build 148+. We need to update to 2.4.8 once it is released: 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-December/010474.html



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

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

[jira] [Created] (SOLR-9963) Add Calcite Avatica handler to Solr

[Kevin Risden (JIRA)]

Kevin Risden created SOLR-9963:
--

 Summary: Add Calcite Avatica handler to Solr
 Key: SOLR-9963
 URL: https://issues.apache.org/jira/browse/SOLR-9963
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Parallel SQL
Reporter: Kevin Risden


Calcite Avatica has an http endpoint which allows Avatica drivers to connect to 
the server. This can be wired in as a handler to Solr. This would allow Solr to 
be used by any Avatica JDBC/ODBC driver. This depends on the Calcite work from 
SOLR-8593.



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

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 256 - Still Unstable

[Apache Jenkins Server]

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

9 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)  
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:202)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94)  at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:102)
  at sun.reflect.GeneratedConstructorAccessor162.newInstance(Unknown Source)  
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)  at 
org.apache.solr.core.SolrCore.createInstance(SolrCore.java:753)  at 
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:815)  at 
org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1065)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:930)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:823)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:889)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:541)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [HdfsTransactionLog]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:202)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94)
at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:102)
at sun.reflect.GeneratedConstructorAccessor162.newInstance(Unknown 
Source)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:753)
at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:815)
at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1065)
at org.apache.solr.core.SolrCore.(SolrCore.java:930)
at org.apache.solr.core.SolrCore.(SolrCore.java:823)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:889)
at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:541)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


at __randomizedtesting.SeedInfo.seed([48F617548D8E895D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:269)
at sun.reflect.GeneratedMethodAccessor82.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Comment Edited] (SOLR-9952) S3BackupRepository

[Trey Cahill (JIRA)]

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

Trey Cahill edited comment on SOLR-9952 at 1/13/17 6:32 PM:


I've done work to run Solr on S3 via HDFS as [~risdenk] described (he also 
suggested it).  See the attachment "Running Solr on S3.pdf".  I tested the 
backup/restore using the HDFS backup repository (just back up and restore 
thought).


was (Author: cahilltr):
I've done work to run Solr on S3 via HDFS as [~risdenk] described (he also 
suggested it).  See the attachment "Running Solr on S3".  I tested the 
backup/restore using the HDFS backup repository (just back up and restore 
thought).

> S3BackupRepository
> --
>
> Key: SOLR-9952
> URL: https://issues.apache.org/jira/browse/SOLR-9952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: Running Solr on S3.pdf
>
>
> I'd like to have a backup repository implementation allows to snapshot to AWS 
> S3



--
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-9952) S3BackupRepository

[Trey Cahill (JIRA)]

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

Trey Cahill edited comment on SOLR-9952 at 1/13/17 6:32 PM:


I've done work to run Solr on S3 via HDFS as [~risdenk] described (he also 
suggested it).  See the attachment "Running Solr on S3.pdf".  I tested the 
backup/restore using the HDFS backup repository (just back up and restore 
though).


was (Author: cahilltr):
I've done work to run Solr on S3 via HDFS as [~risdenk] described (he also 
suggested it).  See the attachment "Running Solr on S3.pdf".  I tested the 
backup/restore using the HDFS backup repository (just back up and restore 
thought).

> S3BackupRepository
> --
>
> Key: SOLR-9952
> URL: https://issues.apache.org/jira/browse/SOLR-9952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: Running Solr on S3.pdf
>
>
> I'd like to have a backup repository implementation allows to snapshot to AWS 
> S3



--
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-9952) S3BackupRepository

[Trey Cahill (JIRA)]

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

Trey Cahill commented on SOLR-9952:
---

I've done work to run Solr on S3 via HDFS as [~risdenk] described (he also 
suggested it).  See the attachment "Running Solr on S3".  I tested the 
backup/restore using the HDFS backup repository (just back up and restore 
thought).

> S3BackupRepository
> --
>
> Key: SOLR-9952
> URL: https://issues.apache.org/jira/browse/SOLR-9952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: Running Solr on S3.pdf
>
>
> I'd like to have a backup repository implementation allows to snapshot to AWS 
> S3



--
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-9952) S3BackupRepository

[Trey Cahill (JIRA)]

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

Trey Cahill updated SOLR-9952:
--
Attachment: Running Solr on S3.pdf

> S3BackupRepository
> --
>
> Key: SOLR-9952
> URL: https://issues.apache.org/jira/browse/SOLR-9952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: Running Solr on S3.pdf
>
>
> I'd like to have a backup repository implementation allows to snapshot to AWS 
> S3



--
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-9836) Add more graceful recovery steps when failing to create SolrCore

[Mike Drob (JIRA)]

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

Mike Drob updated SOLR-9836:

Attachment: SOLR-9836.patch

Attaching the patch rebased onto latest master, since the current one wouldn't 
apply cleanly anymore.

> Add more graceful recovery steps when failing to create SolrCore
> 
>
> Key: SOLR-9836
> URL: https://issues.apache.org/jira/browse/SOLR-9836
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
>Assignee: Mark Miller
> Attachments: SOLR-9836.patch, SOLR-9836.patch, SOLR-9836.patch, 
> SOLR-9836.patch, SOLR-9836.patch, SOLR-9836.patch, SOLR-9836.patch
>
>
> I have seen several cases where there is a zero-length segments_n file. We 
> haven't identified the root cause of these issues (possibly a poorly timed 
> crash during replication?) but if there is another node available then Solr 
> should be able to recover from this situation. Currently, we log and give up 
> on loading that core, leaving the user to manually intervene.



--
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-9952) S3BackupRepository

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-9952:


Just a thought that backing up to S3 may already be possible with the 
HdfsBackupRepository. Hdfs supports reading/writing to S3 with S3N and S3A. It 
may just have to be documented that this is possible.

> S3BackupRepository
> --
>
> Key: SOLR-9952
> URL: https://issues.apache.org/jira/browse/SOLR-9952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>
> I'd like to have a backup repository implementation allows to snapshot to AWS 
> S3



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+147) - Build # 2660 - Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MDCAwareThreadPoolExecutor, SolrCore, MockDirectoryWrapper, 
MockDirectoryWrapper, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at org.apache.solr.core.SolrCore.(SolrCore.java:846)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:823)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:889)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:541)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  at java.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at org.apache.solr.core.SolrCore.(SolrCore.java:996)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:823)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:889)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:541)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  at java.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.MetricsDirectoryFactory.get(MetricsDirectoryFactory.java:201)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:475)  
at org.apache.solr.core.SolrCore.(SolrCore.java:900)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:823)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:889)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:541)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  at java.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.MetricsDirectoryFactory.get(MetricsDirectoryFactory.java:201)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:344)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:689)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:906)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:823)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:889)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:541)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  at java.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 

[jira] [Commented] (LUCENE-7630) EdgeNGramTokenFilter drops payloads

[Nathan Gass (JIRA)]

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

Nathan Gass commented on LUCENE-7630:
-

done

> EdgeNGramTokenFilter drops payloads
> ---
>
> Key: LUCENE-7630
> URL: https://issues.apache.org/jira/browse/LUCENE-7630
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: master (7.0)
>Reporter: Nathan Gass
>Assignee: Uwe Schindler
>Priority: Minor
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Using an EdgeNGramTokenFilter after a DelimitedPayloadTokenFilter discards 
> the payloads, where as most other filters copy the payload to the new tokens.
> I added a test for this issue and a possible fix at 
> https://github.com/xabbu42/lucene-solr/tree/edgepayloads
> Greetings
> Nathan Gass



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

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3776 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3776/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

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

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([A5EFFEF31ECC6767:2DBBC129B0300A9F]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+147) - Build # 18767 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18767/
Java: 32bit/jdk-9-ea+147 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.search.stats.TestDistribIDF

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.search.stats.TestDistribIDF: 1) Thread[id=4306, 
name=OverseerHdfsCoreFailoverThread-97276414634819589-127.0.0.1:42748_solr-n_01,
 state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.] at 
java.base/java.lang.Thread.sleep(Native Method) at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:139)
 at java.base/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.search.stats.TestDistribIDF: 
   1) Thread[id=4306, 
name=OverseerHdfsCoreFailoverThread-97276414634819589-127.0.0.1:42748_solr-n_01,
 state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.]
at java.base/java.lang.Thread.sleep(Native Method)
at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:139)
at java.base/java.lang.Thread.run(Thread.java:844)
at __randomizedtesting.SeedInfo.seed([F16DCBA044EEBD8B]:0)




Build Log:
[...truncated 11552 lines...]
   [junit4] Suite: org.apache.solr.search.stats.TestDistribIDF
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.search.stats.TestDistribIDF_F16DCBA044EEBD8B-001/init-core-data-001
   [junit4]   2> 427204 INFO  
(SUITE-TestDistribIDF-seed#[F16DCBA044EEBD8B]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason="", ssl=0.0/0.0, value=0.0/0.0, 
clientAuth=0.0/0.0)
   [junit4]   2> 427205 INFO  
(TEST-TestDistribIDF.testSimpleQuery-seed#[F16DCBA044EEBD8B]) [] 
o.a.s.SolrTestCaseJ4 ###Starting testSimpleQuery
   [junit4]   2> 427206 INFO  
(TEST-TestDistribIDF.testSimpleQuery-seed#[F16DCBA044EEBD8B]) [] 
o.a.s.c.MiniSolrCloudCluster Starting cluster of 3 servers in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.search.stats.TestDistribIDF_F16DCBA044EEBD8B-001/tempDir-001
   [junit4]   2> 427206 INFO  
(TEST-TestDistribIDF.testSimpleQuery-seed#[F16DCBA044EEBD8B]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 427206 INFO  (Thread-995) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 427206 INFO  (Thread-995) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 427306 INFO  
(TEST-TestDistribIDF.testSimpleQuery-seed#[F16DCBA044EEBD8B]) [] 
o.a.s.c.ZkTestServer start zk server on port:38067
   [junit4]   2> 427312 INFO  (jetty-launcher-713-thread-1) [] 
o.e.j.s.Server jetty-9.3.14.v20161028
   [junit4]   2> 427312 INFO  (jetty-launcher-713-thread-2) [] 
o.e.j.s.Server jetty-9.3.14.v20161028
   [junit4]   2> 427312 INFO  (jetty-launcher-713-thread-3) [] 
o.e.j.s.Server jetty-9.3.14.v20161028
   [junit4]   2> 427313 INFO  (jetty-launcher-713-thread-1) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@1e12bd8{/solr,null,AVAILABLE}
   [junit4]   2> 427313 INFO  (jetty-launcher-713-thread-2) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@c54f4{/solr,null,AVAILABLE}
   [junit4]   2> 427313 INFO  (jetty-launcher-713-thread-3) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@3d69b9{/solr,null,AVAILABLE}
   [junit4]   2> 427315 INFO  (jetty-launcher-713-thread-1) [] 
o.e.j.s.AbstractConnector Started 
ServerConnector@146661b{HTTP/1.1,[http/1.1]}{127.0.0.1:37090}
   [junit4]   2> 427315 INFO  (jetty-launcher-713-thread-3) [] 
o.e.j.s.AbstractConnector Started 
ServerConnector@efa95d{HTTP/1.1,[http/1.1]}{127.0.0.1:34974}
   [junit4]   2> 427315 INFO  (jetty-launcher-713-thread-1) [] 
o.e.j.s.Server Started @428948ms
   [junit4]   2> 427315 INFO  (jetty-launcher-713-thread-3) [] 
o.e.j.s.Server Started @428948ms
   [junit4]   2> 427315 INFO  (jetty-launcher-713-thread-2) [] 
o.e.j.s.AbstractConnector Started 
ServerConnector@e3eb2{HTTP/1.1,[http/1.1]}{127.0.0.1:33485}
   [junit4]   2> 427316 INFO  (jetty-launcher-713-thread-2) [] 
o.e.j.s.Server Started @428948ms
   [junit4]   2> 427316 INFO  (jetty-launcher-713-thread-1) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr, 
hostPort=37090}
   [junit4]   2> 427316 INFO  (jetty-launcher-713-thread-2) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr, 
hostPort=33485}
   [junit4]   2> 427316 INFO  (jetty-launcher-713-thread-3) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr, 
hostPort=34974}
   [junit4]   2> 427316 ERROR (jetty-launcher-713-thread-1) [] 

Re: A question about DV operation

[Erick Erickson]

Shawn:

tangentially related is SOLR-3191 (field exclusion from fl) which has
been in my queue for a very long time and I'd be _delighted_ if
someone took it away and gave it some attention. Rather than having to
specify all the fields you want just to omit the one big one, you
should be able to specify * but then exclude the big one.

Honest, I've had every intention of getting to this for...a very long time ;(

Erick

On Fri, Jan 13, 2017 at 12:52 AM, Ishan Chattopadhyaya
 wrote:
>> What happens if every query has an explicit list of fields to return in
>> results, and the list of fields does NOT include this field that
>> contains a large amount of data in docValues? Does this mean that the
>> docValues data for the field I've mentioned is never read, and has no
>> effect on OS disk cache efficiency?
>
> That is my understanding.
>
>
> On Fri, Jan 13, 2017 at 5:29 AM, Shawn Heisey  wrote:
>>
>> I have an idea for a Solr feature, but to know whether it's at all
>> viable, I need a question about Lucene operation answered.
>>
>> In recent versions of Solr, if a field is not stored, not indexed, but
>> does have docValues, the originally indexed data sent for that field
>> will be returned in search results.  In older versions (not sure which
>> ones) a field must be stored to be returned.
>>
>> Let's say that such a field contains a very large amount of data in
>> every document.  Normally, this would affect OS disk cache efficiency
>> for general queries, because the docValues data for the field would need
>> to be read in order to be included in search results.  Reading that
>> large amount of data can pollute the disk cache.  If the system is in a
>> low-memory situation, that can affect performance.
>>
>> What happens if every query has an explicit list of fields to return in
>> results, and the list of fields does NOT include this field that
>> contains a large amount of data in docValues?  Does this mean that the
>> docValues data for the field I've mentioned is never read, and has no
>> effect on OS disk cache efficiency?  Or would Lucene read the docValues
>> data even though it doesn't include it in results?
>>
>> 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] [Created] (SOLR-9962) need to extend classes in org.apache.solr.client.solrj.io.stream.metrics package

[radhakrishnan devarajan (JIRA)]

radhakrishnan devarajan created SOLR-9962:
-

 Summary: need to extend classes in 
org.apache.solr.client.solrj.io.stream.metrics package
 Key: SOLR-9962
 URL: https://issues.apache.org/jira/browse/SOLR-9962
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Server
Affects Versions: 6.3
Reporter: radhakrishnan devarajan
Priority: Trivial
 Fix For: 6.4


i want to extend the update(Tuple tuple) method in MaxMetric,. MinMetric, 
SumMetric, MeanMetric classes.

can you please make the below metioned variables and methods in the above 
mentioned classes as protected so that it will be easy to extend

variables
---
longMax

doubleMax

columnName



and 

methods

---

init



--
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-7630) EdgeNGramTokenFilter drops payloads

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7630:
---

bq. The NGramTokenFilter probably has the same issue. I can port the fix to 
that class when everything is correct.

Please do! You can update the current PR. Otheriwise PR looks fine.

> EdgeNGramTokenFilter drops payloads
> ---
>
> Key: LUCENE-7630
> URL: https://issues.apache.org/jira/browse/LUCENE-7630
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: master (7.0)
>Reporter: Nathan Gass
>Assignee: Uwe Schindler
>Priority: Minor
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Using an EdgeNGramTokenFilter after a DelimitedPayloadTokenFilter discards 
> the payloads, where as most other filters copy the payload to the new tokens.
> I added a test for this issue and a possible fix at 
> https://github.com/xabbu42/lucene-solr/tree/edgepayloads
> Greetings
> Nathan Gass



--
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-7630) EdgeNGramTokenFilter drops payloads

[Nathan Gass (JIRA)]

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

Nathan Gass commented on LUCENE-7630:
-

I commited the suggested improvements and made a pull request 
https://github.com/apache/lucene-solr/pull/138.

The NGramTokenFilter probably has the same issue. I can port the fix to that 
class when everything is correct.

> EdgeNGramTokenFilter drops payloads
> ---
>
> Key: LUCENE-7630
> URL: https://issues.apache.org/jira/browse/LUCENE-7630
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: master (7.0)
>Reporter: Nathan Gass
>Assignee: Uwe Schindler
>Priority: Minor
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Using an EdgeNGramTokenFilter after a DelimitedPayloadTokenFilter discards 
> the payloads, where as most other filters copy the payload to the new tokens.
> I added a test for this issue and a possible fix at 
> https://github.com/xabbu42/lucene-solr/tree/edgepayloads
> Greetings
> Nathan Gass



--
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-7630) EdgeNGramTokenFilter drops payloads

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7630:


GitHub user xabbu42 opened a pull request:

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

EdgeNGramTokenFilter drops payloads

Test and fix for https://issues.apache.org/jira/browse/LUCENE-7630.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/xabbu42/lucene-solr edgepayloads

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/138.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #138


commit 61e45283061ae486acc5882c5a770025c8291222
Author: Nathan Gass 
Date:   2017-01-09T13:59:31Z

add test that EdgeNGram filter keeps payloads

commit 6570e6ecc2b14a28da9873948083791ba47145d0
Author: Nathan Gass 
Date:   2017-01-09T14:00:21Z

copy all attributes including payload to new tokens

commit 01f2a87c67392a86b533d0c76ba7666845d1945f
Author: Nathan Gass 
Date:   2017-01-13T14:54:07Z

use captureState and restoreState instead of cloneAttributes




> EdgeNGramTokenFilter drops payloads
> ---
>
> Key: LUCENE-7630
> URL: https://issues.apache.org/jira/browse/LUCENE-7630
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: master (7.0)
>Reporter: Nathan Gass
>Assignee: Uwe Schindler
>Priority: Minor
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Using an EdgeNGramTokenFilter after a DelimitedPayloadTokenFilter discards 
> the payloads, where as most other filters copy the payload to the new tokens.
> I added a test for this issue and a possible fix at 
> https://github.com/xabbu42/lucene-solr/tree/edgepayloads
> Greetings
> Nathan Gass



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

[GitHub] lucene-solr pull request #138: EdgeNGramTokenFilter drops payloads

[xabbu42]

GitHub user xabbu42 opened a pull request:

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

EdgeNGramTokenFilter drops payloads

Test and fix for https://issues.apache.org/jira/browse/LUCENE-7630.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/xabbu42/lucene-solr edgepayloads

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/138.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #138


commit 61e45283061ae486acc5882c5a770025c8291222
Author: Nathan Gass 
Date:   2017-01-09T13:59:31Z

add test that EdgeNGram filter keeps payloads

commit 6570e6ecc2b14a28da9873948083791ba47145d0
Author: Nathan Gass 
Date:   2017-01-09T14:00:21Z

copy all attributes including payload to new tokens

commit 01f2a87c67392a86b533d0c76ba7666845d1945f
Author: Nathan Gass 
Date:   2017-01-13T14:54:07Z

use captureState and restoreState instead of cloneAttributes




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Need suggestion to use Graph in Solr

[Joel Bernstein]

This may provide the features that you need:
https://cwiki.apache.org/confluence/display/solr/Graph+Traversal

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

On Fri, Jan 13, 2017 at 8:58 AM, Alpesh Modi  wrote:

> Hi,
>
> I hope I am hitting to the right point.
> I am writing in reference of http://www.slideshare.net/
> MarkHarwood/proposal-for-nested-document-support-in-lucene
>
> I have a use case of searching nodes and documents related to the nodes
> according to given search query, in order of level of connection between
> nodes.
>
> Similar like for example in twitter, want to get search result, mixture of
> followers and tweets.
> Followers should be in order of level of connection to them of a person
> searching. Means level 1 followers are on top, followers of followers next.
> Tweets should be also in similar order, like my tweets first, level 1
> person's tweets next.
>
> What is the best way of storing graph into solr for the best results?
> As, a node will have lot of children nodes, and lot of parent nodes as
> well. If I save relation documents, it will be flood of documents.
>
> I really appreciate your help into this.
>
> Thanks already,
> Alpesh Modi
>

[jira] [Commented] (SOLR-9961) RestoreCore needs the option to download files in parallel.

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-9961:
--

Patch is not ready for commit. We need to think about how to provide some 
config options like max time to wait and number of threads. Right now, I get 
the number of threads from a sys prop, but I think it should probably come 
through a marker interface that specific backup repos can implement ... will 
post up a better version later today.

> RestoreCore needs the option to download files in parallel.
> ---
>
> Key: SOLR-9961
> URL: https://issues.apache.org/jira/browse/SOLR-9961
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 6.2.1
>Reporter: Timothy Potter
> Attachments: SOLR-9961.patch
>
>
> My backup to cloud storage (Google cloud storage in this case, but I think 
> this is a general problem) takes 8 minutes ... the restore of the same core 
> takes hours. The restore loop in RestoreCore is serial and doesn't allow me 
> to parallelize the expensive part of this operation (the IO from the remote 
> cloud storage service). We need the option to parallelize the download (like 
> distcp). 
> Also, I tried downloading the same directory using gsutil and it was very 
> fast, like 2 minutes. So I know it's not the pipe that's limiting perf here.
> Here's a very rough patch that does the parallelization. We may also want to 
> consider a two-step approach: 1) download in parallel to a temp dir, 2) 
> perform all the of the checksum validation against the local temp dir. That 
> will save round trips to the remote cloud storage.



--
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-9961) RestoreCore needs the option to download files in parallel.

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-9961:
-
Attachment: SOLR-9961.patch

> RestoreCore needs the option to download files in parallel.
> ---
>
> Key: SOLR-9961
> URL: https://issues.apache.org/jira/browse/SOLR-9961
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 6.2.1
>Reporter: Timothy Potter
> Attachments: SOLR-9961.patch
>
>
> My backup to cloud storage (Google cloud storage in this case, but I think 
> this is a general problem) takes 8 minutes ... the restore of the same core 
> takes hours. The restore loop in RestoreCore is serial and doesn't allow me 
> to parallelize the expensive part of this operation (the IO from the remote 
> cloud storage service). We need the option to parallelize the download (like 
> distcp). 
> Also, I tried downloading the same directory using gsutil and it was very 
> fast, like 2 minutes. So I know it's not the pipe that's limiting perf here.
> Here's a very rough patch that does the parallelization. We may also want to 
> consider a two-step approach: 1) download in parallel to a temp dir, 2) 
> perform all the of the checksum validation against the local temp dir. That 
> will save round trips to the remote cloud storage.



--
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-9961) RestoreCore needs the option to download files in parallel.

[Timothy Potter (JIRA)]

Timothy Potter created SOLR-9961:


 Summary: RestoreCore needs the option to download files in 
parallel.
 Key: SOLR-9961
 URL: https://issues.apache.org/jira/browse/SOLR-9961
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Backup/Restore
Affects Versions: 6.2.1
Reporter: Timothy Potter


My backup to cloud storage (Google cloud storage in this case, but I think this 
is a general problem) takes 8 minutes ... the restore of the same core takes 
hours. The restore loop in RestoreCore is serial and doesn't allow me to 
parallelize the expensive part of this operation (the IO from the remote cloud 
storage service). We need the option to parallelize the download (like distcp). 

Also, I tried downloading the same directory using gsutil and it was very fast, 
like 2 minutes. So I know it's not the pipe that's limiting perf here.

Here's a very rough patch that does the parallelization. We may also want to 
consider a two-step approach: 1) download in parallel to a temp dir, 2) perform 
all the of the checksum validation against the local temp dir. That will save 
round trips to the remote cloud storage.



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

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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_112) - Build # 688 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/688/
Java: 32bit/jdk1.8.0_112 -client -XX:+UseParallelGC

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

Error Message:
PeerSynced node did not become leader expected:https://127.0.0.1:56073/jhd/collection1]> but was:https://127.0.0.1:56057/jhd/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:https://127.0.0.1:56073/jhd/collection1]> but 
was:https://127.0.0.1:56057/jhd/collection1]>
at 
__randomizedtesting.SeedInfo.seed([1BCBFB95703270F0:939FC44FDECE1D08]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Updated] (SOLR-9835) Create another replication mode for SolrCloud

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-9835:
---
Attachment: SOLR-9835.patch

This is my final patch, cleanup to make the patch more robust. ( all related 
tests are passed, included jepsen tests ).
[~shalinmangar] Can you review this patch?

> Create another replication mode for SolrCloud
> -
>
> Key: SOLR-9835
> URL: https://issues.apache.org/jira/browse/SOLR-9835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch
>
>
> The current replication mechanism of SolrCloud is called state machine, which 
> replicas start in same initial state and for each input, the input is 
> distributed across replicas so all replicas will end up with same next state. 
> But this type of replication have some drawbacks
> - The commit (which costly) have to run on all replicas
> - Slow recovery, because if replica miss more than N updates on its down 
> time, the replica have to download entire index from its leader.
> So we create create another replication mode for SolrCloud called state 
> transfer, which acts like master/slave replication. In basically
> - Leader distribute the update to other replicas, but the leader only apply 
> the update to IW, other replicas just store the update to UpdateLog (act like 
> replication).
> - Replicas frequently polling the latest segments from leader.
> Pros:
> - Lightweight for indexing, because only leader are running the commit, 
> updates.
> - Very fast recovery, replicas just have to download the missing segments.
> To use this new replication mode, a new collection must be created with an 
> additional parameter {{liveReplicas=1}}
> {code}
> http://localhost:8983/solr/admin/collections?action=CREATE=newCollection=2=1=1
> {code}



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

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

Need suggestion to use Graph in Solr

[Alpesh Modi]

Hi,

I hope I am hitting to the right point.
I am writing in reference of
http://www.slideshare.net/MarkHarwood/proposal-for-nested-document-support-in-lucene

I have a use case of searching nodes and documents related to the nodes
according to given search query, in order of level of connection between
nodes.

Similar like for example in twitter, want to get search result, mixture of
followers and tweets.
Followers should be in order of level of connection to them of a person
searching. Means level 1 followers are on top, followers of followers next.
Tweets should be also in similar order, like my tweets first, level 1
person's tweets next.

What is the best way of storing graph into solr for the best results?
As, a node will have lot of children nodes, and lot of parent nodes as
well. If I save relation documents, it will be flood of documents.

I really appreciate your help into this.

Thanks already,
Alpesh Modi

[JENKINS] Lucene-Solr-Tests-6.x - Build # 677 - Unstable

[Apache Jenkins Server]

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

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

Error Message:
PeerSynced node did not become leader expected:https://127.0.0.1:44181/collection1]> but was:https://127.0.0.1:53025/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:https://127.0.0.1:44181/collection1]> but 
was:https://127.0.0.1:53025/collection1]>
at 
__randomizedtesting.SeedInfo.seed([A9C5956E41A10978:2191AAB4EF5D6480]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Assigned] (LUCENE-7630) EdgeNGramTokenFilter drops payloads

[Uwe Schindler (JIRA)]

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

Uwe Schindler reassigned LUCENE-7630:
-

Assignee: Uwe Schindler

> EdgeNGramTokenFilter drops payloads
> ---
>
> Key: LUCENE-7630
> URL: https://issues.apache.org/jira/browse/LUCENE-7630
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: master (7.0)
>Reporter: Nathan Gass
>Assignee: Uwe Schindler
>Priority: Minor
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Using an EdgeNGramTokenFilter after a DelimitedPayloadTokenFilter discards 
> the payloads, where as most other filters copy the payload to the new tokens.
> I added a test for this issue and a possible fix at 
> https://github.com/xabbu42/lucene-solr/tree/edgepayloads
> Greetings
> Nathan Gass



--
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-7630) EdgeNGramTokenFilter drops payloads

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7630:
---

Hi, could you create a Pull Request and add the link here?

About your branch: I would not use cloneAttributes() because thats slow for 
this simple case. cloneAttributes() only helps if you want to modify the 
attributes in the AttributeSource that was created, but is not useful for 
simple save/restore use cases.

For your case, you should simple use captureState(), save the state object and 
then call restorestate() instead of clearAttributes(). After restoring you can 
adapt term text and positions/offsets. In addition when you clone or capture 
state, the call to clearAttributes() is useless and also slows down. When 
restoring states, everything is restored, so the additional clearing before is 
not needed.

> EdgeNGramTokenFilter drops payloads
> ---
>
> Key: LUCENE-7630
> URL: https://issues.apache.org/jira/browse/LUCENE-7630
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: master (7.0)
>Reporter: Nathan Gass
>Priority: Minor
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Using an EdgeNGramTokenFilter after a DelimitedPayloadTokenFilter discards 
> the payloads, where as most other filters copy the payload to the new tokens.
> I added a test for this issue and a possible fix at 
> https://github.com/xabbu42/lucene-solr/tree/edgepayloads
> Greetings
> Nathan Gass



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

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

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_112) - Build # 6355 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6355/
Java: 32bit/jdk1.8.0_112 -client -XX:+UseG1GC

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

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([5DB508429D7FCC5:7F8673F1BF8FD54D]:0)
at 
org.apache.solr.handler.TestReplicationHandler.doTestDetails(TestReplicationHandler.java:312)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
PeerSynced node did not become leader expected:http://127.0.0.1:60234/_bf/collection1]> but was:http://127.0.0.1:60218/_bf/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:http://127.0.0.1:60234/_bf/collection1]> but 
was:http://127.0.0.1:60218/_bf/collection1]>
at 

[jira] [Created] (LUCENE-7630) EdgeNGramTokenFilter drops payloads

[Nathan Gass (JIRA)]

Nathan Gass created LUCENE-7630:
---

 Summary: EdgeNGramTokenFilter drops payloads
 Key: LUCENE-7630
 URL: https://issues.apache.org/jira/browse/LUCENE-7630
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: master (7.0)
Reporter: Nathan Gass
Priority: Minor


Using an EdgeNGramTokenFilter after a DelimitedPayloadTokenFilter discards the 
payloads, where as most other filters copy the payload to the new tokens.

I added a test for this issue and a possible fix at 
https://github.com/xabbu42/lucene-solr/tree/edgepayloads

Greetings
Nathan Gass



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

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

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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1211/

14 tests failed.
FAILED:  
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testBatchBoundaries

Error Message:
Timeout waiting for CDCR replication to complete @source_collection:shard1

Stack Trace:
java.lang.RuntimeException: Timeout waiting for CDCR replication to complete 
@source_collection:shard1
at 
__randomizedtesting.SeedInfo.seed([7BEA8BD3760B15ED:59C552860FAFD40A]:0)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForReplicationToComplete(BaseCdcrDistributedZkTest.java:795)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testBatchBoundaries(CdcrReplicationDistributedZkTest.java:557)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-9960) MetricsHandler should support multiple prefixes.

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-9960:
-

Patch that implements the change. Parameters "prefix" and "registry" can be 
used as multi-valued or comma-separated list (like the "group") to indicate the 
multiple prefixes to match (logical OR) or multiple registry prefixes to match. 
For example:
{code}
registry=solr.core,solr.node
{code}
selects all registries for all cores, and a node registry, whereas these 
parameters:
{code}
registry=solr.core.collection1=ADMIN,UPDATE
{code}
selects metrics from all shards and replicas belonging to "collection1", but 
only for metrics with names starting with these two prefixes.

> MetricsHandler should support multiple prefixes.
> 
>
> Key: SOLR-9960
> URL: https://issues.apache.org/jira/browse/SOLR-9960
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: master (7.0), 6.4
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9960.patch
>
>
> Some consumers of the {{/admin/metrics}} API need to retrieve only a number 
> of specific metrics they are interested in, which don't share the same 
> prefix. Additionally, selecting by "group" or "type" is insufficient when 
> users need to retrieve metrics for a specific collection (all collections 
> handled by a node belong to the same group "core").
> Concrete examples of this kind of use are in SOLR-9857 and SOLR-9858.
> The modification needed to support this in {{MetricsHandler}} is simple:
> * support multiple "prefix" parameters
> * support also "registryPrefix" parameter as an alternative to "group".



--
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-9960) MetricsHandler should support multiple prefixes.

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-9960:

Attachment: SOLR-9960.patch

> MetricsHandler should support multiple prefixes.
> 
>
> Key: SOLR-9960
> URL: https://issues.apache.org/jira/browse/SOLR-9960
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: master (7.0), 6.4
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9960.patch
>
>
> Some consumers of the {{/admin/metrics}} API need to retrieve only a number 
> of specific metrics they are interested in, which don't share the same 
> prefix. Additionally, selecting by "group" or "type" is insufficient when 
> users need to retrieve metrics for a specific collection (all collections 
> handled by a node belong to the same group "core").
> Concrete examples of this kind of use are in SOLR-9857 and SOLR-9858.
> The modification needed to support this in {{MetricsHandler}} is simple:
> * support multiple "prefix" parameters
> * support also "registryPrefix" parameter as an alternative to "group".



--
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-7627) Improve TermsEnum automaton filtering APIs

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7627:


Thanks [~romseygeek], I think the patch is good, except maybe we can name the 
new methods {{intersect}} so it's clearer that we are intersecting with the 
incoming automaton?

> Improve TermsEnum automaton filtering APIs
> --
>
> Key: LUCENE-7627
> URL: https://issues.apache.org/jira/browse/LUCENE-7627
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
> Attachments: LUCENE-7627.patch
>
>
> To filter a TermsEnum by a CompiledAutomaton, we currently have a number of 
> different possibilities:
> * Terms.intersect(CompiledAutomaton, BytesRef) - efficient, but only works on 
> NORMAL type automata
> * CompiledAutomaton.getTerms(Terms) - efficient, works on all automaton 
> types, but requires a Terms instead of a TermsEnum, so no use for eg 
> SortedDocValues.termsEnum()
> * AutomatonTermsEnum - takes a TermsEnum, so it's more general than the Terms 
> methods above, but agian only works on NORMAL automata
> It's easy to do the wrong thing here, and at the moment we only guard against 
> incorrect usage via runtime checks (see eg LUCENE-7576, 
> https://github.com/flaxsearch/marple/issues/24).  We should try and clean 
> this up.



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

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

[jira] [Updated] (LUCENE-7626) IndexWriter shouldn't accept broken offsets

[Michael McCandless (JIRA)]

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

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

New patch, also fixing {{CheckIndex}} to detect broken offsets, and adding a 
tool to fix broken offsets in an index for the very rare possibility that there 
is such an index out there.

> IndexWriter shouldn't accept broken offsets
> ---
>
> Key: LUCENE-7626
> URL: https://issues.apache.org/jira/browse/LUCENE-7626
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: LUCENE-7626.patch, LUCENE-7626.patch
>
>
> I think we should do this in 7.0 (not 6.x).
> Long ago we stopped accepting broken offsets (where the start offset
> for a token is before the start offset of the last token) in postings
> (LUCENE-4127), but we are still lenient with term vectors.
> I think we should also check for term vectors: this would let users
> know that their analysis chain is producing offsets that cannot be
> used properly at search time.



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+147) - Build # 2658 - Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
PeerSynced node did not become leader expected:https://127.0.0.1:33580/collection1]> but was:https://127.0.0.1:42348/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:https://127.0.0.1:33580/collection1]> but 
was:https://127.0.0.1:42348/collection1]>
at 
__randomizedtesting.SeedInfo.seed([573BEA6486708A44:DF6FD5BE288CE7BC]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:538)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Updated] (SOLR-8542) Integrate Learning to Rank into Solr

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-8542:
--
Description: 
This is a ticket to integrate learning to rank machine learning models into 
Solr. Solr Learning to Rank (LTR) provides a way for you to extract features 
directly inside Solr for use in training a machine learned model. You can then 
deploy that model to Solr and use it to rerank your top X search results. This 
concept was previously [presented by the authors at Lucene/Solr Revolution 
2015|http://www.slideshare.net/lucidworks/learning-to-rank-in-solr-presented-by-michael-nilsson-diego-ceccarelli-bloomberg-lp].



Solr Reference Guide documentation:
* https://cwiki.apache.org/confluence/display/solr/Learning+To+Rank

Source code and README files:
* 
[solr/contrib/ltr|https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr]
* 
[solr/contrib/ltr/example|https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr/example]

  was:
This is a ticket to integrate learning to rank machine learning models into 
Solr. Solr Learning to Rank (LTR) provides a way for you to extract features 
directly inside Solr for use in training a machine learned model. You can then 
deploy that model to Solr and use it to rerank your top X search results. This 
concept was previously [presented by the authors at Lucene/Solr Revolution 
2015|http://www.slideshare.net/lucidworks/learning-to-rank-in-solr-presented-by-michael-nilsson-diego-ceccarelli-bloomberg-lp].



Solr Reference Guide documentation:
* https://cwiki.apache.org/confluence/display/solr/Result+Reranking

Source code and README files:
* 
[solr/contrib/ltr|https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr]
* 
[solr/contrib/ltr/example|https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr/example]


> Integrate Learning to Rank into Solr
> 
>
> Key: SOLR-8542
> URL: https://issues.apache.org/jira/browse/SOLR-8542
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joshua Pantony
>Assignee: Christine Poerschke
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-8542-branch_5x.patch, SOLR-8542.patch, 
> SOLR-8542-trunk.patch
>
>
> This is a ticket to integrate learning to rank machine learning models into 
> Solr. Solr Learning to Rank (LTR) provides a way for you to extract features 
> directly inside Solr for use in training a machine learned model. You can 
> then deploy that model to Solr and use it to rerank your top X search 
> results. This concept was previously [presented by the authors at Lucene/Solr 
> Revolution 
> 2015|http://www.slideshare.net/lucidworks/learning-to-rank-in-solr-presented-by-michael-nilsson-diego-ceccarelli-bloomberg-lp].
> 
> Solr Reference Guide documentation:
> * https://cwiki.apache.org/confluence/display/solr/Learning+To+Rank
> Source code and README files:
> * 
> [solr/contrib/ltr|https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr]
> * 
> [solr/contrib/ltr/example|https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr/example]



--
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-8542) Integrate Learning to Rank into Solr

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8542:
---

bq. How about "Learning To Rank" as a sub-page of the "Query Re-Ranking" ... +1 
... I like that idea.

[Learning To 
Rank|https://cwiki.apache.org/confluence/display/solr/Learning+To+Rank] is now 
the documentation page. I renamed and relocated the page and updated 'code' and 
'ref guide' references to it. 
http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/987e2650 and 
http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/9b03e384 are the 
'code' commits.

bq. Regarding the alternative of "Machine Learned Ranking", how about reserving 
that for future use ...

Tentative page name and draft content now at 
https://cwiki.apache.org/confluence/display/solr/Machine+Learning+and+Solr 
because I think there's actually already enough functionality (Learning To Rank 
from SOLR-8542 here and [~joel.bernstein]'s Logistic Regression Text 
Classification) to bring the "future use" into the present - what do you think?

> Integrate Learning to Rank into Solr
> 
>
> Key: SOLR-8542
> URL: https://issues.apache.org/jira/browse/SOLR-8542
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joshua Pantony
>Assignee: Christine Poerschke
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-8542-branch_5x.patch, SOLR-8542.patch, 
> SOLR-8542-trunk.patch
>
>
> This is a ticket to integrate learning to rank machine learning models into 
> Solr. Solr Learning to Rank (LTR) provides a way for you to extract features 
> directly inside Solr for use in training a machine learned model. You can 
> then deploy that model to Solr and use it to rerank your top X search 
> results. This concept was previously [presented by the authors at Lucene/Solr 
> Revolution 
> 2015|http://www.slideshare.net/lucidworks/learning-to-rank-in-solr-presented-by-michael-nilsson-diego-ceccarelli-bloomberg-lp].
> 
> Solr Reference Guide documentation:
> * https://cwiki.apache.org/confluence/display/solr/Result+Reranking
> Source code and README files:
> * 
> [solr/contrib/ltr|https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr]
> * 
> [solr/contrib/ltr/example|https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr/example]



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/616/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
PeerSynced node did not become leader expected:http://127.0.0.1:49871/qgydo/ep/collection1]> but was:http://127.0.0.1:49046/qgydo/ep/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:http://127.0.0.1:49871/qgydo/ep/collection1]> 
but was:http://127.0.0.1:49046/qgydo/ep/collection1]>
at 
__randomizedtesting.SeedInfo.seed([AE1D9E97FEF0A86F:2649A14D500CC597]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Created] (SOLR-9960) MetricsHandler should support multiple prefixes.

[Andrzej Bialecki (JIRA)]

Andrzej Bialecki  created SOLR-9960:
---

 Summary: MetricsHandler should support multiple prefixes.
 Key: SOLR-9960
 URL: https://issues.apache.org/jira/browse/SOLR-9960
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: metrics
Affects Versions: master (7.0), 6.4
Reporter: Andrzej Bialecki 
Assignee: Andrzej Bialecki 
Priority: Minor
 Fix For: master (7.0), 6.4


Some consumers of the {{/admin/metrics}} API need to retrieve only a number of 
specific metrics they are interested in, which don't share the same prefix. 
Additionally, selecting by "group" or "type" is insufficient when users need to 
retrieve metrics for a specific collection (all collections handled by a node 
belong to the same group "core").

Concrete examples of this kind of use are in SOLR-9857 and SOLR-9858.

The modification needed to support this in {{MetricsHandler}} is simple:
* support multiple "prefix" parameters
* support also "registryPrefix" parameter as an alternative to "group".



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+147) - Build # 18765 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18765/
Java: 32bit/jdk-9-ea+147 -server -XX:+UseSerialGC

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

Error Message:
PeerSynced node did not become leader expected:http://127.0.0.1:41807/vky/es/collection1]> but was:http://127.0.0.1:46087/vky/es/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:http://127.0.0.1:41807/vky/es/collection1]> but 
was:http://127.0.0.1:46087/vky/es/collection1]>
at 
__randomizedtesting.SeedInfo.seed([FCB510276BE12BBA:74E12FFDC51D4642]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:538)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Created] (SOLR-9959) SolrInfoMBean-s category and hierarchy cleanup

[Andrzej Bialecki (JIRA)]

Andrzej Bialecki  created SOLR-9959:
---

 Summary: SolrInfoMBean-s category and hierarchy cleanup
 Key: SOLR-9959
 URL: https://issues.apache.org/jira/browse/SOLR-9959
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (7.0)
Reporter: Andrzej Bialecki 
Assignee: Andrzej Bialecki 
Priority: Blocker
 Fix For: master (7.0)


SOLR-9947 changed categories of some of {{SolrInfoMBean-s}}, and it also added 
an alternative view in JMX, similar to the one produced by {{SolrJmxReporter}}.

Some changes were left out from that issue because they would break the 
back-compatibility in 6.x, but they should be done before 7.0:
* remove the old JMX view of {{SolrInfoMBean}}-s and improve the new one so 
that it's more readable and useful.
* in many cases {{SolrInfoMBean.getName()}} just returns a FQCN, but it could 
be more informative - eg. for highlighter or query plugins this could be the 
symbolic name of a plugin that users know and use in configuration.
* top-level categories need more thought. On one hand it's best to minimize 
their number, on the other hand they need to meaningfully represent the 
functionality of components that use them. SOLR-9947 made some cosmetic 
changes, but more discussion is necessary (eg. QUERY vs. SEARCHHANDLER)
* we should consider removing some of the methods in {{SolrInfoMBean}} that 
usually don't return any useful information, eg. {{getDocs}}, {{getSource()}} 
and {{getVersion()}}.



--
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: A question about DV operation

[Ishan Chattopadhyaya]

> What happens if every query has an explicit list of fields to return in
> results, and the list of fields does NOT include this field that
> contains a large amount of data in docValues? Does this mean that the
> docValues data for the field I've mentioned is never read, and has no
> effect on OS disk cache efficiency?

That is my understanding.


On Fri, Jan 13, 2017 at 5:29 AM, Shawn Heisey  wrote:

> I have an idea for a Solr feature, but to know whether it's at all
> viable, I need a question about Lucene operation answered.
>
> In recent versions of Solr, if a field is not stored, not indexed, but
> does have docValues, the originally indexed data sent for that field
> will be returned in search results.  In older versions (not sure which
> ones) a field must be stored to be returned.
>
> Let's say that such a field contains a very large amount of data in
> every document.  Normally, this would affect OS disk cache efficiency
> for general queries, because the docValues data for the field would need
> to be read in order to be included in search results.  Reading that
> large amount of data can pollute the disk cache.  If the system is in a
> low-memory situation, that can affect performance.
>
> What happens if every query has an explicit list of fields to return in
> results, and the list of fields does NOT include this field that
> contains a large amount of data in docValues?  Does this mean that the
> docValues data for the field I've mentioned is never read, and has no
> effect on OS disk cache efficiency?  Or would Lucene read the docValues
> data even though it doesn't include it in results?
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1076 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1076/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
[/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4BF88155B9B629BC-001/solr-instance-017/./collection1/data/index.20170113165512555,
 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4BF88155B9B629BC-001/solr-instance-017/./collection1/data,
 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4BF88155B9B629BC-001/solr-instance-017/./collection1/data/snapshot_metadata,
 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4BF88155B9B629BC-001/solr-instance-017/./collection1/data/index.20170113165512430]
 expected:<3> but was:<4>

Stack Trace:
java.lang.AssertionError: 
[/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4BF88155B9B629BC-001/solr-instance-017/./collection1/data/index.20170113165512555,
 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4BF88155B9B629BC-001/solr-instance-017/./collection1/data,
 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4BF88155B9B629BC-001/solr-instance-017/./collection1/data/snapshot_metadata,
 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4BF88155B9B629BC-001/solr-instance-017/./collection1/data/index.20170113165512430]
 expected:<3> but was:<4>
at 
__randomizedtesting.SeedInfo.seed([4BF88155B9B629BC:BC8B6F0D7F5E865A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:918)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1350)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

Re: Solr web page changes

[Jan Høydahl]

I updated http://lucene.staging.apache.org/solr/community.html 
 with a table.

However, stepping back, it feels a bit mal-placed on a “Community” page.
I wonder if we better move the version table or perhaps the whole explanation
altogheter to a new solr/downloads.html page.

Then we could move all text from 
http://lucene.staging.apache.org/solr/mirrors-solr-latest-redir.html 

to that page. To be honest, it’s a pain that our “Download” page is displayed 
for
a few seconds only before redirecting. If we create a stable download.html page
that page could have a table with links directly to the versions, the version 
specific ref-guides as
well as info about CVE’s or documentation addendums etc.

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

> 13. jan. 2017 kl. 01.56 skrev Walter Underwood :
> 
> I like the list version. Might want to use historical version numbers (4, 5, 
> 6) to
> avoid predicting the future. We’re jumping from 4.10.4 to 6.4 right now. Well,
> we have some 3.x in production, but I’m trying to stomp that flat.
> 
> wunder
> Walter Underwood
> wun...@wunderwood.org 
> http://observer.wunderwood.org/  (my blog)
> 
> 
>> On Jan 12, 2017, at 4:12 PM, Shawn Heisey > > wrote:
>> 
>> On 1/12/2017 3:36 PM, Jan Høydahl wrote:
>>> I don’t like putting version numbers into the website, since they WILL
>>> be out of date at some point. But it is hard to explain three
>>> generations without giving examples, suggestions for how to avoid it?
>> 
>> In the paragraph, don't mention the actual version numbers.  Instead,
>> refer to general version categories, and include something that's
>> table-like where actual version numbers are given.  Here's an example of
>> what that table structure might contain, feel free to bikeshed as necessary:
>> 
>> 5.5.x : Version in the previous major release for bugfixes
>> 6.x   : Current major version, comes from the stable branch_6x
>> 7.0   : Next major version, will come from master branch
>> 
>> When a new stable branch is built and we go looking for info that needs
>> updating, this page will contain it all in one place.  If the code that
>> builds the website allows tags/comments that become invisible, perhaps
>> we can come up with a way to tag this with a string that we can search
>> for later when we we build a new stable branch.
>> 
>> Thanks,
>> Shawn
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> 
>> 
>