Is "solr.AnalyzerName" expansion supposed to work for Analyzers?

[Alexandre Rafalovitch]

I can't see a reason why it should be different, but:

This works




   

This does not:




This does work again:




Both LowerCaseTokenizerFactory and SimpleAnalyzer are in the same package.

Is this a bug or some sort of legacy decision?

Regards,
   Alex.

Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail

Error Message:
expected:<200> but was:<404>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([4C667B4C94BDAE17:24D94E664427BCFB]: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.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:137)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:292)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
IOException occured when talking to server at: https://127.0.0.1:37268/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:37268/solr
at 
__randomizedtesting.SeedInfo.seed([C7CBC8E9742D5C5B:7BA5BEFBD07EDF21]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:158)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

Re: [ANNOUNCE] Apache Lucene 5.5.3 released

[SIDDHAST® Roshan]

Hi anshuman can you help us in building in the customised parser for solr
On Sep 10, 2016 1:13 AM, "Anshum Gupta"  wrote:

> 09 September 2016, Apache Lucene™ 5.5.3 available
>
> The Lucene PMC is pleased to announce the release of Apache Lucene 5.5.3
>
> Apache Lucene is a high-performance, full-featured text search engine
> library written entirely in Java. It is a technology suitable for nearly
> any application that requires full-text search, especially cross-platform.
>
> The release is available for immediate download at:
>
>   http://www.apache.org/dyn/closer.lua/lucene/java/5.5.3
>
> Please read CHANGES.txt for a full list of new features and changes:
>
>   https://lucene.apache.org/core/5_5_3/changes/Changes.html
>
> Please report any feedback to the mailing lists
> (http://lucene.apache.org/core/discussion.html)
>
> Note: The Apache Software Foundation uses an extensive mirroring network
> for distributing releases.  It is possible that the mirror you are using
> may not have replicated the release yet.  If that is the case, please
> try another mirror.  This also goes for Maven access.
>
> -Anshum Gupta
>

[JENKINS] Lucene-Solr-NightlyTests-5.5 - Build # 5 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.5/5/

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

Error Message:
Exactly one shard should have changed, instead: [shard2, shard1] 
nodes=([core_node2(shard1), core_node4(shard1), core_node3(shard2)]) 
expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: Exactly one shard should have changed, instead: 
[shard2, shard1] nodes=([core_node2(shard1), core_node4(shard1), 
core_node3(shard2)]) expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([D6A8934F3CFE4FB5:5EFCAC959202224D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.test(DistribDocExpirationUpdateProcessorTest.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Updated] (LUCENE-7442) MinHashFilter.FixedSizeTreeSet.add() calls TreeSet.last() without first testing for emptiness, under which condition NoSuchElementException is thrown

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-7442:
---
Summary: MinHashFilter.FixedSizeTreeSet.add() calls TreeSet.last() without 
first testing for emptiness, under which condition NoSuchElementException is 
thrown  (was: MinHashFilter.FixedSizeTreeSet.add() calls SortedSet.last() 
without first testing for emptiness, under which condition 
NoSuchElementException is thrown)

> MinHashFilter.FixedSizeTreeSet.add() calls TreeSet.last() without first 
> testing for emptiness, under which condition NoSuchElementException is thrown
> -
>
> Key: LUCENE-7442
> URL: https://issues.apache.org/jira/browse/LUCENE-7442
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Steve Rowe
>
> My Jenkins found this reproducing branch_6x seed:
> {noformat}
>[junit4] Suite: org.apache.lucene.analysis.core.TestRandomChains
>[junit4]   2> Exception from random analyzer: 
>[junit4]   2> charfilters=
>[junit4]   2> tokenizer=
>[junit4]   2>   org.apache.lucene.analysis.standard.StandardTokenizer()
>[junit4]   2> filters=
>[junit4]   2>   
> org.apache.lucene.analysis.minhash.MinHashFilter(ValidatingTokenFilter@6ae99167
>  
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,
>  5, 5, -3, true)
>[junit4]   2>   
> org.apache.lucene.analysis.bg.BulgarianStemFilter(ValidatingTokenFilter@40844352
>  
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,keyword=false)
>[junit4]   2> offsetsAreCorrect=true
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRandomChains 
> -Dtests.method=testRandomChainsWithLargeStrings -Dtests.seed=4733E677EBDC28FC 
> -Dtests.slow=true -Dtests.locale=ar-OM 
> -Dtests.timezone=Atlantic/South_Georgia -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   3.18s J4 | 
> TestRandomChains.testRandomChainsWithLargeStrings <<<
>[junit4]> Throwable #1: java.util.NoSuchElementException
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([4733E677EBDC28FC:2D685966B292080F]:0)
>[junit4]>  at java.util.TreeMap.key(TreeMap.java:1323)
>[junit4]>  at java.util.TreeMap.lastKey(TreeMap.java:297)
>[junit4]>  at java.util.TreeSet.last(TreeSet.java:401)
>[junit4]>  at 
> org.apache.lucene.analysis.minhash.MinHashFilter$FixedSizeTreeSet.add(MinHashFilter.java:325)
>[junit4]>  at 
> org.apache.lucene.analysis.minhash.MinHashFilter.incrementToken(MinHashFilter.java:159)
>[junit4]>  at 
> org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:67)
>[junit4]>  at 
> org.apache.lucene.analysis.bg.BulgarianStemFilter.incrementToken(BulgarianStemFilter.java:48)
>[junit4]>  at 
> org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:67)
>[junit4]>  at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException(BaseTokenStreamTestCase.java:405)
>[junit4]>  at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:510)
>[junit4]>  at 
> org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings(TestRandomChains.java:959)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): 
> {dummy=Lucene50(blocksize=128)}, docValues:{}, maxPointsInLeafNode=252, 
> maxMBSortInHeap=5.297834377897023, sim=ClassicSimilarity, locale=ar-OM, 
> timezone=Atlantic/South_Georgia
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_77 (64-bit)/cpus=16,threads=1,free=395080152,total=465567744
>[junit4]   2> NOTE: All tests run in this JVM: 
> [TestDecimalDigitFilterFactory, TestMultiWordSynonyms, 
> TestReversePathHierarchyTokenizer, TestDoubleEscape, 
> TestHunspellStemFilterFactory, TestArabicNormalizationFilter, 
> TestUAX29URLEmailAnalyzer, TestSwedishLightStemFilterFactory, 
> TestBulgarianStemmer, TestASCIIFoldingFilter, 
> TestDelimitedPayloadTokenFilterFactory, TestIndonesianStemmer, TestCircumfix, 
> EdgeNGramTokenFilterTest, TestPatternTokenizer, 
> TestScandinavianFoldingFilter, TestIgnore, TestRandomChains]
>[junit4] Completed [130/272 (1!)] on J4 in 9.85s, 2 tests, 1 error <<< 
> FAILURES!
> {noformat}



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

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

[jira] [Created] (LUCENE-7442) MinHashFilter.FixedSizeTreeSet.add() calls SortedSet.last() without first testing for emptiness, under which condition NoSuchElementException is thrown

[Steve Rowe (JIRA)]

Steve Rowe created LUCENE-7442:
--

 Summary: MinHashFilter.FixedSizeTreeSet.add() calls 
SortedSet.last() without first testing for emptiness, under which condition 
NoSuchElementException is thrown
 Key: LUCENE-7442
 URL: https://issues.apache.org/jira/browse/LUCENE-7442
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Reporter: Steve Rowe


My Jenkins found this reproducing branch_6x seed:

{noformat}
   [junit4] Suite: org.apache.lucene.analysis.core.TestRandomChains
   [junit4]   2> Exception from random analyzer: 
   [junit4]   2> charfilters=
   [junit4]   2> tokenizer=
   [junit4]   2>   org.apache.lucene.analysis.standard.StandardTokenizer()
   [junit4]   2> filters=
   [junit4]   2>   
org.apache.lucene.analysis.minhash.MinHashFilter(ValidatingTokenFilter@6ae99167 
term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,
 5, 5, -3, true)
   [junit4]   2>   
org.apache.lucene.analysis.bg.BulgarianStemFilter(ValidatingTokenFilter@40844352
 
term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,keyword=false)
   [junit4]   2> offsetsAreCorrect=true
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRandomChains 
-Dtests.method=testRandomChainsWithLargeStrings -Dtests.seed=4733E677EBDC28FC 
-Dtests.slow=true -Dtests.locale=ar-OM -Dtests.timezone=Atlantic/South_Georgia 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] ERROR   3.18s J4 | 
TestRandomChains.testRandomChainsWithLargeStrings <<<
   [junit4]> Throwable #1: java.util.NoSuchElementException
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([4733E677EBDC28FC:2D685966B292080F]:0)
   [junit4]>at java.util.TreeMap.key(TreeMap.java:1323)
   [junit4]>at java.util.TreeMap.lastKey(TreeMap.java:297)
   [junit4]>at java.util.TreeSet.last(TreeSet.java:401)
   [junit4]>at 
org.apache.lucene.analysis.minhash.MinHashFilter$FixedSizeTreeSet.add(MinHashFilter.java:325)
   [junit4]>at 
org.apache.lucene.analysis.minhash.MinHashFilter.incrementToken(MinHashFilter.java:159)
   [junit4]>at 
org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:67)
   [junit4]>at 
org.apache.lucene.analysis.bg.BulgarianStemFilter.incrementToken(BulgarianStemFilter.java:48)
   [junit4]>at 
org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:67)
   [junit4]>at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException(BaseTokenStreamTestCase.java:405)
   [junit4]>at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:510)
   [junit4]>at 
org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings(TestRandomChains.java:959)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): 
{dummy=Lucene50(blocksize=128)}, docValues:{}, maxPointsInLeafNode=252, 
maxMBSortInHeap=5.297834377897023, sim=ClassicSimilarity, locale=ar-OM, 
timezone=Atlantic/South_Georgia
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=395080152,total=465567744
   [junit4]   2> NOTE: All tests run in this JVM: 
[TestDecimalDigitFilterFactory, TestMultiWordSynonyms, 
TestReversePathHierarchyTokenizer, TestDoubleEscape, 
TestHunspellStemFilterFactory, TestArabicNormalizationFilter, 
TestUAX29URLEmailAnalyzer, TestSwedishLightStemFilterFactory, 
TestBulgarianStemmer, TestASCIIFoldingFilter, 
TestDelimitedPayloadTokenFilterFactory, TestIndonesianStemmer, TestCircumfix, 
EdgeNGramTokenFilterTest, TestPatternTokenizer, TestScandinavianFoldingFilter, 
TestIgnore, TestRandomChains]
   [junit4] Completed [130/272 (1!)] on J4 in 9.85s, 2 tests, 1 error <<< 
FAILURES!
{noformat}



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

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

[jira] [Commented] (LUCENE-7440) Document skipping on large indexes is broken

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7440:
---

+1 compareUnsigned is the way to go! It's an intrinsic, too.

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {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

Re: 6.2.1?

[Michael McCandless]

Thank you Uwe!

Mike McCandless

http://blog.mikemccandless.com


On Fri, Sep 9, 2016 at 3:18 PM, Uwe Schindler  wrote:
> Hi,
>
> Ok. Then we should also fix the StandardAnalyzer related backwards 
> compatibility bugs introduced by 6.2.0.
>
> I can take care of that. I reopened the issue last week.
>
> Uwe
>
> Am 9. September 2016 21:11:37 MESZ, schrieb Anshum Gupta 
> :
>>This looks nasty. Makes sense to have a 6.2.1 out.
>>
>>I would have taken up the responsibility here but I'm traveling
>>mid-next
>>week onwards and wouldn't have the bandwidth needed to manage a
>>release.
>>
>>On Fri, Sep 9, 2016 at 12:07 PM Chris Hostetter
>>
>>wrote:
>>
>>>
>>>
>>> FWIW: SOLR-9490 Is a pretty nasty bug for most BoolField users.
>>>
>>> We should probably consider a rapid 6.2.1 release.
>>>
>>>
>>> https://issues.apache.org/jira/browse/SOLR-9490
>>>
>>>
>>>
>>> -Hoss
>>> http://www.lucidworks.com/
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>
> --
> Uwe Schindler
> H.-H.-Meier-Allee 63, 28213 Bremen
> http://www.thetaphi.de
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Commented] (LUCENE-7432) TestIndexWriterOnError.testCheckpoint fails on IBM J9

[Kevin Langman (JIRA)]

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

Kevin Langman commented on LUCENE-7432:
---

APAR IV88620 will be included in the upcoming IBM Java 8.0.3.12 release.

> TestIndexWriterOnError.testCheckpoint fails on IBM J9
> -
>
> Key: LUCENE-7432
> URL: https://issues.apache.org/jira/browse/LUCENE-7432
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>  Labels: IBM-J9
>
> Not sure if this is a J9 issue or a Lucene issue, but using this version of 
> J9:
> {noformat}
> 09:26 $ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp10-20160720_02(SR3fp10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
> 20160719_312156 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160719_1144_B312156
> JIT  - tr.r14.java_20160629_120284.01
> GC   - R28_Java8_SR3_20160719_1144_B312156_CMPRSS
> J9CL - 20160719_312156)
> JCL - 20160719_01 based on Oracle jdk8u101-b13
> {noformat}
> This test failure seems to reproduce:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestIndexWriterOnVMError -Dtests.method=testCheckpoint 
> -Dtests.seed=FAB0DC147AFDBF4E -Dtests.nightly=true -Dtests.slow=true 
> -Dtests.locale=kn -Dtests.timezone=Australia/South -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR196s | TestIndexWriterOnVMError.testCheckpoint <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: 
> MockDirectoryWrapper: cannot close: there are still 9 open files: 
> {_2_Asserting_0.pos=1, _2_Asserting_0.dvd=1, _2.fdt=1, _2_Asserting_0.doc=1, 
> _2_Asserting_0.tim=1, _2.nvd=1, _2.tvd=1, _3.cfs=1, _2.dim=1}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([FAB0DC147AFDBF4E:FBA18A7C5B16548D]:0)
>[junit4]>  at 
> org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:841)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterOnVMError.doTest(TestIndexWriterOnVMError.java:89)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterOnVMError.testCheckpoint(TestIndexWriterOnVMError.java:280)
>[junit4]>  at java.lang.Thread.run(Thread.java:785)
>[junit4]> Caused by: java.lang.RuntimeException: unclosed IndexInput: 
> _2.dim
>[junit4]>  at 
> org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:732)
>[junit4]>  at 
> org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:776)
>[junit4]>  at 
> org.apache.lucene.codecs.lucene60.Lucene60PointsReader.(Lucene60PointsReader.java:85)
>[junit4]>  at 
> org.apache.lucene.codecs.lucene60.Lucene60PointsFormat.fieldsReader(Lucene60PointsFormat.java:104)
>[junit4]>  at 
> org.apache.lucene.codecs.asserting.AssertingPointsFormat.fieldsReader(AssertingPointsFormat.java:66)
>[junit4]>  at 
> org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:128)
>[junit4]>  at 
> org.apache.lucene.index.SegmentReader.(SegmentReader.java:74)
>[junit4]>  at 
> org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:145)
>[junit4]>  at 
> org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:197)
>[junit4]>  at 
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:103)
>[junit4]>  at 
> org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:460)
>[junit4]>  at 
> org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:103)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterOnVMError.doTest(TestIndexWriterOnVMError.java:175)
>[junit4]>  ... 37 more
>[junit4]   2> NOTE: leaving temporary files on disk at: 
> /l/trunk/lucene/build/core/test/J0/temp/lucene.index.TestIndexWriterOnVMError_FAB0DC147AFDBF4E-001
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene62), 
> sim=ClassicSimilarity, locale=kn, timezone=Australia/South
>[junit4]   2> NOTE: Linux 4.4.0-34-generic amd64/IBM Corporation 1.8.0 
> (64-bit)/cpus=8,threads=1,free=55483576,total=76742656
>[junit4]   2> NOTE: All tests run in this JVM: [TestIndexWriterOnVMError]
> {noformat}
> The test is quite stressful, provoking "unexpected" exceptions at tricky 
> times for {{IndexWriter}}.
> When I run with Oracle's 1.8.0_101 with that same "reproduce with", the test 
> passes.
> I see a similar failure for {{testUnknownError}}.



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

-
To unsubscribe, e-mail: 

[jira] [Created] (SOLR-9494) CollapseQParserPlugin doesn't propagate needsScores() correctly

[David Smiley (JIRA)]

David Smiley created SOLR-9494:
--

 Summary: CollapseQParserPlugin doesn't propagate needsScores() 
correctly
 Key: SOLR-9494
 URL: https://issues.apache.org/jira/browse/SOLR-9494
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: David Smiley
Assignee: David Smiley


CollapseQParserPlugin internally has a number of Lucene Collector 
implementations, all of which extend Solr DelegatingCollector which provides a 
default implementation of the method needsScores() based on what it's 
delegating too.  But Collapsing's collectors fail to consider that these 
collectors _themselves_ sometimes need the score, irrespective of wether or not 
a delegate might.

In most cases nobody would notice this bug because most queries don't seem to 
care.  However, SpanQueries are cranky about this, which will either throw an 
AssertionError or NPE if you ask for a score without saying in advance you 
wanted them.

I have a patch forthcoming, but am having trouble ATM reproducing to create a 
test.  The most straight-forward test doesn't trip it.  I have a failing test 
in a client environment, and a patch that fixes it.  Reproducing seems to 
involve a cached query somehow.



--
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+134) - Build # 1693 - Still Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
IOException occured when talking to server at: https://127.0.0.1:36768/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:36768/solr
at 
__randomizedtesting.SeedInfo.seed([F9D989217B3EB010:45B7FF33DF6D336A]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:158)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Updated] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-9310:
---
Fix Version/s: 5.5.3

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 5.5.3, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, 
> SOLR-9310_5x.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



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

[ANNOUNCE] Apache Solr 5.5.3 released

[Anshum Gupta]

09 September 2016, Apache Solr™ 5.5.3 available

The Lucene PMC is pleased to announce the release of Apache Solr 5.5.3

Solr is the popular, blazing fast, open source NoSQL search platform
from the Apache Lucene project. Its major features include powerful
full-text search, hit highlighting, faceted search, dynamic
clustering, database integration, rich document (e.g., Word, PDF)
handling, and geospatial search. Solr is highly scalable, providing
fault tolerant distributed search and indexing, and powers the search
and navigation features of many of the world's largest internet sites.

This release includes 5 bug fixes since the 5.5.2 release.

The release is available for immediate download at:

  http://www.apache.org/dyn/closer.lua/lucene/solr/5.5.3

This release specially contains 2 critical fixes:
* The number of TCP connections in CLOSE_WAIT state do not spike during
indexing,
* PeerSync no longer fails on a node restart due to IndexFingerPrint
mismatch.

Please read CHANGES.txt for a detailed list of changes:

  https://lucene.apache.org/solr/5_5_3/changes/Changes.html

Please report any feedback to the mailing lists
(http://lucene.apache.org/solr/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring
network for distributing releases. It is possible that the mirror you
are using may not have replicated the release yet. If that is the
case, please try another mirror. This also goes for Maven access.

-Anshum Gupta

[ANNOUNCE] Apache Lucene 5.5.3 released

[Anshum Gupta]

09 September 2016, Apache Lucene™ 5.5.3 available

The Lucene PMC is pleased to announce the release of Apache Lucene 5.5.3

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that requires full-text search, especially cross-platform.

The release is available for immediate download at:

  http://www.apache.org/dyn/closer.lua/lucene/java/5.5.3

Please read CHANGES.txt for a full list of new features and changes:

  https://lucene.apache.org/core/5_5_3/changes/Changes.html

Please report any feedback to the mailing lists
(http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network
for distributing releases.  It is possible that the mirror you are using
may not have replicated the release yet.  If that is the case, please
try another mirror.  This also goes for Maven access.

-Anshum Gupta

[jira] [Commented] (SOLR-7393) HDFS poor indexing performance

[David Johnson (JIRA)]

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

David Johnson commented on SOLR-7393:
-

Does Hadoop have the native library configuration set appropriately?  

> HDFS poor indexing performance
> --
>
> Key: SOLR-7393
> URL: https://issues.apache.org/jira/browse/SOLR-7393
> Project: Solr
>  Issue Type: Bug
>  Components: Hadoop Integration, hdfs, SolrCloud
>Affects Versions: 4.7.2, 4.10.3
> Environment: HDP 2.2 / HDP Search + LucidWorks Hive SerDe
>Reporter: Hari Sekhon
>Priority: Critical
>
> When switching SolrCloud from local dataDir to HDFS directory factory 
> indexing performance falls through the floor.
> I've also observed very high latency on both QTime and code timer on HDFS 
> writes compares to local dataDir writes (using check_solr_write.pl from 
> https://github.com/harisekhon/nagios-plugins). Single test document write 
> latency jumps from a few dozen milliseconds to 700-1700 millisecs, over 2000 
> on some runs.
> A previous bulk online indexing job from Hive to SolrCloud that took 2 hours 
> for 620M rows ended up taking a projected 20+ hours and never completing, 
> usually breaking around the 16-17 hour timeframe when left overnight.
> It's worth noting that I had to disable the HDFS write cache which was 
> causing index corruption (SOLR-7255) on the advice of Mark Miller, who tells 
> me this doesn't make much performance difference anway.
> This is probably also related to SolrCloud not respecting HDFS replication 
> factor, effectively making 4 copies of data instead of 2 (SOLR-6528), but 
> that solely doesn't account for the massive performance drop going from 
> vanilla SolrCloud to SolrCloud on HDFS HA + Kerberos.
> Hari Sekhon
> http://www.linkedin.com/in/harisekhon



--
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.2.1?

[Uwe Schindler]

Hi,

Ok. Then we should also fix the StandardAnalyzer related backwards 
compatibility bugs introduced by 6.2.0.

I can take care of that. I reopened the issue last week.

Uwe

Am 9. September 2016 21:11:37 MESZ, schrieb Anshum Gupta 
:
>This looks nasty. Makes sense to have a 6.2.1 out.
>
>I would have taken up the responsibility here but I'm traveling
>mid-next
>week onwards and wouldn't have the bandwidth needed to manage a
>release.
>
>On Fri, Sep 9, 2016 at 12:07 PM Chris Hostetter
>
>wrote:
>
>>
>>
>> FWIW: SOLR-9490 Is a pretty nasty bug for most BoolField users.
>>
>> We should probably consider a rapid 6.2.1 release.
>>
>>
>> https://issues.apache.org/jira/browse/SOLR-9490
>>
>>
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

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

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

Re: 6.2.1?

[Anshum Gupta]

This looks nasty. Makes sense to have a 6.2.1 out.

I would have taken up the responsibility here but I'm traveling mid-next
week onwards and wouldn't have the bandwidth needed to manage a release.

On Fri, Sep 9, 2016 at 12:07 PM Chris Hostetter 
wrote:

>
>
> FWIW: SOLR-9490 Is a pretty nasty bug for most BoolField users.
>
> We should probably consider a rapid 6.2.1 release.
>
>
> https://issues.apache.org/jira/browse/SOLR-9490
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

6.2.1?

[Chris Hostetter]

FWIW: SOLR-9490 Is a pretty nasty bug for most BoolField users.

We should probably consider a rapid 6.2.1 release.


https://issues.apache.org/jira/browse/SOLR-9490



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

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

[jira] [Resolved] (SOLR-9490) BoolField always returning false for non-DV fields when javabin involved (via solrj, or intra node communicaition)

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-9490.

   Resolution: Fixed
 Assignee: Hoss Man
Fix Version/s: 6.3
   master (7.0)

> BoolField always returning false for non-DV fields when javabin involved (via 
> solrj, or intra node communicaition)
> --
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Critical
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9490.patch, SOLR-9490.patch, Solr9490.java
>
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-9490) BoolField always returning false for non-DV fields when javabin involved (via solrj, or intra node communicaition)

[ASF subversion and git services (JIRA)]

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

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

Commit 60ce8d7c549ef90cd6aaa9297bf31aeb3dd3417e in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=60ce8d7 ]

SOLR-9490: Fixed bugs in BoolField that caused it to erroneously return "false" 
for all docs depending on usage


> BoolField always returning false for non-DV fields when javabin involved (via 
> solrj, or intra node communicaition)
> --
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
> Attachments: SOLR-9490.patch, SOLR-9490.patch, Solr9490.java
>
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-9490) BoolField always returning false for non-DV fields when javabin involved (via solrj, or intra node communicaition)

[ASF subversion and git services (JIRA)]

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

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

Commit 5aedab619af9c65136b18dac46c493994465485b in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5aedab6 ]

SOLR-9490: Merge remote-tracking branch 'refs/remotes/origin/master'


> BoolField always returning false for non-DV fields when javabin involved (via 
> solrj, or intra node communicaition)
> --
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
> Attachments: SOLR-9490.patch, SOLR-9490.patch, Solr9490.java
>
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-9490) BoolField always returning false for non-DV fields when javabin involved (via solrj, or intra node communicaition)

[ASF subversion and git services (JIRA)]

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

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

Commit d59715f14bc180ebb9b2aef8ebbcb02103e9fcc8 in lucene-solr's branch 
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d59715f ]

SOLR-9490: Fixed bugs in BoolField that caused it to erroneously return "false" 
for all docs depending on usage

(cherry picked from commit 60ce8d7c549ef90cd6aaa9297bf31aeb3dd3417e)


> BoolField always returning false for non-DV fields when javabin involved (via 
> solrj, or intra node communicaition)
> --
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
> Attachments: SOLR-9490.patch, SOLR-9490.patch, Solr9490.java
>
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-9490) BoolField always returning false for non-DV fields when javabin involved (via solrj, or intra node communicaition)

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-9490:
---
Summary: BoolField always returning false for non-DV fields when javabin 
involved (via solrj, or intra node communicaition)  (was: BoolField always 
returning false for non-DV fields?)

> BoolField always returning false for non-DV fields when javabin involved (via 
> solrj, or intra node communicaition)
> --
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
> Attachments: SOLR-9490.patch, SOLR-9490.patch, Solr9490.java
>
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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: [VOTE] Release PyLucene 6.2.0 (rc2)

[Jeff Breidenbach]

+1

[JENKINS] Lucene-Solr-SmokeRelease-6.x - Build # 145 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.x/145/

No tests ran.

Build Log:
[...truncated 40542 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (12.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.3.0-src.tgz...
   [smoker] 30.0 MB in 0.05 sec (567.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.3.0.tgz...
   [smoker] 64.6 MB in 0.08 sec (812.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.3.0.zip...
   [smoker] 75.2 MB in 0.09 sec (810.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.3.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6056 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.3.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6056 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.3.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 226 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   5.5.3
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1436, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1380, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1418, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, gitRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 597, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
gitRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 743, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1356, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/build.xml:559: 
exec returned: 1

Total time: 72 minutes 27 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any




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

[jira] [Updated] (SOLR-9490) BoolField always returning false for non-DV fields?

[Hoss Man (JIRA)]

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

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

patch w/fix i'm currently testing

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
> Attachments: SOLR-9490.patch, SOLR-9490.patch, Solr9490.java
>
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-9490) BoolField always returning false for non-DV fields?

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9490:


Not to be pedantic, but I believe this isn't about SolrCloud, rather about 
distributed-search (shards).  Neither require the other.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
> Attachments: SOLR-9490.patch, Solr9490.java
>
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-7417) Highlighting fails for MultiPhraseQuery's with one clause

[David Smiley (JIRA)]

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

David Smiley updated LUCENE-7417:
-
Component/s: (was: core/search)
 modules/highlighter

> Highlighting fails for MultiPhraseQuery's with one clause
> -
>
> Key: LUCENE-7417
> URL: https://issues.apache.org/jira/browse/LUCENE-7417
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Affects Versions: 5.2.1, 5.x, 5.5.2
>Reporter: Thomas Kappler
>Assignee: David Smiley
> Fix For: 6.3, 5.5.4
>
> Attachments: multiphrasequery_singleclause_highlighting.patch
>
>
> This bug is the same issue as LUCENE-7231, just for MultiPhraseQuery instead 
> of PhraseQuery. The fix is the same as well. To reproduce, change the test 
> that was committed for LUCENE-7231 to use a MultiPhraseQuery. It results in 
> the same error
> {{java.lang.IllegalArgumentException: Less than 2 subSpans.size():1}}
> I have a patch including a test against branch_5.x, it just needs to go 
> through legal before I can post it.



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

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

[jira] [Resolved] (LUCENE-7417) Highlighting fails for MultiPhraseQuery's with one clause

[David Smiley (JIRA)]

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

David Smiley resolved LUCENE-7417.
--
   Resolution: Fixed
Fix Version/s: 5.5.4
   6.3
Lucene Fields: New,Patch Available  (was: New)

Thanks for the patch Thomas!

BTW in my commit I also updated some looping in this method to use Java 5 
for-each style.

> Highlighting fails for MultiPhraseQuery's with one clause
> -
>
> Key: LUCENE-7417
> URL: https://issues.apache.org/jira/browse/LUCENE-7417
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Affects Versions: 5.2.1, 5.x, 5.5.2
>Reporter: Thomas Kappler
>Assignee: David Smiley
> Fix For: 6.3, 5.5.4
>
> Attachments: multiphrasequery_singleclause_highlighting.patch
>
>
> This bug is the same issue as LUCENE-7231, just for MultiPhraseQuery instead 
> of PhraseQuery. The fix is the same as well. To reproduce, change the test 
> that was committed for LUCENE-7231 to use a MultiPhraseQuery. It results in 
> the same error
> {{java.lang.IllegalArgumentException: Less than 2 subSpans.size():1}}
> I have a patch including a test against branch_5.x, it just needs to go 
> through legal before I can post it.



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

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

Re: Release Solr 5.5.3

[David Smiley]

Ok; thanks Anshum.

On Fri, Sep 9, 2016 at 1:40 PM Anshum Gupta  wrote:

> Hey David,
>
> I'm just about to update the website and send out the notification for
> 5.5.3 in a few hours (as soon as I get some time at work). About the
> section, I assume you are talking about the CHANGES.txt file and I
> should've done that as part of the release process but I think I missed the
> 5x, and master branches. I've added the 5.5.3 section to both, and moved
> your entry to a new 5.5.4 section on the 5x branch.
> 5.5.4 section addition on branch_5_5 is a part of the post-release
> process, so I'll remember to move this to the correct section when I add
> that.
>
>
>
> On Fri, Sep 9, 2016 at 8:17 AM David Smiley 
> wrote:
>
>> Anhum,
>> Minutes ago I went and committed
>> https://issues.apache.org/jira/browse/LUCENE-7417 to master, branch_6x,
>> branch_5x, and branch_5_5.  While on both the v5 branches, I noticed the
>> last 5.5.x was specifically 5.5.2 so I went and added this under a new
>> 5.5.3.   That is now committed.  Then the realization hits me that you're
>> doing a 5.5.3 release and it just passed a vote  So I guess I should change
>> those entries to be 5.5.4 and probably also add a blank 5.5.3 section so
>> it's clear there were not additions in 5.5.3 for Lucene?  BTW I think this
>> bug is "minor" IMO.
>> ~ David
>>
>> On Thu, Sep 8, 2016 at 1:29 PM Anshum Gupta 
>> wrote:
>>
>>> The release notes (draft) can be found here:
>>>
>>> Lucene: https://wiki.apache.org/lucene-java/ReleaseNote553
>>> Solr: https://wiki.apache.org/solr/ReleaseNote553
>>>
>>> Please feel free to edit/fix it.
>>>
>>> -Anshum
>>>
>>> On Wed, Jul 20, 2016 at 1:35 PM David Smiley 
>>> wrote:
>>>
 Okay.  BTW SOLR-9290 isn't "Just" high indexing rates, but it's for
 those using SSL too -- correct me if I'm wrong.  We don't want to raise
 alarm bells too loudly :-)

 On Wed, Jul 20, 2016 at 4:18 PM Anshum Gupta 
 wrote:

> Hi,
>
> With SOLR-9290 fixed, I think it calls for a bug fix release as it
> impacts all users with high indexing rates.
>
> If someone else wants to work on the release, I am fine with it else,
> I'll be happy to be the RM and cut an RC a week from now.
>
> --
> Anshum Gupta
>
 --
 Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
 LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
 http://www.solrenterprisesearchserver.com

>>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Release Solr 5.5.3

[Anshum Gupta]

Hey David,

I'm just about to update the website and send out the notification for
5.5.3 in a few hours (as soon as I get some time at work). About the
section, I assume you are talking about the CHANGES.txt file and I
should've done that as part of the release process but I think I missed the
5x, and master branches. I've added the 5.5.3 section to both, and moved
your entry to a new 5.5.4 section on the 5x branch.
5.5.4 section addition on branch_5_5 is a part of the post-release process,
so I'll remember to move this to the correct section when I add that.



On Fri, Sep 9, 2016 at 8:17 AM David Smiley 
wrote:

> Anhum,
> Minutes ago I went and committed
> https://issues.apache.org/jira/browse/LUCENE-7417 to master, branch_6x,
> branch_5x, and branch_5_5.  While on both the v5 branches, I noticed the
> last 5.5.x was specifically 5.5.2 so I went and added this under a new
> 5.5.3.   That is now committed.  Then the realization hits me that you're
> doing a 5.5.3 release and it just passed a vote  So I guess I should change
> those entries to be 5.5.4 and probably also add a blank 5.5.3 section so
> it's clear there were not additions in 5.5.3 for Lucene?  BTW I think this
> bug is "minor" IMO.
> ~ David
>
> On Thu, Sep 8, 2016 at 1:29 PM Anshum Gupta 
> wrote:
>
>> The release notes (draft) can be found here:
>>
>> Lucene: https://wiki.apache.org/lucene-java/ReleaseNote553
>> Solr: https://wiki.apache.org/solr/ReleaseNote553
>>
>> Please feel free to edit/fix it.
>>
>> -Anshum
>>
>> On Wed, Jul 20, 2016 at 1:35 PM David Smiley 
>> wrote:
>>
>>> Okay.  BTW SOLR-9290 isn't "Just" high indexing rates, but it's for
>>> those using SSL too -- correct me if I'm wrong.  We don't want to raise
>>> alarm bells too loudly :-)
>>>
>>> On Wed, Jul 20, 2016 at 4:18 PM Anshum Gupta 
>>> wrote:
>>>
 Hi,

 With SOLR-9290 fixed, I think it calls for a bug fix release as it
 impacts all users with high indexing rates.

 If someone else wants to work on the release, I am fine with it else,
 I'll be happy to be the RM and cut an RC a week from now.

 --
 Anshum Gupta

>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>>
>> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

[jira] [Commented] (LUCENE-7440) Document skipping on large indexes is broken

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7440:


bq. Another alternative would be to use Integer.compareUnsigned()

+1

These values should never overflow 2^32

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



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

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

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

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-5944 at 9/9/16 5:39 PM:


Here's more on the problem with the re-ordered DBQs that Shalin pointed out.
When a document requiring in-place update cannot be "resurrected" when the 
original full indexed document has been deleted by an out of order DBQ. As per 
this patch, expected behaviour in this case is to throw the replica into LIR 
(this situation itself is rare). Here's an example of the situation:
{code}
ADD(id=x, val=5, ver=1)
UPD(id=x, val=10, ver = 2)
DBQ(q=val:10, ver=4)
DV(id=x, val=5, ver=3)
{code}

Here ^ the version 3 update, when it arrives, will not have a document to 
update to in its index.


was (Author: ichattopadhyaya):
Here's more on the problem with the re-ordered DBQs that Shalin pointed out.
When a document requiring in-place update cannot be "resurrected" when the 
original full indexed document has been deleted by an out of order DBQ. As per 
this patch, expected behaviour in this case is to throw the replica into LIR 
(this situation itself is rare). Here's an example of the situation:
{code}
ADD(id=x, val=5, ver=1)
UPD(id=x, val=10, ver = 2)
DBQ(q=val:10, v=4)
DV(id=x, val=5, ver=3)
{code}


> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: DUP.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.62D328FA1DEA57FD.fail2.txt, 
> hoss.62D328FA1DEA57FD.fail3.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



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

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

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

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-5944:


Here's more on the problem with the re-ordered DBQs that Shalin pointed out.
When a document requiring in-place update cannot be "resurrected" when the 
original full indexed document has been deleted by an out of order DBQ. As per 
this patch, expected behaviour in this case is to throw the replica into LIR 
(this situation itself is rare). Here's an example of the situation:
{code}
ADD(id=x, val=5, ver=1)
UPD(id=x, val=10, ver = 2)
DBQ(q=val:10, v=4)
DV(id=x, val=5, ver=3)
{code}


> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: DUP.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.62D328FA1DEA57FD.fail2.txt, 
> hoss.62D328FA1DEA57FD.fail3.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



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

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

[jira] [Updated] (SOLR-9493) uniqueKey generation fails if content POSTed as "application/javabin".

[Yury Kartsev (JIRA)]

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

Yury Kartsev updated SOLR-9493:
---
Description: 
I have faced a weird issue when the same application code (using SolrJ) fails 
indexing a document without a unique key (should be auto-generated by SOLR) in 
SolrCloud and succeeds indexing it in standalone SOLR instance (or even in 
cloud mode, but from web interface of one of the replicas). Difference is 
obviously only between clients (CloudSolrClient vs HttpSolrClient) and SOLR 
URLs (Zokeeper hostname+port vs standalone SOLR instance hostname and port). 
Failure is seen as "org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Document 
is missing mandatory uniqueKey field: id".

I am using SOLR 5.1. In cloud mode I have 1 shard and 3 replicas.

After lot of debugging and investigation (see below as well as my 
[StackOverflow 
post|http://stackoverflow.com/questions/39401792/uniquekey-generation-does-not-work-in-solrcloud-but-works-if-standalone])
 I came to a conclusion that the difference in failing and succeeding calls is 
simply content type of the POSTing requests. Local proxy clearly shows that the 
request fails if content is sent as "application/javabin" (see attached 
screenshot with sensitive data removed) and succeeds if content sent as 
"application/xml; charset=UTF-8"  (see attached screenshot with sensitive data 
removed).

Would you be able to please assist?

Thank you very much in advance!


Copying whole description and investigation here as well:


[Documentation|https://cwiki.apache.org/confluence/display/solr/Other+Schema+Elements]
 states:{quote}Schema defaults and copyFields cannot be used to populate the 
uniqueKey field. You can use UUIDUpdateProcessorFactory to have uniqueKey 
values generated automatically.{quote}

Therefore I have added my uniqueKey field to the schema:{code}
...

...
id{code}Then I have added updateRequestProcessorChain to 
my solrconfig:{code}

id


{code}And made it the default for the 
UpdateRequestHandler:{code}
 
  uuid
 
{code}
Adding new documents with null/absent id works fine as from web-interface of 
one of the replicas, as when using SOLR in standalone mode (non-cloud) from my 
application. Although when only I'm using SolrCloud and add document from my 
application (using CloudSolrClient from SolrJ) it fails with 
"org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Document 
is missing mandatory uniqueKey field: id"

All other operations like ping or search for documents work fine in either mode 
(standalone or cloud).

INVESTIGATION (i.e. more details):

In standalone mode obviously update request is:{code}POST 
standalone_host:port/solr/collection_name/update?wt=json{code}
In SOLR cloud mode, when adding document from one replica's web interface, 
update request is (found through inspecting the call made by web interface): 
{code}POST 
replica_host:port/solr/collection_name_shard1_replica_1/update?wt=json{code}
In both these cases payload is something like:{code}{
"add": {
"doc": {
 .
},
"boost": 1.0,
"overwrite": true,
"commitWithin": 1000
}
}{code}
In case when CloudSolrClient is used, the following happens (found through 
debugging):

Using ZK and some logic, URL list of replicas is constructed that looks like 
this:{code}[http://replica_1_host:port/solr/collection_name/,
 http://replica_2_host:port/solr/collection_name/,
 http://replica_3_host:port/solr/collection_name/]{code}
This code is called:{code}LBHttpSolrClient.Req req = new 
LBHttpSolrClient.Req(request, theUrlList);
LBHttpSolrClient.Rsp rsp = lbClient.request(req);
return rsp.getResponse();{code}
Where the second line fails with the exception.
If to debug the second line further, it ends up calling HttpClient.execute 
(from HttpSolrClient.executeMethod) for:{code}POST 
http://replica_1_host:port/solr/collection_name/update?wt=javabin=2 
HTTP/1.1
POST 
http://replica_2_host:port/solr/collection_name/update?wt=javabin=2 
HTTP/1.1
POST 
http://replica_3_host:port/solr/collection_name/update?wt=javabin=2 
HTTP/1.1{code}
And the very first request returns 400 Bad Request with replica 1 logging 
"Document is missing mandatory uniqueKey field: id" in the logs.

The funny thing is that when I execute the same request using POSTMAN (but with 
JSON instead of binary payload), it works! Am I doing something wrong here? I 
assume it's definitely something in the way of how the request is made...

UPDATE:

I have used local proxy in order to see the difference in these 2 requests sent 
by my application in order to understand what is different there. Looks like 
the only difference is content type. In case of cloud 

[jira] [Updated] (SOLR-9490) BoolField always returning false for non-DV fields?

[Hoss Man (JIRA)]

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

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

{quote}
I've spotted that the error with the json response happens when there is more 
than 1 shard in the collection.

So toExternal() isn't being called when using a single shard and the json 
response writer, but it is used by the JavaBinCodec (via toObject() for 
BoolField) since javabin is used for communication between the shards?
{quote}

Gah .. yes, of course, that's totally plausable.  It should have occured to me 
when you posted your original JSON example that you might have bene using 
SolrCloud.  That would explain why you saw it with JSON, but Pavan only 
reported seeing it using javabin, and *not* with JSON.

(I assumed that since your reports conflicted, there must have been some other 
independent variable you had in common -- but it was actaully a _difference_ 
you two had: cloud mode)

Dan: thank you for the patch, I've refactored the key bit into our existing 
SolrExampleTests, so it's run as part of many tests (embedded, Jetty with XML, 
jetty with javabin, etc...)

With the attached test patch, all of these tests fail...

{noformat}
   [junit4] Tests with failures [seed: 4947C3B3180BA616]:
   [junit4]   - 
org.apache.solr.client.solrj.embedded.SolrExampleStreamingBinaryTest.testExampleConfig
   [junit4]   - 
org.apache.solr.client.solrj.embedded.SolrExampleJettyTest.testExampleConfig
   [junit4]   - 
org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig
   [junit4]   - 
org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.testExampleConfig
{noformat}

..working on fix, I suspect Colvin's earlier comments in SOLR-9187  are correct 
and it's a trivial fix.


> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
> Attachments: SOLR-9490.patch, Solr9490.java
>
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-9493) uniqueKey generation fails if content POSTed as "application/javabin".

[Yury Kartsev (JIRA)]

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

Yury Kartsev updated SOLR-9493:
---
Description: 
I have faced a weird issue when the same application code (using SolrJ) fails 
indexing a document without a unique key (should be auto-generated by SOLR) in 
SolrCloud and succeeds indexing it in standalone SOLR instance (or even in 
cloud mode, but from web interface of one of the replicas). Difference is 
obviously only between clients (CloudSolrClient vs HttpSolrClient) and SOLR 
URLs (Zokeeper hostname+port vs standalone SOLR instance hostname and port). 
Failure is seen as "org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Document 
is missing mandatory uniqueKey field: id".

I am using SOLR 5.1. In cloud mode I have 1 shard and 3 replicas.

After lot of debugging and investigation (see below as well as my 
[StackOverflow 
post|http://stackoverflow.com/questions/39401792/uniquekey-generation-does-not-work-in-solrcloud-but-works-if-standalone])
 I came to a conclusion that the difference in failing and succeeding calls is 
simply content type of the POSTing requests. Local proxy clearly shows that the 
request fails if content is sent as "application/javabin" (see attached) and 
succeeds if content sent as "application/xml; charset=UTF-8"  (see attached).

Would you be able to please assist?

Thank you very much in advance!


Copying whole description and investigation here as well:


[Documentation|https://cwiki.apache.org/confluence/display/solr/Other+Schema+Elements]
 states:{quote}Schema defaults and copyFields cannot be used to populate the 
uniqueKey field. You can use UUIDUpdateProcessorFactory to have uniqueKey 
values generated automatically.{quote}

Therefore I have added my uniqueKey field to the schema:{code}
...

...
id{code}Then I have added updateRequestProcessorChain to 
my solrconfig:{code}

id


{code}And made it the default for the 
UpdateRequestHandler:{code}
 
  uuid
 
{code}
Adding new documents with null/absent id works fine as from web-interface of 
one of the replicas, as when using SOLR in standalone mode (non-cloud) from my 
application. Although when only I'm using SolrCloud and add document from my 
application (using CloudSolrClient from SolrJ) it fails with 
"org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Document 
is missing mandatory uniqueKey field: id"

All other operations like ping or search for documents work fine in either mode 
(standalone or cloud).

INVESTIGATION (i.e. more details):

In standalone mode obviously update request is:{code}POST 
standalone_host:port/solr/collection_name/update?wt=json{code}
In SOLR cloud mode, when adding document from one replica's web interface, 
update request is (found through inspecting the call made by web interface): 
{code}POST 
replica_host:port/solr/collection_name_shard1_replica_1/update?wt=json{code}
In both these cases payload is something like:{code}{
"add": {
"doc": {
 .
},
"boost": 1.0,
"overwrite": true,
"commitWithin": 1000
}
}{code}
In case when CloudSolrClient is used, the following happens (found through 
debugging):

Using ZK and some logic, URL list of replicas is constructed that looks like 
this:{code}[http://replica_1_host:port/solr/collection_name/,
 http://replica_2_host:port/solr/collection_name/,
 http://replica_3_host:port/solr/collection_name/]{code}
This code is called:{code}LBHttpSolrClient.Req req = new 
LBHttpSolrClient.Req(request, theUrlList);
LBHttpSolrClient.Rsp rsp = lbClient.request(req);
return rsp.getResponse();{code}
Where the second line fails with the exception.
If to debug the second line further, it ends up calling HttpClient.execute 
(from HttpSolrClient.executeMethod) for:{code}POST 
http://replica_1_host:port/solr/collection_name/update?wt=javabin=2 
HTTP/1.1
POST 
http://replica_2_host:port/solr/collection_name/update?wt=javabin=2 
HTTP/1.1
POST 
http://replica_3_host:port/solr/collection_name/update?wt=javabin=2 
HTTP/1.1{code}
And the very first request returns 400 Bad Request with replica 1 logging 
"Document is missing mandatory uniqueKey field: id" in the logs.

The funny thing is that when I execute the same request using POSTMAN (but with 
JSON instead of binary payload), it works! Am I doing something wrong here? I 
assume it's definitely something in the way of how the request is made...

UPDATE:

I have used local proxy in order to see the difference in these 2 requests sent 
by my application in order to understand what is different there. Looks like 
the only difference is content type. In case of cloud mode the payload for 
POSTing document is sent as "application/javabin" while in 

[jira] [Updated] (SOLR-9493) uniqueKey generation fails if content POSTed as "application/javabin".

[Yury Kartsev (JIRA)]

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

Yury Kartsev updated SOLR-9493:
---
Attachment: 400.png
200.png

> uniqueKey generation fails if content POSTed as "application/javabin".
> --
>
> Key: SOLR-9493
> URL: https://issues.apache.org/jira/browse/SOLR-9493
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yury Kartsev
> Attachments: 200.png, 400.png
>
>
> I have faced a weird issue when the same application code (using SolrJ) fails 
> indexing a document without a unique key (should be auto-generated by SOLR) 
> in SolrCloud and succeeds indexing it in standalone SOLR instance (or even in 
> cloud mode, but from web interface of one of the replicas). Difference is 
> obviously only between clients (CloudSolrClient vs HttpSolrClient) and SOLR 
> URLs (Zokeeper hostname+port vs standalone SOLR instance hostname and port). 
> Failure is seen as "org.apache.solr.client.solrj.SolrServerException: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
> Document is missing mandatory uniqueKey field: id".
> I am using SOLR 5.1. In cloud mode I have 1 shard and 3 replicas.
> After lot of debugging and investigation (see my [StackOverflow 
> post|http://stackoverflow.com/questions/39401792/uniquekey-generation-does-not-work-in-solrcloud-but-works-if-standalone])
>  I came to a conclusion that the difference in failing and succeeding calls 
> is simply content type of the POSTing requests. Local proxy clearly shows 
> that the request fails if content is sent as "application/javabin" (see 
> attached) and succeeds if content sent as "application/xml; charset=UTF-8"  
> (see attached).
> Would you be able to please assist?
> Thank you very much in advance!



--
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-9493) uniqueKey generation fails if content POSTed as "application/javabin".

[Yury Kartsev (JIRA)]

Yury Kartsev created SOLR-9493:
--

 Summary: uniqueKey generation fails if content POSTed as 
"application/javabin".
 Key: SOLR-9493
 URL: https://issues.apache.org/jira/browse/SOLR-9493
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Yury Kartsev


I have faced a weird issue when the same application code (using SolrJ) fails 
indexing a document without a unique key (should be auto-generated by SOLR) in 
SolrCloud and succeeds indexing it in standalone SOLR instance (or even in 
cloud mode, but from web interface of one of the replicas). Difference is 
obviously only between clients (CloudSolrClient vs HttpSolrClient) and SOLR 
URLs (Zokeeper hostname+port vs standalone SOLR instance hostname and port). 
Failure is seen as "org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Document 
is missing mandatory uniqueKey field: id".

I am using SOLR 5.1. In cloud mode I have 1 shard and 3 replicas.

After lot of debugging and investigation (see my [StackOverflow 
post|http://stackoverflow.com/questions/39401792/uniquekey-generation-does-not-work-in-solrcloud-but-works-if-standalone])
 I came to a conclusion that the difference in failing and succeeding calls is 
simply content type of the POSTing requests. Local proxy clearly shows that the 
request fails if content is sent as "application/javabin" (see attached) and 
succeeds if content sent as "application/xml; charset=UTF-8"  (see attached).

Would you be able to please assist?

Thank you very much in advance!



--
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-7440) Document skipping on large indexes is broken

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7440:
-

Another alternative would be to use Integer.compareUnsigned()

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



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

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

[jira] [Commented] (LUCENE-7440) Document skipping on large indexes is broken

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7440:


What a nice find!

I would rather we just use {{long[]}} here?  The added memory cost is minor, 
and I think understandable code is more important.

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



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

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

[jira] [Updated] (SOLR-9438) Shard split can lose data

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9438:

Attachment: SOLR-9438.patch

The test failure due to only one node remaining down was because sometimes the 
parent leader node itself is selected to host the new sub-shard replica. When 
we shutdown that node at the right time, the add replica call fails but the 
replica has already been created in the cluster state. Since the physical core 
doesn't actually exist, it will never recover and stay in down state.

Changes:
# The test now checks if all replicas actually exist as a core before we wait 
for recovery and for sub-shards to switch states.
# The split shard API puts sub-shards into recovery_failed state itself if the 
parent leader changes before any replicas can be created.

I've been beasting this test and so far everything looks good but I'll continue 
beasting for a little while more.

> Shard split can lose data
> -
>
> Key: SOLR-9438
> URL: https://issues.apache.org/jira/browse/SOLR-9438
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5.2, 6.1
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
>  Labels: difficulty-medium, impact-high
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9438-false-replication.log, 
> SOLR-9438-split-data-loss.log, SOLR-9438.patch, SOLR-9438.patch, 
> SOLR-9438.patch, SOLR-9438.patch, SOLR-9438.patch
>
>
> Solr’s shard split can lose documents if the parent/sub-shard leader is 
> killed (or crashes) between the time that the new sub-shard replica is 
> created and before it recovers. In such a case the slice has already been set 
> to ‘recovery’ state, the sub-shard replica comes up, finds that no other 
> replica is up, waits until the leader vote wait time and then proceeds to 
> become the leader as well as publish itself as active. Once that happens the 
> overseer seeing that all replicas of the sub-shard are now ‘active’, sets the 
> parent slice as ‘inactive’ and the new sub-shard as ‘active’.



--
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-9278) Possible deadlock in replication

[Michael Braun (JIRA)]

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

Michael Braun commented on SOLR-9278:
-

Is this possibly the same issue I reported as [SOLR-9470] or another deadlock?

> Possible deadlock in replication
> 
>
> Key: SOLR-9278
> URL: https://issues.apache.org/jira/browse/SOLR-9278
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: 6.1
> Environment: Linux
>Reporter: Xunlong
>  Labels: replication
> Fix For: master (7.0)
>
> Attachments: SOLR-9278.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> There is a bug in IndexFetcher for replication logic, it may cause deadlock 
> issue, and it's very easy to reproduce. If you change your solrconfig to keep 
> more than 1 commit points, this operation will causes 2 issues:
> 1. Slave has to download whole index directory of Master, instead of 
> incremental udpates only;
> 2. If you click "replicate now" button manually, this is cause deadlock, stop 
> both "indexFetcher" thread and "explicitFetcher" thread.
> The first issue is a design issue, can be worked around by keep only 1 commit 
> point. But the second issue can always happen if there is some file located 
> in slave's index directory, but can not be deleted by index delete policy 
> (due to permission issue etc), I have fixed this issue for my service, would 
> happy to contribute to Solr community to benefit others.



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

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_102) - Build # 1692 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1692/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
IOException occured when talking to server at: https://127.0.0.1:36140/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:36140/solr
at 
__randomizedtesting.SeedInfo.seed([A02E38E6F47D283A:1C404EF4502EAB40]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-9470) Deadlocked threads in recovery

[Michael Braun (JIRA)]

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

Michael Braun commented on SOLR-9470:
-

Dug more into this and only two threads are actually part of the core deadlock 
- 

"recoveryExecutor-3-thread-1-processing-n:x.x.x.166:8983_solr 
x:mycollection_shard1_replica2 s:shard1 c:mycollection r:core_node97":
{code}
- parking to wait for  <0x7fc1b0a97250> (a 
java.util.concurrent.locks.ReentrantLock$FairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at 
java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1804)
at 
org.apache.solr.handler.IndexFetcher.openNewSearcherAndUpdateCommitPoint(IndexFetcher.java:746)
at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:523)
at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:254)
at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:397)
{code}

It first acquires the iwLock ( 0x7fc1b0a96fe0) by this mechanism:
org.apache.solr.update.DefaultSolrCoreState.newIndexWriter(DefaultSolrCoreState.java
 210)
org.apache.solr.update.DirectUpdateHandler2.newIndexWriter(DirectUpdateHandler2.java
 698)
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java 520)


Then as you see from the stacktrace above, it's waiting on the 
openSearcherLock, which is held by the thread below:

"qtp1879034789-189":
{code}
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x7fc1b0a96fe0> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at 
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.tryLock(ReentrantReadWriteLock.java:871)
at 
org.apache.solr.update.DefaultSolrCoreState.lock(DefaultSolrCoreState.java:159)
at 
org.apache.solr.update.DefaultSolrCoreState.getIndexWriter(DefaultSolrCoreState.java:104)
at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1601)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1806)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1552)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1487)
at 
org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:115)
at 
org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:130)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:154)
{code}

It's already holding the openSearchLock (0x7fc1b0a97250) and wants the 
iwLock. It gets the openSearchLock by this mechanism:
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1804) is 
where it does the actual lock of openSearcher.lock, called by
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1552)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1487)
at 
org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:115)
at 
org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:130)

> Deadlocked threads in recovery
> --
>
> Key: SOLR-9470
> URL: https://issues.apache.org/jira/browse/SOLR-9470
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Michael Braun
> Attachments: solr-deadlock.txt
>
>
> Background: Booted up a cluster and replicas were in recovery. All replicas 
> recovered minus one, and it was hanging on HTTP requests. Issued shutdown and 
> solr would not shut down. Examined with JStack and found a deadlock had 
> occurred. The relevant thread information is attached. Some information has 
> been redacted as well (some custom URPs, IPs) from the stack traces.



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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeRapidAdds

Error Message:
1: soft wasn't fast enough

Stack Trace:
java.lang.AssertionError: 1: soft wasn't fast enough
at 
__randomizedtesting.SeedInfo.seed([7D6AE9BDCCFE6C3A:217F4784277C2D42]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeRapidAdds(SoftAutoCommitTest.java:322)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 10559 lines...]
   [junit4] Suite: org.apache.solr.update.SoftAutoCommitTest
   [junit4]   2> Creating dataDir: 

[jira] [Updated] (SOLR-9490) BoolField always returning false for non-DV fields?

[Dan Fox (JIRA)]

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

Dan Fox updated SOLR-9490:
--
Attachment: Solr9490.java

Hi, I think I've also run into this issue.   Here's a unit test that 
demonstrates it.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
> Attachments: Solr9490.java
>
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie edited comment on SOLR-9490 at 9/9/16 4:06 PM:


I've spotted that the error with the json response happens when there is more 
than 1 shard in the collection.

So toExternal() isn't being called when using a single shard and the json 
response writer, but it is used by the JavaBinCodec (via toObject() for 
BoolField) since javabin is used for communication between the shards?


was (Author: cjcowie):
I've spotted that the error with the json response happens when there is more 
than 1 shard in the collection.

So toExternal() isn't being called when using a single shard, I guess?

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-9492) Request status API returns a completed status even if the collection API call failed

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-9492:
---

 Summary: Request status API returns a completed status even if the 
collection API call failed
 Key: SOLR-9492
 URL: https://issues.apache.org/jira/browse/SOLR-9492
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Affects Versions: 6.2, 5.5.2
Reporter: Shalin Shekhar Mangar
 Fix For: master (7.0), 6.3


A failed split shard response is:
{code}
{success={127.0.0.1:43245_hfnp%2Fbq={responseHeader={status=0,QTime=2}},127.0.0.1:43245_hfnp%2Fbq={responseHeader={status=0,QTime=0}},127.0.0.1:43245_hfnp%2Fbq={responseHeader={status=0,QTime=0}},127.0.0.1:43245_hfnp%2Fbq={responseHeader={status=0,QTime=0}},127.0.0.1:43245_hfnp%2Fbq={responseHeader={status=0,QTime=0}},127.0.0.1:43245_hfnp%2Fbq={responseHeader={status=0,QTime=0}},127.0.0.1:43245_hfnp%2Fbq={responseHeader={status=0,QTime=0}},127.0.0.1:50948_hfnp%2Fbq={responseHeader={status=0,QTime=0}}},c32001ed-3bca-4ae0-baae-25a3c99e35e65883644576126044={responseHeader={status=0,QTime=0},STATUS=completed,Response=TaskId:
 c32001ed-3bca-4ae0-baae-25a3c99e35e65883644576126044 webapp=null 
path=/admin/cores 
params={async=c32001ed-3bca-4ae0-baae-25a3c99e35e65883644576126044=/admin/cores=conf1=collection1_shard1_0_replica1=CREATE=collection1=shard1_0=javabin=2}
 status=0 
QTime=2},c32001ed-3bca-4ae0-baae-25a3c99e35e65883647597130004={responseHeader={status=0,QTime=0},STATUS=completed,Response=TaskId:
 c32001ed-3bca-4ae0-baae-25a3c99e35e65883647597130004 webapp=null 
path=/admin/cores 
params={async=c32001ed-3bca-4ae0-baae-25a3c99e35e65883647597130004=/admin/cores=conf1=collection1_shard1_1_replica1=CREATE=collection1=shard1_1=javabin=2}
 status=0 
QTime=0},c32001ed-3bca-4ae0-baae-25a3c99e35e65883649607943904={responseHeader={status=0,QTime=0},STATUS=completed,Response=TaskId:
 c32001ed-3bca-4ae0-baae-25a3c99e35e65883649607943904 webapp=null 
path=/admin/cores 
params={nodeName=127.0.0.1:43245_hfnp%252Fbq=collection1_shard1_1_replica1=c32001ed-3bca-4ae0-baae-25a3c99e35e65883649607943904=/admin/cores=core_node6=PREPRECOVERY=true=active=true=javabin=2}
 status=0 
QTime=0},c32001ed-3bca-4ae0-baae-25a3c99e35e65883649612565003={responseHeader={status=0,QTime=0},STATUS=completed,Response=TaskId:
 c32001ed-3bca-4ae0-baae-25a3c99e35e65883649612565003 webapp=null 
path=/admin/cores 
params={core=collection1=c32001ed-3bca-4ae0-baae-25a3c99e35e65883649612565003=/admin/cores=SPLIT=collection1_shard1_0_replica1=collection1_shard1_1_replica1=javabin=2}
 status=0 
QTime=0},c32001ed-3bca-4ae0-baae-25a3c99e35e65883650618358632={responseHeader={status=0,QTime=0},STATUS=completed,Response=TaskId:
 c32001ed-3bca-4ae0-baae-25a3c99e35e65883650618358632 webapp=null 
path=/admin/cores 
params={async=c32001ed-3bca-4ae0-baae-25a3c99e35e65883650618358632=/admin/cores=collection1_shard1_1_replica1=REQUESTAPPLYUPDATES=javabin=2}
 status=0 
QTime=0},c32001ed-3bca-4ae0-baae-25a3c99e35e65883650636428900={responseHeader={status=0,QTime=0},STATUS=completed,Response=TaskId:
 c32001ed-3bca-4ae0-baae-25a3c99e35e65883650636428900 webapp=null 
path=/admin/cores 
params={async=c32001ed-3bca-4ae0-baae-25a3c99e35e65883650636428900=/admin/cores=conf1=collection1_shard1_0_replica0=CREATE=collection1=shard1_0=javabin=2}
 status=0 
QTime=0},failure={127.0.0.1:43245_hfnp%2Fbq=org.apache.solr.client.solrj.SolrServerException:IOException
 occured when talking to server at: http://127.0.0.1:43245/hfnp/bq},Operation 
splitshard caused exception:=org.apache.solr.common.SolrException: ADDREPLICA 
failed to create replica,exception={msg=ADDREPLICA failed to create 
replica,rspCode=500}}
{code}

Note the "failure" bit. The split shard couldn't add a replica. But when you 
use the request status API, it returns a "completed" status.

Apparently, completed doesn't mean it was successful! In any case, it is very 
misleading and makes it very hard to properly use the Collection APIs. We need 
more investigation to figure out what other Collection APIs might be affected.



--
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-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie commented on SOLR-9490:


I've spotted that the error with the json response happens when there is more 
than 1 shard in the collection.

So toExternal() isn't being called when using a single shard, I guess?

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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 # 158 - Still Unstable

[Apache Jenkins Server]

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

7 tests failed.
FAILED:  
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testBatchAddsWithDelete

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

Stack Trace:
java.lang.RuntimeException: Timeout waiting for CDCR replication to complete 
@source_collection:shard2
at 
__randomizedtesting.SeedInfo.seed([2148ACF3C2336A63:5652D5576A2A6B4F]:0)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForReplicationToComplete(BaseCdcrDistributedZkTest.java:794)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testBatchAddsWithDelete(CdcrReplicationDistributedZkTest.java:526)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Comment Edited] (SOLR-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie edited comment on SOLR-9490 at 9/9/16 3:24 PM:


Unfortunately I don't think that I personally can provide a unit test (without 
getting approval to do so).

However I can reproduce the error reliably just by deploying the cloud example 
and creating a document:

{noformat}
solr stop -all

rm -rf ../example/cloud
solr -e cloud -noprompt
curl http://localhost:8983/solr/gettingstarted/update -d "[ {\"f_b\": true, 
\"id\": \"1\" }, {\"f_b\": false, \"id\": \"2\" }]"
{noformat}
http://localhost:8983/solr/gettingstarted/select?facet.field=f_b=on=on=*:*=json

{noformat}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":78,
"params":{
  "q":"*:*",
  "facet.field":"f_b",
  "indent":"on",
  "facet":"on",
  "wt":"json"}},
  "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
  {
"f_b":false,
"id":"1",
"_version_":1545007494796935168},
  {
"f_b":false,
"id":"2",
"_version_":1545007494796935168}]
  },
  "facet_counts":{
"facet_queries":{},
"facet_fields":{
  "f_b":[
"false",1,
"true",1]},
"facet_ranges":{},
"facet_intervals":{},
"facet_heatmaps":{}}}
{noformat}

The strange thing however, is that when I try and reproduce the problem with 
our actual configuration and test data which wrongly returns false on the 
javabin response, the json response returns the correct response. It appears in 
that case that {{toExternal()}} isn't being called at all. I don't know enough 
about the code to know why/how it would be bypassing {{toExternal()}} in that 
case though.


was (Author: cjcowie):
Unfortunately I don't think that I personally can provide a unit test (without 
getting approval to do so).

However I can reproduce the error reliably just by deploying the cloud example 
and creating a document:

{noformat}
solr stop -all

rm -rf ../example/cloud
solr -e cloud -noprompt
curl http://localhost:8983/solr/gettingstarted/update -d "[ {\"f_b\": true, 
\"id\": \"1\" }, {\"f_b\": false, \"id\": \"2\" }]"
{noformat}
http://localhost:8983/solr/gettingstarted/select?facet.field=f_b=on=on=*:*=json

{noformat}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":78,
"params":{
  "q":"*:*",
  "facet.field":"f_b",
  "indent":"on",
  "facet":"on",
  "wt":"json"}},
  "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
  {
"f_b":false,
"id":"1",
"_version_":1545007494796935168},
  {
"f_b":false,
"id":"2",
"_version_":1545007494796935168}]
  },
  "facet_counts":{
"facet_queries":{},
"facet_fields":{
  "f_b":[
"false",1,
"true",1]},
"facet_ranges":{},
"facet_intervals":{},
"facet_heatmaps":{}}}
{noformat}

The strange thing however, is that when I try and reproduce the problem with 
our actual configuration and test data which wrongly returns false on the 
javabin response, I struggle to get the json response to produce the wrong 
result as above. It appears in that case that {{toExternal()}} isn't being 
called at all. I don't know enough about the code to know why/how it would be 
bypassing {{toExternal()}} in that case though.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> 

[jira] [Comment Edited] (SOLR-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie edited comment on SOLR-9490 at 9/9/16 3:24 PM:


Unfortunately I don't think that I personally can provide a unit test (without 
getting approval to do so).

However I can reproduce the error reliably just by deploying the cloud example 
and creating a document:

{noformat}
solr stop -all

rm -rf ../example/cloud
solr -e cloud -noprompt
curl http://localhost:8983/solr/gettingstarted/update -d "[ {\"f_b\": true, 
\"id\": \"1\" }, {\"f_b\": false, \"id\": \"2\" }]"
{noformat}
http://localhost:8983/solr/gettingstarted/select?facet.field=f_b=on=on=*:*=json

{noformat}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":78,
"params":{
  "q":"*:*",
  "facet.field":"f_b",
  "indent":"on",
  "facet":"on",
  "wt":"json"}},
  "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
  {
"f_b":false,
"id":"1",
"_version_":1545007494796935168},
  {
"f_b":false,
"id":"2",
"_version_":1545007494796935168}]
  },
  "facet_counts":{
"facet_queries":{},
"facet_fields":{
  "f_b":[
"false",1,
"true",1]},
"facet_ranges":{},
"facet_intervals":{},
"facet_heatmaps":{}}}
{noformat}

The strange thing however, is that when I try and reproduce the problem with 
our actual configuration and test data which wrongly returns false on the 
javabin response, I struggle to get the json response to produce the wrong 
result as above. It appears in that case that {{toExternal()}} isn't being 
called at all. I don't know enough about the code to know why/how it would be 
bypassing {{toExternal()}} in that case though.


was (Author: cjcowie):
Unfortunately I don't think that I personally can provide a unit test (without 
getting approval to do so).

However I can reproduce the error reliably just by deploying the cloud example 
and creating a document:

{noformat}
solr stop -all

rm -rf ../example/cloud
solr -e cloud -noprompt
curl http://localhost:8983/solr/gettingstarted/update -d "[ {\"f_b\": true, 
\"id\": \"1\" }, {\"f_b\": false, \"id\": \"2\" }]"
{noformat}
http://localhost:8983/solr/gettingstarted/select?facet.field=f_b=on=on=*:*=json

{noformat}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":78,
"params":{
  "q":"*:*",
  "facet.field":"f_b",
  "indent":"on",
  "facet":"on",
  "wt":"json"}},
  "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
  {
"f_b":false,
"id":"1",
"_version_":1545007494796935168},
  {
"f_b":false,
"id":"2",
"_version_":1545007494796935168}]
  },
  "facet_counts":{
"facet_queries":{},
"facet_fields":{
  "f_b":[
"false",1,
"true",1]},
"facet_ranges":{},
"facet_intervals":{},
"facet_heatmaps":{}}}
{noformat}

The strange thing however, is that when I try and reproduce the problem with 
our actual configuration and test data which always returns false on the 
javabin response, I struggle to get the json response to produce the wrong 
result as above. It appears in that case that {{toExternal()}} isn't being 
called at all. I don't know enough about the code to know why/how it would be 
bypassing {{toExternal()}} in that case though.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it 

[jira] [Comment Edited] (SOLR-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie edited comment on SOLR-9490 at 9/9/16 3:23 PM:


Unfortunately I don't think that I personally can provide a unit test (without 
getting approval to do so).

However I can reproduce the error reliably just by deploying the cloud example 
and creating a document:

{noformat}
solr stop -all

rm -rf ../example/cloud
solr -e cloud -noprompt
curl http://localhost:8983/solr/gettingstarted/update -d "[ {\"f_b\": true, 
\"id\": \"1\" }, {\"f_b\": false, \"id\": \"2\" }]"
{noformat}
http://localhost:8983/solr/gettingstarted/select?facet.field=f_b=on=on=*:*=json

{noformat}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":78,
"params":{
  "q":"*:*",
  "facet.field":"f_b",
  "indent":"on",
  "facet":"on",
  "wt":"json"}},
  "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
  {
"f_b":false,
"id":"1",
"_version_":1545007494796935168},
  {
"f_b":false,
"id":"2",
"_version_":1545007494796935168}]
  },
  "facet_counts":{
"facet_queries":{},
"facet_fields":{
  "f_b":[
"false",1,
"true",1]},
"facet_ranges":{},
"facet_intervals":{},
"facet_heatmaps":{}}}
{noformat}

The strange thing however, is that when I try and reproduce the problem with 
our actual configuration and test data which always returns false on the 
javabin response, I struggle to get the json response to produce the wrong 
result as above. It appears in that case that {{toExternal()}} isn't being 
called at all. I don't know enough about the code to know why/how it would be 
bypassing {{toExternal()}} in that case though.


was (Author: cjcowie):
Unfortunately I don't think that I personally can provide a unit test (without 
getting approval to do so).

However I can reproduce the error reliably just by deploying the cloud example 
and creating a document:

{noformat}
solr stop -all

rm -rf ../example/cloud
solr -e cloud -noprompt
curl http://localhost:8983/solr/gettingstarted/update -d "[ {\"f_b\": true, 
\"id\": \"1\" }, {\"f_b\": false, \"id\": \"2\" }]"
{noformat}
http://localhost:8983/solr/gettingstarted/select?facet.field=f_b=on=on=*:*=json

{noformat}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":78,
"params":{
  "q":"*:*",
  "facet.field":"f_b",
  "indent":"on",
  "facet":"on",
  "wt":"json"}},
  "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
  {
"f_b":false,
"id":"1",
"_version_":1545007494796935168},
  {
"f_b":false,
"id":"2",
"_version_":1545007494796935168}]
  },
  "facet_counts":{
"facet_queries":{},
"facet_fields":{
  "f_b":[
"false",1,
"true",1]},
"facet_ranges":{},
"facet_intervals":{},
"facet_heatmaps":{}}}
{noformat}

The strange thing however, is that when I try and reproduce the problem with 
our actual configuration and test data which fails on the javabin response, I 
struggle to get the json response to produce the wrong result as above. It 
appears in that case that {{toExternal()}} isn't being called at all. I don't 
know enough about the code to know why/how it would be bypassing 
{{toExternal()}} in that case though.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? 

[jira] [Comment Edited] (SOLR-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie edited comment on SOLR-9490 at 9/9/16 3:21 PM:


Unfortunately I don't think that I personally can provide a unit test (without 
getting approval to do so).

However I can reproduce the error reliably just by deploying the cloud example 
and creating a document:

{noformat}
solr stop -all

rm -rf ../example/cloud
solr -e cloud -noprompt
curl http://localhost:8983/solr/gettingstarted/update -d "[ {\"f_b\": true, 
\"id\": \"1\" }, {\"f_b\": false, \"id\": \"2\" }]"
{noformat}
http://localhost:8983/solr/gettingstarted/select?facet.field=f_b=on=on=*:*=json

{noformat}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":78,
"params":{
  "q":"*:*",
  "facet.field":"f_b",
  "indent":"on",
  "facet":"on",
  "wt":"json"}},
  "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
  {
"f_b":false,
"id":"1",
"_version_":1545007494796935168},
  {
"f_b":false,
"id":"2",
"_version_":1545007494796935168}]
  },
  "facet_counts":{
"facet_queries":{},
"facet_fields":{
  "f_b":[
"false",1,
"true",1]},
"facet_ranges":{},
"facet_intervals":{},
"facet_heatmaps":{}}}
{noformat}

The strange thing however, is that when I try and reproduce the problem with 
our actual configuration and test data which fails on the javabin response, I 
struggle to get the json response to produce the wrong result as above. It 
appears in that case that {{toExternal()}} isn't being called at all. I don't 
know enough about the code to know why/how it would be bypassing 
{{toExternal()}} in that case though.


was (Author: cjcowie):
Unfortunately I don't think that I personally can provide a unit test (without 
getting approval to do so).

However I can reproduce the error reliably just by deploying the cloud example 
and creating a document:

{noformat}
solr stop -all

rm -rf ../example/cloud
solr -e cloud -noprompt
curl http://localhost:8983/solr/gettingstarted/update -d "[ {\"f_b\": true, 
\"id\": \"1\" }, {\"f_b\": false, \"id\": \"2\" }]"
{noformat}
http://localhost:8983/solr/gettingstarted/select?facet.field=f_b=on=on=*:*=json

{noformat}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":78,
"params":{
  "q":"*:*",
  "facet.field":"f_b",
  "indent":"on",
  "facet":"on",
  "wt":"json"}},
  "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
  {
"f_b":false,
"id":"1",
"_version_":1545007494796935168},
  {
"f_b":false,
"id":"2",
"_version_":1545007494796935168}]
  },
  "facet_counts":{
"facet_queries":{},
"facet_fields":{
  "f_b":[
"false",1,
"true",1]},
"facet_ranges":{},
"facet_intervals":{},
"facet_heatmaps":{}}}
{noformat}

The strange thing however, is that when I try and reproduce the problem with 
our actual configuration and test data which fails on the javabin response, I 
struggle to get the json response to produce the wrong result as above. It 
appears in that case that {code}toExternal(){code} isn't being called at all. I 
don't know enough about the code to know why/how it would be bypassing 
{code}toExternal(){code} in that case though.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? 

[jira] [Commented] (SOLR-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie commented on SOLR-9490:


Unfortunately I don't think that I personally can provide a unit test (without 
getting approval to do so).

However I can reproduce the error reliably just by deploying the cloud example 
and creating a document:

{noformat}
solr stop -all

rm -rf ../example/cloud
solr -e cloud -noprompt
curl http://localhost:8983/solr/gettingstarted/update -d "[ {\"f_b\": true, 
\"id\": \"1\" }, {\"f_b\": false, \"id\": \"2\" }]"
{noformat}
http://localhost:8983/solr/gettingstarted/select?facet.field=f_b=on=on=*:*=json

{noformat}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":78,
"params":{
  "q":"*:*",
  "facet.field":"f_b",
  "indent":"on",
  "facet":"on",
  "wt":"json"}},
  "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
  {
"f_b":false,
"id":"1",
"_version_":1545007494796935168},
  {
"f_b":false,
"id":"2",
"_version_":1545007494796935168}]
  },
  "facet_counts":{
"facet_queries":{},
"facet_fields":{
  "f_b":[
"false",1,
"true",1]},
"facet_ranges":{},
"facet_intervals":{},
"facet_heatmaps":{}}}
{noformat}

The strange thing however, is that when I try and reproduce the problem with 
our actual configuration and test data which fails on the javabin response, I 
struggle to get the json response to produce the wrong result as above. It 
appears in that case that {code}toExternal(){code} isn't being called at all. I 
don't know enough about the code to know why/how it would be bypassing 
{code}toExternal(){code} in that case though.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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: Release Solr 5.5.3

[David Smiley]

Anhum,
Minutes ago I went and committed
https://issues.apache.org/jira/browse/LUCENE-7417 to master, branch_6x,
branch_5x, and branch_5_5.  While on both the v5 branches, I noticed the
last 5.5.x was specifically 5.5.2 so I went and added this under a new
5.5.3.   That is now committed.  Then the realization hits me that you're
doing a 5.5.3 release and it just passed a vote  So I guess I should change
those entries to be 5.5.4 and probably also add a blank 5.5.3 section so
it's clear there were not additions in 5.5.3 for Lucene?  BTW I think this
bug is "minor" IMO.
~ David

On Thu, Sep 8, 2016 at 1:29 PM Anshum Gupta  wrote:

> The release notes (draft) can be found here:
>
> Lucene: https://wiki.apache.org/lucene-java/ReleaseNote553
> Solr: https://wiki.apache.org/solr/ReleaseNote553
>
> Please feel free to edit/fix it.
>
> -Anshum
>
> On Wed, Jul 20, 2016 at 1:35 PM David Smiley 
> wrote:
>
>> Okay.  BTW SOLR-9290 isn't "Just" high indexing rates, but it's for those
>> using SSL too -- correct me if I'm wrong.  We don't want to raise alarm
>> bells too loudly :-)
>>
>> On Wed, Jul 20, 2016 at 4:18 PM Anshum Gupta 
>> wrote:
>>
>>> Hi,
>>>
>>> With SOLR-9290 fixed, I think it calls for a bug fix release as it
>>> impacts all users with high indexing rates.
>>>
>>> If someone else wants to work on the release, I am fine with it else,
>>> I'll be happy to be the RM and cut an RC a week from now.
>>>
>>> --
>>> Anshum Gupta
>>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

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

[Ishan Chattopadhyaya (JIRA)]

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

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

Updated patch. Fixes the nocommits, test for reordered DBQs (which now can 
potentially throw a replica into LIR).
There are occasional failures with the TestStressInPlaceUpdates test, that are 
basically due to: "ClusterState says we are the leader, but locally we don't 
think so. Request came from null". I'm looking into them.

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: DUP.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.62D328FA1DEA57FD.fail2.txt, 
> hoss.62D328FA1DEA57FD.fail3.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



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

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

[jira] [Commented] (LUCENE-7417) Highlighting fails for MultiPhraseQuery's with one clause

[ASF subversion and git services (JIRA)]

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

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

Commit 7350d14a9f8a2bedf07d8ae7b89cf67884ca879e in lucene-solr's branch 
refs/heads/branch_5_5 from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7350d14 ]

LUCENE-7417: Highlighter WSTE didn't handle single-term MultiPhraseQuery.
Also updated to Java 5 for-each in this method.

(cherry picked from commit 9a8ff64)


> Highlighting fails for MultiPhraseQuery's with one clause
> -
>
> Key: LUCENE-7417
> URL: https://issues.apache.org/jira/browse/LUCENE-7417
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.2.1, 5.x, 5.5.2
>Reporter: Thomas Kappler
>Assignee: David Smiley
> Attachments: multiphrasequery_singleclause_highlighting.patch
>
>
> This bug is the same issue as LUCENE-7231, just for MultiPhraseQuery instead 
> of PhraseQuery. The fix is the same as well. To reproduce, change the test 
> that was committed for LUCENE-7231 to use a MultiPhraseQuery. It results in 
> the same error
> {{java.lang.IllegalArgumentException: Less than 2 subSpans.size():1}}
> I have a patch including a test against branch_5.x, it just needs to go 
> through legal before I can post it.



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

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

[jira] [Commented] (LUCENE-7440) Document skipping on large indexes is broken

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7440:
---

Fix with negative check looks fine to me, this should be cheap. I'd suggest 
that [~mikemccand] also looks into it, he knows this code better.

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



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

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

[jira] [Resolved] (LUCENE-7436) MinHashFilter has package-local constructor and constants

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-7436.

   Resolution: Fixed
Fix Version/s: 6.3
   master (7.0)

Thank you [~softwaredoug]!

> MinHashFilter has package-local constructor and constants
> -
>
> Key: LUCENE-7436
> URL: https://issues.apache.org/jira/browse/LUCENE-7436
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.2
>Reporter: Doug Turnbull
>Priority: Minor
> Fix For: master (7.0), 6.3
>
>
> Trying to use the MinHashFilter outside of Lucene/Solr. Was it intentional 
> that the constructor and useful defaults are package-private? Seems like an 
> oversight to me, correct me if I'm wrong.



--
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-7436) MinHashFilter has package-local constructor and constants

[ASF subversion and git services (JIRA)]

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

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

Commit 7834fc1d5d5e328681c9b69514176641d95447c9 in lucene-solr's branch 
refs/heads/branch_6x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7834fc1 ]

LUCENE-7436: make constructor and default settings public for MinMashFilter


> MinHashFilter has package-local constructor and constants
> -
>
> Key: LUCENE-7436
> URL: https://issues.apache.org/jira/browse/LUCENE-7436
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.2
>Reporter: Doug Turnbull
>Priority: Minor
>
> Trying to use the MinHashFilter outside of Lucene/Solr. Was it intentional 
> that the constructor and useful defaults are package-private? Seems like an 
> oversight to me, correct me if I'm wrong.



--
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-7436) MinHashFilter has package-local constructor and constants

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7436: make constructor and default settings public for MinMashFilter


> MinHashFilter has package-local constructor and constants
> -
>
> Key: LUCENE-7436
> URL: https://issues.apache.org/jira/browse/LUCENE-7436
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.2
>Reporter: Doug Turnbull
>Priority: Minor
>
> Trying to use the MinHashFilter outside of Lucene/Solr. Was it intentional 
> that the constructor and useful defaults are package-private? Seems like an 
> oversight to me, correct me if I'm wrong.



--
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-7441) Invalid results on full-text search with a combination of numbers and dots in research terms

[Erick Erickson (JIRA)]

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

Erick Erickson resolved LUCENE-7441.

Resolution: Invalid

Please raise questions like this on the user's list, we try to reserve JIRAs 
for known bugs/enhancements rather than usage questions. The user's list has 
many more people looking at it so in all probability you'll also get your 
answers faster.

Please don't think that I'm unwilling to help ... it just needs to happen in 
the correct place.

See the solr-u...@lucene.apache.org mailing list, here: 
http://lucene.apache.org/solr/resources.html#community


> Invalid results on full-text search with a combination of numbers and dots in 
> research terms
> 
>
> Key: LUCENE-7441
> URL: https://issues.apache.org/jira/browse/LUCENE-7441
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.3.1
> Environment: OS : Windows 7
> Platform : DMS web soft 
>Reporter: Efalia
> Fix For: 4.3.1
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> I have no results on full-text searching with a combination of numbers and 
> dots in research terms (example : 304.411)
> Does Lucene core (version 4.1.3) have limits or does I have missing 
> parameters ?



--
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-7417) Highlighting fails for MultiPhraseQuery's with one clause

[ASF subversion and git services (JIRA)]

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

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

Commit 9a8ff64260102702b293b87de6914e438f439c31 in lucene-solr's branch 
refs/heads/branch_5x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9a8ff64 ]

LUCENE-7417: Highlighter WSTE didn't handle single-term MultiPhraseQuery.
Also updated to Java 5 for-each in this method.

(cherry picked from commit 514bb1b)


> Highlighting fails for MultiPhraseQuery's with one clause
> -
>
> Key: LUCENE-7417
> URL: https://issues.apache.org/jira/browse/LUCENE-7417
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.2.1, 5.x, 5.5.2
>Reporter: Thomas Kappler
>Assignee: David Smiley
> Attachments: multiphrasequery_singleclause_highlighting.patch
>
>
> This bug is the same issue as LUCENE-7231, just for MultiPhraseQuery instead 
> of PhraseQuery. The fix is the same as well. To reproduce, change the test 
> that was committed for LUCENE-7231 to use a MultiPhraseQuery. It results in 
> the same error
> {{java.lang.IllegalArgumentException: Less than 2 subSpans.size():1}}
> I have a patch including a test against branch_5.x, it just needs to go 
> through legal before I can post it.



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

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

[jira] [Commented] (SOLR-9490) BoolField always returning false for non-DV fields?

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9490:
--

Hmmm, would it be at all possible to provide a unit test illustrating this? 
It's _really_ helpful so we actually do the same thing.

Then we can incorporate that test in the final patch and be sure the problem 
you;'re seeing is actually fixed for now and into the future.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie edited comment on SOLR-9490 at 9/9/16 2:37 PM:


-ignore this-


was (Author: cjcowie):
-Well, the version seems to the reason for the discrepancy between what we are 
seeing. The schema was version 1.5. With 1.6, the json response returns the 
correct value, however the javabin still returns false. (This is with new 
indexes in both cases, not upgraded.)-


Edit: Actually, something else seems to be going on here. Booleans on 1.5 are 
returning true for me again. I'm going to have to look at it more closely


Changing toExternal() to fallback to its original behaviour fixes javabin for 
me.

I did observe some strange behaviour where having one boolean field with 
docValues enabled appeared to fix all the other boolean fields, regardless of 
whether they have docValues enabled, which is quite puzzling, so I may be 
mistaken on that. I'll try and have another look at it.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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] [Issue Comment Deleted] (SOLR-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie updated SOLR-9490:
---
Comment: was deleted

(was: -ignore this-)

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-7417) Highlighting fails for MultiPhraseQuery's with one clause

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7417: Highlighter WSTE didn't handle single-term MultiPhraseQuery.
Also updated to Java 5 for-each in this method.

(cherry picked from commit 3966f99)


> Highlighting fails for MultiPhraseQuery's with one clause
> -
>
> Key: LUCENE-7417
> URL: https://issues.apache.org/jira/browse/LUCENE-7417
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.2.1, 5.x, 5.5.2
>Reporter: Thomas Kappler
>Assignee: David Smiley
> Attachments: multiphrasequery_singleclause_highlighting.patch
>
>
> This bug is the same issue as LUCENE-7231, just for MultiPhraseQuery instead 
> of PhraseQuery. The fix is the same as well. To reproduce, change the test 
> that was committed for LUCENE-7231 to use a MultiPhraseQuery. It results in 
> the same error
> {{java.lang.IllegalArgumentException: Less than 2 subSpans.size():1}}
> I have a patch including a test against branch_5.x, it just needs to go 
> through legal before I can post it.



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

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

[jira] [Comment Edited] (SOLR-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie edited comment on SOLR-9490 at 9/9/16 2:27 PM:


-Well, the version seems to the reason for the discrepancy between what we are 
seeing. The schema was version 1.5. With 1.6, the json response returns the 
correct value, however the javabin still returns false. (This is with new 
indexes in both cases, not upgraded.)-


Edit: Actually, something else seems to be going on here. Booleans on 1.5 are 
returning true for me again. I'm going to have to look at it more closely


Changing toExternal() to fallback to its original behaviour fixes javabin for 
me.

I did observe some strange behaviour where having one boolean field with 
docValues enabled appeared to fix all the other boolean fields, regardless of 
whether they have docValues enabled, which is quite puzzling, so I may be 
mistaken on that. I'll try and have another look at it.


was (Author: cjcowie):
Well, the version seems to the reason for the discrepancy between what we are 
seeing. The schema was version 1.5. With 1.6, the json response returns the 
correct value, however the javabin still returns false. (This is with new 
indexes in both cases, not upgraded.)

Changing toExternal() to fallback to its original behaviour fixes javabin for 
me.

I did observe some strange behaviour where having one boolean field with 
docValues enabled appeared to fix all the other boolean fields, regardless of 
whether they have docValues enabled, which is quite puzzling, so I may be 
mistaken on that. I'll try and have another look at it.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-7436) MinHashFilter has package-local constructor and constants

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7436:


Thanks; I don't think this was intentional.  I'll commit shortly.

> MinHashFilter has package-local constructor and constants
> -
>
> Key: LUCENE-7436
> URL: https://issues.apache.org/jira/browse/LUCENE-7436
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.2
>Reporter: Doug Turnbull
>Priority: Minor
>
> Trying to use the MinHashFilter outside of Lucene/Solr. Was it intentional 
> that the constructor and useful defaults are package-private? Seems like an 
> oversight to me, correct me if I'm wrong.



--
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-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie edited comment on SOLR-9490 at 9/9/16 2:17 PM:


Well, the version seems to the reason for the discrepancy between what we are 
seeing. The schema was version 1.5. With 1.6, the json response returns the 
correct value, however the javabin still returns false. (This is with new 
indexes in both cases, not upgraded.)

Changing toExternal() to fallback to its original behaviour fixes javabin for 
me.

I did observe some strange behaviour where having one boolean field with 
docValues enabled appeared to fix all the other boolean fields, regardless of 
whether they have docValues enabled, which is quite puzzling, so I may be 
mistaken on that. I'll try and have another look at it.


was (Author: cjcowie):
Well, the version seems to the reason for the discrepancy between what we are 
seeing. The schema was version 1.5. With 1.6, the json response returns the 
correct value, however the javabin still returns false.

Changing toExternal() to fallback to its original behaviour fixes javabin for 
me.

I did observe some strange behaviour where having one boolean field with 
docValues enabled appeared to fix all the other boolean fields, regardless of 
whether they have docValues enabled, which is quite puzzling, so I may be 
mistaken on that. I'll try and have another look at it.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie edited comment on SOLR-9490 at 9/9/16 2:15 PM:


Well, the version seems to the reason for the discrepancy between what we are 
seeing. The schema was version 1.5. With 1.6, the json response returns the 
correct value, however the javabin still returns false.

Changing toExternal() to fallback to its original behaviour fixes javabin for 
me.

I did observe some strange behaviour where having one boolean field with 
docValues enabled appeared to fix all the other boolean fields, regardless of 
whether they have docValues enabled, which is quite puzzling, so I may be 
mistaken on that. I'll try and have another look at it.


was (Author: cjcowie):
Well, the version seems to the reason for the discrepancy between what we are 
seeing. The schema was version 1.5. With 1.6, the json response returns the 
correct value, however the javabin still returns false.

Changing toExternal() to fallback to its original behaviour fixes javabin for 
me.

I did observe some strange behaviour where having a one boolean field with 
docValues enabled appeared to fix all the other boolean fields, regardless of 
whether they have docValues enabled, which is quite puzzling, so I may be 
mistaken on that. I'll try and have another look at it.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-9490) BoolField always returning false for non-DV fields?

[Colvin Cowie (JIRA)]

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

Colvin Cowie commented on SOLR-9490:


Well, the version seems to the reason for the discrepancy between what we are 
seeing. The schema was version 1.5. With 1.6, the json response returns the 
correct value, however the javabin still returns false.

Changing toExternal() to fallback to its original behaviour fixes javabin for 
me.

I did observe some strange behaviour where having a one boolean field with 
docValues enabled appeared to fix all the other boolean fields, regardless of 
whether they have docValues enabled, which is quite puzzling, so I may be 
mistaken on that. I'll try and have another look at it.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



--
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-7440) Document skipping on large indexes is broken

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on LUCENE-7440:
--

Regarding the 1.8B docs number... at least in my tests I saw the top-level skip 
distance of ~268M w/ the default codec.  Subtracting this from MAX_INT gives 
around 1.8B, which is around the number I saw prior to the overflow.  To hit 
the bug, one also needs to be doing *large* skips toward the end of the index 
as well, in order to use the top level(s) of the multi-level skip list.  Having 
a conjunction query of a highly unique term (or clause) in conjunction with a 
common term has a good chance of triggering (example:  
+timestamp:39520928456494 +doctype:common)


> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



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

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

[jira] [Commented] (LUCENE-7417) Highlighting fails for MultiPhraseQuery's with one clause

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7417: Highlighter WSTE didn't handle single-term MultiPhraseQuery.
Also updated to Java 5 for-each in this method.


> Highlighting fails for MultiPhraseQuery's with one clause
> -
>
> Key: LUCENE-7417
> URL: https://issues.apache.org/jira/browse/LUCENE-7417
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.2.1, 5.x, 5.5.2
>Reporter: Thomas Kappler
>Assignee: David Smiley
> Attachments: multiphrasequery_singleclause_highlighting.patch
>
>
> This bug is the same issue as LUCENE-7231, just for MultiPhraseQuery instead 
> of PhraseQuery. The fix is the same as well. To reproduce, change the test 
> that was committed for LUCENE-7231 to use a MultiPhraseQuery. It results in 
> the same error
> {{java.lang.IllegalArgumentException: Less than 2 subSpans.size():1}}
> I have a patch including a test against branch_5.x, it just needs to go 
> through legal before I can post it.



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

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

[jira] [Commented] (LUCENE-7440) Document skipping on large indexes is broken

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7440:
---

Nice findings. A really old bug!

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



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

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

[jira] [Updated] (LUCENE-7440) Document skipping on large indexes is broken

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated LUCENE-7440:
-
Affects Version/s: (was: master (7.0))
   2.2

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



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

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

[jira] [Updated] (LUCENE-7440) Document skipping on large indexes is broken

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated LUCENE-7440:
-
Attachment: LUCENE-7440.patch

Here's a patch, and a test that fails w/o the patch (takes 30min on my old 
linux box).

There are two obvious ways to fix:
- use long[] instead of int[] for numSkipped
- check numSkipped for overflow and compensate where used

I used the latter in this patch since it avoids increasing the memory footprint 
and there was only a single place to check for overflow.  Subsequent uses of 
the overflowed value were already automatically corrected by subtracting the 
same value that caused the overflow in the first place.

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



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

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

[jira] [Updated] (LUCENE-7441) Invalid results on full-text search with a combination of numbers and dots in research terms

[Efalia (JIRA)]

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

Efalia updated LUCENE-7441:
---
Summary: Invalid results on full-text search with a combination of numbers 
and dots in research terms  (was: Can we )

> Invalid results on full-text search with a combination of numbers and dots in 
> research terms
> 
>
> Key: LUCENE-7441
> URL: https://issues.apache.org/jira/browse/LUCENE-7441
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.3.1
> Environment: OS : Windows 7
> Platform : DMS web soft 
>Reporter: Efalia
> Fix For: 4.3.1
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> I have no results on full-text searching with a combination of numbers and 
> dots in research terms (example : 304.411)
> Does Lucene core (version 4.1.3) have limits or does I have missing 
> parameters ?



--
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-7441) Can we

[Efalia (JIRA)]

Efalia created LUCENE-7441:
--

 Summary: Can we 
 Key: LUCENE-7441
 URL: https://issues.apache.org/jira/browse/LUCENE-7441
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.3.1
 Environment: OS : Windows 7
Platform : DMS web soft 
Reporter: Efalia
 Fix For: 4.3.1


I have no results on full-text searching with a combination of numbers and dots 
in research terms (example : 304.411)

Does Lucene core (version 4.1.3) have limits or does I have missing parameters ?



--
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-7440) Document skipping on large indexes is broken

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated LUCENE-7440:
-
Description: 
Large skips on large indexes fail.
Anything that uses skips (such as a boolean query, filtered queries, faceted 
queries, join queries, etc) can trigger this bug on a sufficiently large index.

The bug is a numeric overflow in MultiLevelSkipList that has been present since 
inception (Lucene 2.2).  It may not manifest until one has a single segment 
with more than ~1.8B documents, and a large skip is performed on that segment.

Typical stack trace on Lucene7-dev:
{code}
java.lang.ArrayIndexOutOfBoundsException: 110
at 
org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
at 
org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
at 
org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
at 
org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
at 
org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
at YCS_skip7$1.testSkip(YCS_skip7.java:307)
{code}

Typical stack trace on Lucene4.10.3:
{code}
6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
null:java.lang.ArrayIndexOutOfBoundsException: 75
 at 
org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
 at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
 at 
org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
 at 
org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
 at 
org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
 at 
org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
 at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
[...]
 at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
[...]
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
{code}

  was:
Large skips on large indexes fail.
Anything that uses skips (such as a boolean query, filtered queries, faceted 
queries, join queries, etc) can trigger this bug on a sufficiently large index.

The bug is a numeric overflow in MultiLevelSkipList that has been present since 
inception (Lucene 2.2).  It may not manifest until one has a single segment 
with more than 1.8B documents, and a large skip is performed on that segment.

Typical stack trace on Lucene7-dev:
{code}
java.lang.ArrayIndexOutOfBoundsException: 110
at 
org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
at 
org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
at 
org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
at 
org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
at 
org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
at YCS_skip7$1.testSkip(YCS_skip7.java:307)
{code}

Typical stack trace on Lucene4.10.3:
{code}
6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
null:java.lang.ArrayIndexOutOfBoundsException: 75
 at 
org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
 at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
 at 
org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
 at 
org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
 at 
org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
 at 
org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
 at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
[...]
 at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
[...]
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
{code}


> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Yonik Seeley

[jira] [Updated] (LUCENE-7440) Document skipping on large indexes is broken

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated LUCENE-7440:
-
Description: 
Large skips on large indexes fail.
Anything that uses skips (such as a boolean query, filtered queries, faceted 
queries, join queries, etc) can trigger this bug on a sufficiently large index.

The bug is a numeric overflow in MultiLevelSkipList that has been present since 
inception (Lucene 2.2).  It may not manifest until one has a single segment 
with more than 1.8B documents, and a large skip is performed on that segment.

Typical stack trace on Lucene7-dev:
{code}
java.lang.ArrayIndexOutOfBoundsException: 110
at 
org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
at 
org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
at 
org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
at 
org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
at 
org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
at YCS_skip7$1.testSkip(YCS_skip7.java:307)
{code}

Typical stack trace on Lucene4.10.3:
{code}
6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
null:java.lang.ArrayIndexOutOfBoundsException: 75
 at 
org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
 at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
 at 
org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
 at 
org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
 at 
org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
 at 
org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
 at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
[...]
 at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
[...]
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
{code}

  was:
Large skips on large indexes fail.
Anything that uses skips (such as a boolean query, filtered queries, faceted 
queries, join queries, etc) can trigger this bug on a sufficiently large index.



> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Yonik Seeley
>Priority: Critical
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than 1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> 

[jira] [Updated] (SOLR-9365) Reduce noise in solr logs during graceful shutdown

[Cao Manh Dat (JIRA)]

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

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

First patch for this issue, It remove some boilerplate error when graceful 
shutdown solr cluster :
- RejectedExecutionException when watcher being executed after the zk callback 
is shutdown
- Cannot find core by name when election happen after the cores is shutdown

> Reduce noise in solr logs during graceful shutdown
> --
>
> Key: SOLR-9365
> URL: https://issues.apache.org/jira/browse/SOLR-9365
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Minor
>  Labels: difficulty-easy, impact-low, newdev
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9365.patch
>
>
> There is too much unnecessary logging of exceptions during a graceful 
> shutdown. This is mostly due to:
> # Watcher invocations fired after the zk callback executor is shutdown, and
> # Session expiry because of zkclient or embedded zk server shutdown
> We should add a simple check for such conditions to reduce noise in our logs.



--
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-7440) Document skipping on large indexes is broken

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on LUCENE-7440:
--

Patch coming... was waiting for tests to pass.

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Yonik Seeley
>Priority: Critical
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.



--
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-8029) Modernize and standardize Solr APIs

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8029: general refactoring


> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: 6.0
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, 
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 4 types of requests in the new API 
> * {{/v2//*}} : Hit a collection directly or manage 
> collections/shards/replicas 
> * {{/v2//*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection 
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



--
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-8029) Modernize and standardize Solr APIs

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8029: 'enum' support in schema


> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: 6.0
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, 
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 4 types of requests in the new API 
> * {{/v2//*}} : Hit a collection directly or manage 
> collections/shards/replicas 
> * {{/v2//*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection 
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



--
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: [VOTE] Release PyLucene 6.2.0 (rc2)

[Marc Jeurissen]

+1


On 9/09/2016 12:06, Andi Vajda wrote:


After an almost two year hiatus, a new PyLucene version is ready for 
release. The PyLucene 6.2.0 (rc2) release tracking the recent release 
of Apache Lucene 6.2.0 is ready.


A release candidate is available from:
https://dist.apache.org/repos/dist/dev/lucene/pylucene/6.2.0-rc2/

PyLucene 6.2.0 is built with JCC 2.22 included in these release 
artifacts.


Please vote to release these artifacts as PyLucene 6.2.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1



--
Signature Marc Jeurissen | UAntwerpen
Met vriendelijke groeten,

Marc Jeurissen


Bibliotheek UAntwerpen
Stadscampus - S.A.085
Prinsstraat 9 - 2000 Antwerpen
marc.jeuris...@uantwerpen.be 
T +32 3 265 49 71

[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode

[JIRA]

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

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

I tried throwing an error if edit was used when not in ZK mode, but that 
unfortunately broke some tests which relied on module testing the edit feature 
in standalone mode :(
Will try to find some way around it.

> BasicAuthPlugin should support standalone mode
> --
>
> Key: SOLR-9481
> URL: https://issues.apache.org/jira/browse/SOLR-9481
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: authentication
> Attachments: SOLR-9481.patch
>
>
> The BasicAuthPlugin currently only supports SolrCloud, and reads users and 
> credentials from ZK /security.json
> Add support for standalone mode operation



--
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+134) - Build # 17788 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17788/
Java: 32bit/jdk-9-ea+134 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([227079A60C288312:DB3DEA09305DCE98]: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.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:275)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/444/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail

Error Message:
expected:<200> but was:<404>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([48D09EE8D2FF436F:206FABC202655183]: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.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:141)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:286)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[VOTE] Release PyLucene 6.2.0 (rc2)

[Andi Vajda]

After an almost two year hiatus, a new PyLucene version is ready for 
release. The PyLucene 6.2.0 (rc2) release tracking the recent release of 
Apache Lucene 6.2.0 is ready.


A release candidate is available from:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/6.2.0-rc2/

PyLucene 6.2.0 is built with JCC 2.22 included in these release artifacts.

Please vote to release these artifacts as PyLucene 6.2.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[jira] [Commented] (SOLR-9491) CoreContainer Closer thread can miss cores

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9491:
-

I think SOLR-9208 might be related.

> CoreContainer Closer thread can miss cores
> --
>
> Key: SOLR-9491
> URL: https://issues.apache.org/jira/browse/SOLR-9491
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Alan Woodward
>
> See for example http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/836/
> The core T4 is placed on the 'to-close' queue by the transient core cache, 
> but it never gets picked up by the Closer thread for some reason - I'm 
> guessing it's a race somewhere, but the SolrCores code is really difficult to 
> follow so I'm having trouble tracking down exactly where this is happening.



--
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: testing PyLucene 6.2

[Andi Vajda]

On Fri, 9 Sep 2016, Andi Vajda wrote:



On Fri, 9 Sep 2016, Dirk Rothe wrote:


Am 09.09.2016, 00:29 Uhr, schrieb Andi Vajda :



On Thu, 8 Sep 2016, Dirk Rothe wrote:


Am 08.09.2016, 15:56 Uhr, schrieb Andi Vajda :


On Thu, 8 Sep 2016, Dirk Rothe wrote:
I've made initReader() python-overridable (see patch). What do you 
think?
Not sure what to think. While your change looks fine, if Lucene decided 
to make this 'hard', it may be a sign that you're doing something wrong 
or going the wrong way about it.
I suggest you ask on the java-u...@lucene.apache.org list as you're 
probably not the first one to transition from 3.x to something more 
recent.

Please let pylucene-dev@ know what you find out...


OK.

Making Analyzer.initReader() python-overridable is also important for 
use-cases like this: http://stackoverflow.com/a/10290635

So the patch should be fine independently of my usage/hack.


Actually, your patch is not good enough. You need to add an implementation 
for initReader() in all the tests that make a subclass of PythonAnalyzer 
(search for createComponents() implementations) otherwise, when 
initReader() gets called from Java, you'll get a stack overflow (it'd be 
good, as an aside, if I could make a better error out of that...).


OK, I see the effect in samples/PorterStemmerAnalyzer.py (fixed some 
imports there, use patch).


Shouldn't the need for implementation be optional? I don't understand.


Once you define a native method on a class, a native method implementation 
must be provided. JCC does that but that native implementation just invokes 
the python implementation on the python subclass instance. If that python 
subclass has no method implementation, the inherited method is invoked again, 
which in turn calls the native method again, and so on until the stack 
overflows.


This could maybe be improved at the JCC level but until it is, a Python
implementation must be provided. The default initReader() method just returns 
'reader' and so should the python default implementation.


I just did this so that I could produce a new RC and restart the voting 
process. I added initReader() and all needed implementations in tests and 
samples.


Thanks !

Andi..



Andi..



--dirk

Re: FacetExample.py's indexes are too old

[Andi Vajda]

On Fri, 9 Sep 2016, Andi Vajda wrote:


 Hi Thomas,

As you may have noticed, PyLucene is being refreshed to Lucene 6.2.0.
The FacetExample.py sample you submitted to PyLucene is using an index from
Lucene version 2, FacetExample.Index.

Sadly, Lucene 6 no longer supports that version, it must be at least version
4. Could you please refresh FacetExample.Index ? (and FacetExample.Taxonomy
looks like needing that too).


False alert, I had old indexes lying around and FacetExample.py is capable 
of regenerating the index. It runs now on PyLucene 6.2.0.


Andi..



Thanks !

Andi..

[jira] [Created] (SOLR-9491) CoreContainer Closer thread can miss cores

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-9491:
---

 Summary: CoreContainer Closer thread can miss cores
 Key: SOLR-9491
 URL: https://issues.apache.org/jira/browse/SOLR-9491
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.2
Reporter: Alan Woodward


See for example http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/836/

The core T4 is placed on the 'to-close' queue by the transient core cache, but 
it never gets picked up by the Closer thread for some reason - I'm guessing 
it's a race somewhere, but the SolrCores code is really difficult to follow so 
I'm having trouble tracking down exactly where this is happening.



--
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+134) - Build # 1690 - Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:38098/c8n_1x3_lf_shard1_replica2]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:38098/c8n_1x3_lf_shard1_replica2]
at 
__randomizedtesting.SeedInfo.seed([742626C3593EA404:FC721919F7C2C9FC]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:769)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:592)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:578)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:174)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

FacetExample.py's indexes are too old

[Andi Vajda]

  Hi Thomas,

As you may have noticed, PyLucene is being refreshed to Lucene 6.2.0.
The FacetExample.py sample you submitted to PyLucene is using an index from
Lucene version 2, FacetExample.Index.

Sadly, Lucene 6 no longer supports that version, it must be at least version
4. Could you please refresh FacetExample.Index ? (and FacetExample.Taxonomy
looks like needing that too).

Thanks !

Andi..

Re: testing PyLucene 6.2

[Andi Vajda]

On Fri, 9 Sep 2016, Dirk Rothe wrote:


Am 09.09.2016, 00:29 Uhr, schrieb Andi Vajda :



On Thu, 8 Sep 2016, Dirk Rothe wrote:


Am 08.09.2016, 15:56 Uhr, schrieb Andi Vajda :


On Thu, 8 Sep 2016, Dirk Rothe wrote:
I've made initReader() python-overridable (see patch). What do you 
think?
Not sure what to think. While your change looks fine, if Lucene decided 
to make this 'hard', it may be a sign that you're doing something wrong 
or going the wrong way about it.
I suggest you ask on the java-u...@lucene.apache.org list as you're 
probably not the first one to transition from 3.x to something more 
recent.

Please let pylucene-dev@ know what you find out...


OK.

Making Analyzer.initReader() python-overridable is also important for 
use-cases like this: http://stackoverflow.com/a/10290635

So the patch should be fine independently of my usage/hack.


Actually, your patch is not good enough. You need to add an implementation 
for initReader() in all the tests that make a subclass of PythonAnalyzer 
(search for createComponents() implementations) otherwise, when 
initReader() gets called from Java, you'll get a stack overflow (it'd be 
good, as an aside, if I could make a better error out of that...).


OK, I see the effect in samples/PorterStemmerAnalyzer.py (fixed some imports 
there, use patch).


I see no patch attached probably because the apache mail server strips 
attachments sent to mailing lists. Either you include the patch inline or 
you send it to me as an attachment directly.


Thanks !

Andi..



Shouldn't the need for implementation be optional? I don't understand.

--dirk