[JENKINS] Lucene-Solr-Tests-7.x - Build # 99 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/99/

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

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

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<403>
at 
__randomizedtesting.SeedInfo.seed([DE8577F5C2897658:62EB01E766DAF522]: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.security.BasicAuthIntegrationTest.executeCommand(BasicAuthIntegrationTest.java:242)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:154)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 13044 lines...]
   [junit4] Suite: 

[JENKINS] Lucene-Solr-NightlyTests-7.0 - Build # 15 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.0/15/

4 tests failed.
FAILED:  org.apache.lucene.index.TestMixedDocValuesUpdates.testTonsOfUpdates

Error Message:
_1_8.fnm

Stack Trace:
java.io.FileNotFoundException: _1_8.fnm
at 
__randomizedtesting.SeedInfo.seed([A5174D66C4FE2FFB:DD32936D26DE0019]:0)
at org.apache.lucene.store.RAMDirectory.openInput(RAMDirectory.java:243)
at 
org.apache.lucene.store.Directory.openChecksumInput(Directory.java:119)
at 
org.apache.lucene.store.RawDirectoryWrapper.openChecksumInput(RawDirectoryWrapper.java:41)
at 
org.apache.lucene.codecs.lucene60.Lucene60FieldInfosFormat.read(Lucene60FieldInfosFormat.java:113)
at 
org.apache.lucene.index.SegmentReader.initFieldInfos(SegmentReader.java:190)
at org.apache.lucene.index.SegmentReader.(SegmentReader.java:93)
at 
org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:688)
at 
org.apache.lucene.index.IndexWriter$ReaderPool.writeSomeDocValuesUpdates(IndexWriter.java:703)
at 
org.apache.lucene.index.FrozenBufferedUpdates.apply(FrozenBufferedUpdates.java:331)
at 
org.apache.lucene.index.DocumentsWriter$ResolveUpdatesEvent.process(DocumentsWriter.java:723)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5060)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5048)
at 
org.apache.lucene.index.IndexWriter.updateDocValues(IndexWriter.java:1879)
at 
org.apache.lucene.index.TestMixedDocValuesUpdates.testTonsOfUpdates(TestMixedDocValuesUpdates.java:374)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
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)

[jira] [Commented] (SOLR-10229) See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10229:
-

bq. Does it make sense to use the SolrJ APIs to change the schema instead?

Well this framework here randomizes the settings that aren't explicit, and I 
imagine that might be hard to do with SolrJ schema API?  Can you still use 
SolrJ schema API if a test writer wanted to?

RE setting "df" to "id" in solrconfig-id-version.xml: please don't do that; 
leave it off entirely.  If a test fundamentally requires the default field bet 
set, it ought to set it.  If it leads to errors then this is a good thing as 
whatever query caused it was ambiguous and they should be fixed.  Setting "df" 
in solrconfig can be problematic since it effects the entire query in ways that 
might be unanticipated since the Lucene query parser is activated via many Solr 
features (e.g. facet.query etc.).  This conceals bugs or makes errors take 
longer to troubleshoot (some head scratching moments as to why a query isn't 
working but doesn't error).  In my perfect world (that this isn't), "df" would 
only be a local-param, and all params would be considered a local-param to 'q' 
for convenience.

> See what it would take to shift many of our one-off schemas used for testing 
> to managed schema and construct them as part of the tests
> --
>
> Key: SOLR-10229
> URL: https://issues.apache.org/jira/browse/SOLR-10229
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, 
> SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, 
> SOLR-10229.patch, SOLR-10229-straw-man.patch
>
>
> The test schema files are intimidating. There are about a zillion of them, 
> and making a change in any of them risks breaking some _other_ test. That 
> leaves people three choices:
> 1> add what they need to some existing schema. Which makes schemas bigger and 
> bigger and bigger.
> 2> create a new schema file, adding to the proliferation thereof.
> 3> Look through all the existing tests to see if they have something that 
> works.
> The recent work on LUCENE-7705 is a case in point. We're adding a maxLen 
> parameter to some tokenizers. Putting those parameters into any of the 
> existing schemas, especially to test < 255 char tokens is virtually 
> guaranteed to break other tests, so the only safe thing to do is make another 
> schema file. Adding to the multiplication of files.
> As part of SOLR-5260 I tried creating the schema on the fly rather than 
> creating a new static schema file and it's not hard. WDYT about making this 
> into some better thought-out utility? 
> At present, this is pretty fuzzy, I wanted to get some reactions before 
> putting much effort into it. I expect that the utility methods would 
> eventually get a bunch of canned types. It's reasonably straightforward for 
> primitive types, if lengthy. But when you get into solr.TextField-based types 
> it gets less straight-forward.
> We could manage to just move the "intimidation" from the plethora of schema 
> files to a zillion fieldTypes in the utility to choose from...
> Also, forcing every test to define the fields up-front is arguably less 
> convenient than just having _some_ canned schemas we can use. And erroneous 
> schemas to test failure modes are probably not very good fits for any such 
> framework.
> [~steve_rowe] and [~hossman_luc...@fucit.org] in particular might have 
> something to say.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-11023:
---

Assignee: (was: Hoss Man)

> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: numeric-tries-to-points
> Attachments: SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-11023:

Attachment: SOLR-11023.patch


bq. I think points are not a good fit in that case, they will use more disk and 
be slower at exact queries, ...

Right, that's kind of what i was suspecting based on what i've read about 
points in the past -- really low cardinality like this didn't seem appropriate.

bq. I'd really store it like a string field ...

The hitch there is that, historically, when using "solr.EnumField" it's been 
possible to change the (String) "values" in the enumConfig.xml w/o breaking 
anything because only the (int) ordinals for those values were ever indexed (or 
put in docValues) ... and ideally we still want to do that.

So I think we really still want to use ints for the store/index/docvalues and 
deal with all the String/label conversion only in response writing and query 
parsing.   Obviously we'll still want to use NumericUtils.intToSortableBytes 
for the indexed bytes so that our range queries are still "numeric" and not 
"alphabetical"



I'm about to go off-line for 2 weeks, so here's a patch w/ my current work in 
progress...

* SOLR-5927 related test config beef up
* beef up existing test code a bit so that our enum has more then 10 values (to 
sanity check against potential "1 < 11 < 2" range query mistakes)
** add several nocommit comments about test coverage that seems to be missing
* refactors the EnumConfig parsing up into a new AbstractEnumField super class 
of EnumField
** clones EnumField into a new "HuperDuperEnumField" sibling class
** modify HuperDuperEnumField to use SortedNumericDV (and equiv query) instead 
of SortedSetDV
* update test configs and SolrTestCaseJ4 to randomize HuperDuperEnumField when 
randomizing in "point" fields (i guess really it's just "not trie fields" at 
this point)

obviously the big item still TODO is removing the existing LegacyIntField code 
from HuperDuperEnumField and picking a decent name.

If anyone wants to pick up & continue this patch while i'm gone, by all means 
please do.



> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>  Labels: numeric-tries-to-points
> Attachments: SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-7.0-Linux (32bit/jdk-9-ea+178) - Build # 81 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/81/
Java: 32bit/jdk-9-ea+178 -server -XX:+UseG1GC --illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxDocs

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([F0A9121391BDB721:4928C4CCBD57B3AB]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:885)
at 
org.apache.solr.update.AutoCommitTest.testMaxDocs(AutoCommitTest.java:225)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:14==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
... 39 more




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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.core.TestJmxIntegration.testJmxUpdate

Error Message:
solr:dom1=core,dom2=collection1,category=SEARCHER,scope=searcher,name=numDocs

Stack Trace:
javax.management.InstanceNotFoundException: 
solr:dom1=core,dom2=collection1,category=SEARCHER,scope=searcher,name=numDocs
at 
__randomizedtesting.SeedInfo.seed([1868411CDB6AD3E4:E0F73764BBC784F]:0)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
at 
org.apache.solr.core.TestJmxIntegration.testJmxUpdate(TestJmxIntegration.java:151)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20192/
Java: 64bit/jdk-9-ea+178 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.handler.admin.MBeansHandlerTest.testDiff

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([CD7B1EB232DD9490:86DDA29226BACF0]:0)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2473)
at org.apache.solr.util.TestHarness.query(TestHarness.java:337)
at org.apache.solr.util.TestHarness.query(TestHarness.java:319)
at 
org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)

[jira] [Commented] (SOLR-11093) implement Points/Numeric support for graph query

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-11093:
-

bq. Is there a back-compat concern?

Everything should be back compat with existing schemas.

> implement Points/Numeric support for graph query
> 
>
> Key: SOLR-11093
> URL: https://issues.apache.org/jira/browse/SOLR-11093
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 7.0
>
> Attachments: SOLR-11093.patch, SOLR-11093.patch, SOLR-11093.patch
>
>
> It looks like GraphQueryTest only has tests for strings.  We should add tests 
> for numeric fields and then enable points randomization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11093) implement Points/Numeric support for graph query

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-11093:

Attachment: SOLR-11093.patch

Updated patch... tests now pass!

> implement Points/Numeric support for graph query
> 
>
> Key: SOLR-11093
> URL: https://issues.apache.org/jira/browse/SOLR-11093
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 7.0
>
> Attachments: SOLR-11093.patch, SOLR-11093.patch, SOLR-11093.patch
>
>
> It looks like GraphQueryTest only has tests for strings.  We should add tests 
> for numeric fields and then enable points randomization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

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

Error Message:
tried these servers [https://127.0.0.1:53905/collection1_shard1_replica_n3, 
https://127.0.0.1:53925/collection1_shard1_replica_n7, 
https://127.0.0.1:53900/collection1_shard2_replica_n1, 
https://127.0.0.1:53913/collection1_shard2_replica_n5] succeeded only in []  
expected:<4> but was:<0>

Stack Trace:
java.lang.AssertionError: tried these servers 
[https://127.0.0.1:53905/collection1_shard1_replica_n3, 
https://127.0.0.1:53925/collection1_shard1_replica_n7, 
https://127.0.0.1:53900/collection1_shard2_replica_n1, 
https://127.0.0.1:53913/collection1_shard2_replica_n5] succeeded only in []  
expected:<4> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([2B3871F6B17F6CBB:A36C4E2C1F830143]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestConfigReload.checkConfReload(TestConfigReload.java:132)
at 
org.apache.solr.handler.TestConfigReload.reloadTest(TestConfigReload.java:92)
at 
org.apache.solr.handler.TestConfigReload.test(TestConfigReload.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Resolved] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-10494.
-
Resolution: Fixed

this change fixed smoketest for me on master, so i went ahead and backported it 
-- but i'm actually still sanity testing on 7x/7_0

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.0
>Reporter: Trey Grainger
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494.branch_7x.patch, 
> SOLR-10494.patch, SOLR-10494.patch, SOLR-10494.patch, 
> SOLR-10494-withdocs.patch, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10494:


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

SOLR-10494: fix smoker

(cherry picked from commit 56ad1a7a9b049e7399c0e482dcf6f4f395472f5b)


> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.0
>Reporter: Trey Grainger
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494.branch_7x.patch, 
> SOLR-10494.patch, SOLR-10494.patch, SOLR-10494.patch, 
> SOLR-10494-withdocs.patch, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10494:


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

SOLR-10494: fix smoker

(cherry picked from commit 56ad1a7a9b049e7399c0e482dcf6f4f395472f5b)


> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.0
>Reporter: Trey Grainger
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494.branch_7x.patch, 
> SOLR-10494.patch, SOLR-10494.patch, SOLR-10494.patch, 
> SOLR-10494-withdocs.patch, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10494:


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

SOLR-10494: fix smoker


> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.0
>Reporter: Trey Grainger
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494.branch_7x.patch, 
> SOLR-10494.patch, SOLR-10494.patch, SOLR-10494.patch, 
> SOLR-10494-withdocs.patch, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-9-ea+178) - Build # 137 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/137/
Java: 64bit/jdk-9-ea+178 -XX:-UseCompressedOops -XX:+UseG1GC 
--illegal-access=deny

1 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressConcurrentCommit

Error Message:
this IndexWriter is closed

Stack Trace:
org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:896)
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:910)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3377)
at 
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressConcurrentCommit(TestIndexingSequenceNumbers.java:230)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.OutOfMemoryError: Java heap space




Build Log:
[...truncated 1696 lines...]
   [junit4] Suite: org.apache.lucene.index.TestIndexingSequenceNumbers
   [junit4]   2> msb 24, 2017 2:57:39 YA MUCHANA 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-2717,5,TGRP-TestIndexingSequenceNumbers]
   [junit4]   2> java.lang.RuntimeException: 
org.apache.lucene.store.AlreadyClosedException: refusing to delete any files: 

[JENKINS-EA] Lucene-Solr-7.0-Windows (32bit/jdk-9-ea+178) - Build # 43 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Windows/43/
Java: 32bit/jdk-9-ea+178 -server -XX:+UseG1GC --illegal-access=deny

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

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:62986/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:62986/collection1
at 
__randomizedtesting.SeedInfo.seed([F501BAE147B1A05C:7D55853BE94DCDA4]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1581)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:213)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

Re: Request for Lucene.net 4.8 Beta for .Net Core

[Chris Hostetter]

Lucene.Net is a fully distinct Apache project with completely 
independent developer/user communities, mailing lists, source code 
repository, and releases...

https://lucenenet.apache.org/community.html




: Date: Mon, 24 Jul 2017 21:56:17 +0530
: From: rohit kumar 
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Cc: Mohan Jaganathan 
: Subject: Request for Lucene.net 4.8 Beta for .Net Core
: 
: Hi,
: 
: I am Rohit Kumar Rapolu from Hyderabad, India.  We are working on our
: academic project which is web application on .net core framework.  We
: trying to implement full text search in our application.  We heard Lucene
: is the best for it.  Could we have Lucene 4.8 Beta version which supports
: on .net core 1.1 framework.  Could you please help us on this.
: 
: 
: Regards
: 
: -- 
: 
: *RegardsRohit*
: 

-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] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10494:
-

gah ... sorry ... i didn't even think about that.

lemme review the rest of the smoketester a bit more and figure out if it makes 
more sense to just add wt=xml, or to redo these bits to expect json by default.

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.0
>Reporter: Trey Grainger
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494.branch_7x.patch, 
> SOLR-10494.patch, SOLR-10494.patch, SOLR-10494.patch, 
> SOLR-10494-withdocs.patch, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Reopened] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Hoss Man (JIRA)]

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

Hoss Man reopened SOLR-10494:
-

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.0
>Reporter: Trey Grainger
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494.branch_7x.patch, 
> SOLR-10494.patch, SOLR-10494.patch, SOLR-10494.patch, 
> SOLR-10494-withdocs.patch, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 73 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/73/

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

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica_n3","base_url":"http://127.0.0.1:36014","node_name":"127.0.0.1:36014_","state":"active","type":"NRT","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/28)={   
"pullReplicas":"0",   "replicationFactor":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"c8n_1x3_lf_shard1_replica_n1",   
"base_url":"http://127.0.0.1:38254;,   "node_name":"127.0.0.1:38254_",  
 "state":"down",   "type":"NRT"}, "core_node2":{
   "state":"down",   "base_url":"http://127.0.0.1:44778;,   
"core":"c8n_1x3_lf_shard1_replica_n2",   
"node_name":"127.0.0.1:44778_",   "type":"NRT"}, "core_node3":{ 
  "core":"c8n_1x3_lf_shard1_replica_n3",   
"base_url":"http://127.0.0.1:36014;,   "node_name":"127.0.0.1:36014_",  
 "state":"active",   "type":"NRT",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false",   "nrtReplicas":"3",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica_n3","base_url":"http://127.0.0.1:36014","node_name":"127.0.0.1:36014_","state":"active","type":"NRT","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/28)={
  "pullReplicas":"0",
  "replicationFactor":"1",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"c8n_1x3_lf_shard1_replica_n1",
  "base_url":"http://127.0.0.1:38254;,
  "node_name":"127.0.0.1:38254_",
  "state":"down",
  "type":"NRT"},
"core_node2":{
  "state":"down",
  "base_url":"http://127.0.0.1:44778;,
  "core":"c8n_1x3_lf_shard1_replica_n2",
  "node_name":"127.0.0.1:44778_",
  "type":"NRT"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica_n3",
  "base_url":"http://127.0.0.1:36014;,
  "node_name":"127.0.0.1:36014_",
  "state":"active",
  "type":"NRT",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"3",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([269DA1D02135731E:AEC99E0A8FC91EE6]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:169)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-10229) See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10229:
---

Does it make sense to use the SolrJ APIs to change the schema instead?

> See what it would take to shift many of our one-off schemas used for testing 
> to managed schema and construct them as part of the tests
> --
>
> Key: SOLR-10229
> URL: https://issues.apache.org/jira/browse/SOLR-10229
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, 
> SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, 
> SOLR-10229.patch, SOLR-10229-straw-man.patch
>
>
> The test schema files are intimidating. There are about a zillion of them, 
> and making a change in any of them risks breaking some _other_ test. That 
> leaves people three choices:
> 1> add what they need to some existing schema. Which makes schemas bigger and 
> bigger and bigger.
> 2> create a new schema file, adding to the proliferation thereof.
> 3> Look through all the existing tests to see if they have something that 
> works.
> The recent work on LUCENE-7705 is a case in point. We're adding a maxLen 
> parameter to some tokenizers. Putting those parameters into any of the 
> existing schemas, especially to test < 255 char tokens is virtually 
> guaranteed to break other tests, so the only safe thing to do is make another 
> schema file. Adding to the multiplication of files.
> As part of SOLR-5260 I tried creating the schema on the fly rather than 
> creating a new static schema file and it's not hard. WDYT about making this 
> into some better thought-out utility? 
> At present, this is pretty fuzzy, I wanted to get some reactions before 
> putting much effort into it. I expect that the utility methods would 
> eventually get a bunch of canned types. It's reasonably straightforward for 
> primitive types, if lengthy. But when you get into solr.TextField-based types 
> it gets less straight-forward.
> We could manage to just move the "intimidation" from the plethora of schema 
> files to a zillion fieldTypes in the utility to choose from...
> Also, forcing every test to define the fields up-front is arguably less 
> convenient than just having _some_ canned schemas we can use. And erroneous 
> schemas to test failure modes are probably not very good fits for any such 
> framework.
> [~steve_rowe] and [~hossman_luc...@fucit.org] in particular might have 
> something to say.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11139) FreeTextSuggester exits on first error while building suggester index

[Angel Todorov (JIRA)]

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

Angel Todorov updated SOLR-11139:
-
Description: 
If an exception is thrown below, it will exit the while loop, therefore 
stopping building of the suggester index. In fact, it will not build anything, 
because the exception is not handled in any way. This is highly unacceptable, 
because in an enterprise environment there will always be data that does not 
conform to the expected rules. 

  while (true) {
BytesRef term = termsEnum.next();
if (term == null) {
  break;
}
int ngramCount = countGrams(term);
if (ngramCount > grams) {
  throw new IllegalArgumentException("tokens must not contain separator 
byte; got token=" + term + " but gramCount=" + ngramCount + ", which is greater 
than expected max ngram size=" + grams);
}
if (ngramCount == 1) {
  totTokens += termsEnum.totalTermFreq();
}

builder.add(Util.toIntsRef(term, scratchInts), 
encodeWeight(termsEnum.totalTermFreq()));
  }


  was:
If an exception is thrown below, it will exit the while loop, therefore 
stopping building of the suggester index. This is highly unacceptable, because 
in an enterprise environment there will always be data that does not conform to 
the expected rules. 

  while (true) {
BytesRef term = termsEnum.next();
if (term == null) {
  break;
}
int ngramCount = countGrams(term);
if (ngramCount > grams) {
  throw new IllegalArgumentException("tokens must not contain separator 
byte; got token=" + term + " but gramCount=" + ngramCount + ", which is greater 
than expected max ngram size=" + grams);
}
if (ngramCount == 1) {
  totTokens += termsEnum.totalTermFreq();
}

builder.add(Util.toIntsRef(term, scratchInts), 
encodeWeight(termsEnum.totalTermFreq()));
  }



> FreeTextSuggester exits on first error while building suggester index
> -
>
> Key: SOLR-11139
> URL: https://issues.apache.org/jira/browse/SOLR-11139
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 5.5.4
>Reporter: Angel Todorov
>Priority: Blocker
>
> If an exception is thrown below, it will exit the while loop, therefore 
> stopping building of the suggester index. In fact, it will not build 
> anything, because the exception is not handled in any way. This is highly 
> unacceptable, because in an enterprise environment there will always be data 
> that does not conform to the expected rules. 
>   while (true) {
> BytesRef term = termsEnum.next();
> if (term == null) {
>   break;
> }
> int ngramCount = countGrams(term);
> if (ngramCount > grams) {
>   throw new IllegalArgumentException("tokens must not contain 
> separator byte; got token=" + term + " but gramCount=" + ngramCount + ", 
> which is greater than expected max ngram size=" + grams);
> }
> if (ngramCount == 1) {
>   totTokens += termsEnum.totalTermFreq();
> }
> builder.add(Util.toIntsRef(term, scratchInts), 
> encodeWeight(termsEnum.totalTermFreq()));
>   }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: via C++, determine if a java object is null

[Andi Vajda]

On Mon, 24 Jul 2017, William Schilp wrote:


i'm using JCC to interface a C++ application to a java application. in the
java application a method can return a "null" java object. i need to
determine if the returned object is a null object. i do not see a way to do
this via the JCC interface. the object i get on the C++ side is an object
residing in memory space. so as far as C++ is concerned, the object is not
NULL as it points to a valid memory address, ie not 0.
so, how do i determine if the returned object is a null java object?


The java object is held by the 'jobject this$' member variable in the C++ 
wrapper. I think that if Java returned a null object, this$ is set to 0;


You might also be able to use the '!' operator declared on JObject:

inline int operator!() const
{
return env->isSame(this$, NULL);
}

if (!wrapper)  // java returned null
  ...

Andi..



bill

[jira] [Created] (SOLR-11139) FreeTextSuggester exits on first error while building suggester index

[Angel Todorov (JIRA)]

Angel Todorov created SOLR-11139:


 Summary: FreeTextSuggester exits on first error while building 
suggester index
 Key: SOLR-11139
 URL: https://issues.apache.org/jira/browse/SOLR-11139
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Suggester
Affects Versions: 5.5.4
Reporter: Angel Todorov
Priority: Blocker


If an exception is thrown below, it will exit the while loop, therefore 
stopping building of the suggester index. This is highly unacceptable, because 
in an enterprise environment there will always be data that does not conform to 
the expected rules. 

  while (true) {
BytesRef term = termsEnum.next();
if (term == null) {
  break;
}
int ngramCount = countGrams(term);
if (ngramCount > grams) {
  throw new IllegalArgumentException("tokens must not contain separator 
byte; got token=" + term + " but gramCount=" + ngramCount + ", which is greater 
than expected max ngram size=" + grams);
}
if (ngramCount == 1) {
  totTokens += termsEnum.totalTermFreq();
}

builder.add(Util.toIntsRef(term, scratchInts), 
encodeWeight(termsEnum.totalTermFreq()));
  }




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9836) Add more graceful recovery steps when failing to create SolrCore

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9836:
--

Non-reproducing master failure from my Jenkins yesterday: 

{noformat}
Checking out Revision 97ca529e49505cef0c1dd6138ed70be4a7b85610 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=MissingSegmentRecoveryTest -Dtests.method=testLeaderRecovery 
-Dtests.seed=E0C710C4147CEA7B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=ar-BH -Dtests.timezone=Asia/Urumqi -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 95.9s J2 | MissingSegmentRecoveryTest.testLeaderRecovery <<<
   [junit4]> Throwable #1: java.lang.AssertionError: Expected a collection 
with one shard and two replicas
   [junit4]> null
   [junit4]> Live Nodes: [127.0.0.1:42849_solr, 127.0.0.1:43941_solr]
   [junit4]> Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/9)={
   [junit4]>   "pullReplicas":"0",
   [junit4]>   "replicationFactor":"2",
   [junit4]>   "shards":{"shard1":{
   [junit4]>   "range":"8000-7fff",
   [junit4]>   "state":"active",
   [junit4]>   "replicas":{
   [junit4]> "core_node1":{
   [junit4]>   
"core":"MissingSegmentRecoveryTest_shard1_replica_n1",
   [junit4]>   "base_url":"https://127.0.0.1:42849/solr;,
   [junit4]>   "node_name":"127.0.0.1:42849_solr",
   [junit4]>   "state":"active",
   [junit4]>   "type":"NRT",
   [junit4]>   "leader":"true"},
   [junit4]> "core_node2":{
   [junit4]>   
"core":"MissingSegmentRecoveryTest_shard1_replica_n2",
   [junit4]>   "base_url":"https://127.0.0.1:43941/solr;,
   [junit4]>   "node_name":"127.0.0.1:43941_solr",
   [junit4]>   "state":"down",
   [junit4]>   "type":"NRT",
   [junit4]>   "router":{"name":"compositeId"},
   [junit4]>   "maxShardsPerNode":"1",
   [junit4]>   "autoAddReplicas":"false",
   [junit4]>   "nrtReplicas":"2",
   [junit4]>   "tlogReplicas":"0"}
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([E0C710C4147CEA7B:B09288C74D5D5C66]:0)
   [junit4]>at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
   [junit4]>at 
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:105)
[...]
   [junit4]   2> NOTE: test params are: 
codec=HighCompressionCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=HIGH_COMPRESSION,
 chunkSize=4, maxDocsPerChunk=1, blockSize=790), 
termVectorsFormat=CompressingTermVectorsFormat(compressionMode=HIGH_COMPRESSION,
 chunkSize=4, blockSize=790)), sim=RandomSimilarity(queryNorm=true): {}, 
locale=ar-BH, timezone=Asia/Urumqi
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=300978976,total=530055168
   [junit4]   2> NOTE: All tests run in this JVM: [SolrCloudReportersTest, 
TestConfigSetsAPIExclusivity, TestCloudJSONFacetJoinDomain, 
RequestHandlersTest, TestRangeQuery, TestJsonFacetRefinement, ZkCLITest, 
ExternalFileFieldSortTest, LukeRequestHandlerTest, SimpleMLTQParserTest, 
AutoScalingHandlerTest, CdcrBootstrapTest, TestBulkSchemaConcurrent, 
CoreAdminHandlerTest, SuggestComponentTest, TestRuleBasedAuthorizationPlugin, 
CdcrUpdateLogTest, SpellCheckCollatorWithCollapseTest, SortByFunctionTest, 
MissingSegmentRecoveryTest]
{noformat}

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



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SOLR-10272) Use a default configset and make the configName parameter optional.

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya resolved SOLR-10272.
-
Resolution: Fixed

Ah, I was wrong; I had finished it up already and just forgot to close out this 
issue; doing so now.

> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz, 
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience 
> better for users.
> To create a collection we need to specify a configName that needs to be 
> present in ZK. When a new user is starting Solr why should he worry about 
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a 
> configset and references it. This is great. We should extend this idea to API 
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if 
> "/configs/_baseConfigSet" znode is present . If not it uploads the 
> "basic_configs". 
> We can discuss if its the "basic_configs" or something other default config 
> set. 
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API  
> {{admin/collections?action=CREATE=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy 
> over the default config set to a configset with the name of the collection 
> specified.
> collection.configName can truly be an optional parameter. If its specified we 
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do 
> the same thing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10272:
-

Hi Anshum, just minor ref guide documentation remains for a related issue, 
SOLR-10574. I'll take it up tomorrow.

> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz, 
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience 
> better for users.
> To create a collection we need to specify a configName that needs to be 
> present in ZK. When a new user is starting Solr why should he worry about 
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a 
> configset and references it. This is great. We should extend this idea to API 
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if 
> "/configs/_baseConfigSet" znode is present . If not it uploads the 
> "basic_configs". 
> We can discuss if its the "basic_configs" or something other default config 
> set. 
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API  
> {{admin/collections?action=CREATE=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy 
> over the default config set to a configset with the name of the collection 
> specified.
> collection.configName can truly be an optional parameter. If its specified we 
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do 
> the same thing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-6630:


Anshum, unfortunately, I'll be unable to get to this until 28th August. I'm 
unmarking this as a blocker as per Noble's comment [0].

[0] - 
https://issues.apache.org/jira/browse/SOLR-6630?focusedCommentId=16062482=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16062482

> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Shawn Heisey
> Fix For: 7.0
>
> Attachments: SOLR-6630.patch, SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
>  all my documents end up on just one of my 24 shards. What
>  might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router.  that means that
>   documents will be indexed on the shard you sent them
> to, not
>   routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
>  impression that implicit router would use a hash of the
>  uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name.  It's technically
> correct,
>   but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person.  This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead?  Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log.  Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning.  If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-6630:
---
Priority: Major  (was: Blocker)

> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Shawn Heisey
> Fix For: 7.0
>
> Attachments: SOLR-6630.patch, SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
>  all my documents end up on just one of my 24 shards. What
>  might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router.  that means that
>   documents will be indexed on the shard you sent them
> to, not
>   routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
>  impression that implicit router would use a hash of the
>  uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name.  It's technically
> correct,
>   but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person.  This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead?  Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log.  Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning.  If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10261) TestStressCloudBlindAtomicUpdates.test_dv() fail

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-10261:

Attachment: SOLR-10261.patch

Here's a WIP patch that potentially fixes the issue.

> TestStressCloudBlindAtomicUpdates.test_dv() fail
> 
>
> Key: SOLR-10261
> URL: https://issues.apache.org/jira/browse/SOLR-10261
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10261.patch
>
>
> I found a reproducing seed that cause 
> TestStressCloudBlindAtomicUpdates.test_dv() fail
> {code}
> [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestStressCloudBlindAtomicUpdates -Dtests.method=test_dv 
> -Dtests.seed=AD8E7B56D53B627F -Dtests.nightly=true -Dtests.slow=true 
> -Dtests.locale=bg -Dtests.timezone=America/La_Paz -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   1.21s J2 | TestStressCloudBlindAtomicUpdates.test_dv <<<
>[junit4]> Throwable #1: java.util.concurrent.ExecutionException: 
> java.lang.RuntimeException: Error from server at 
> http://127.0.0.1:49825/solr/test_col: Async exception during distributed 
> update: Error from server at 
> http://127.0.0.1:49824/solr/test_col_shard2_replica2: Server Error
>[junit4]> request: 
> http://127.0.0.1:49824/solr/test_col_shard2_replica2/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A49825%2Fsolr%2Ftest_col_shard5_replica1%2F=javabin=2
>[junit4]> Remote error message: Failed synchronous update on shard 
> StdNode: http://127.0.0.1:49836/solr/test_col_shard2_replica1/ update: 
> org.apache.solr.client.solrj.request.UpdateRequest@5919dfb3
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([AD8E7B56D53B627F:9B9A19105F66586E]:0)
>[junit4]>  at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
>[junit4]>  at 
> java.util.concurrent.FutureTask.get(FutureTask.java:192)
>[junit4]>  at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:281)
>[junit4]>  at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:193)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.RuntimeException: Error from server at 
> http://127.0.0.1:49825/solr/test_col: Async exception during distributed 
> update: Error from server at 
> http://127.0.0.1:49824/solr/test_col_shard2_replica2: Server Error
>[junit4]> request: 
> http://127.0.0.1:49824/solr/test_col_shard2_replica2/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A49825%2Fsolr%2Ftest_col_shard5_replica1%2F=javabin=2
>[junit4]> Remote error message: Failed synchronous update on shard 
> StdNode: http://127.0.0.1:49836/solr/test_col_shard2_replica1/ update: 
> org.apache.solr.client.solrj.request.UpdateRequest@5919dfb3
>[junit4]>  at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates$Worker.run(TestStressCloudBlindAtomicUpdates.java:409)
>[junit4]>  at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>[junit4]>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>[junit4]>  at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>[junit4]>  ... 1 more
>[junit4]> Caused by: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://127.0.0.1:49825/solr/test_col: Async exception during 
> distributed update: Error from server at 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10372) TestStressCloudBlindAtomicUpdates.test_dv() failure: Failed synchronous update

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya resolved SOLR-10372.
-
Resolution: Duplicate

> TestStressCloudBlindAtomicUpdates.test_dv() failure: Failed synchronous update
> --
>
> Key: SOLR-10372
> URL: https://issues.apache.org/jira/browse/SOLR-10372
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
>
> Policeman Jenkins found a reproducing branch_6x seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3157/]:
> {noformat}
> Checking out Revision 337612259a928ab61f1380470e6e0fbe4e71bca4 
> (refs/remotes/origin/branch_6x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestStressCloudBlindAtomicUpdates -Dtests.method=test_dv 
> -Dtests.seed=72B0B386CE823E83 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=vi-VN -Dtests.timezone=Etc/GMT-14 -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.66s J1 | TestStressCloudBlindAtomicUpdates.test_dv <<<
>[junit4]> Throwable #1: java.util.concurrent.ExecutionException: 
> java.lang.RuntimeException: Error from server at 
> http://127.0.0.1:34879/solr/test_col: Async exception during distributed 
> update: Error from server at 
> http://127.0.0.1:46166/solr/test_col_shard1_replica1: Server Error
>[junit4]> request: 
> http://127.0.0.1:46166/solr/test_col_shard1_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A34879%2Fsolr%2Ftest_col_shard2_replica2%2F=javabin=2
>[junit4]> Remote error message: Failed synchronous update on shard 
> StdNode: http://127.0.0.1:35050/solr/test_col_shard1_replica2/ update: 
> org.apache.solr.client.solrj.request.UpdateRequest@11acebf
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([72B0B386CE823E83:44A4D1C044DF0492]:0)
>[junit4]>  at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
>[junit4]>  at 
> java.util.concurrent.FutureTask.get(FutureTask.java:192)
>[junit4]>  at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:281)
>[junit4]>  at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:193)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.RuntimeException: Error from server at 
> http://127.0.0.1:34879/solr/test_col: Async exception during distributed 
> update: Error from server at 
> http://127.0.0.1:46166/solr/test_col_shard1_replica1: Server Error
>[junit4]> request: 
> http://127.0.0.1:46166/solr/test_col_shard1_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A34879%2Fsolr%2Ftest_col_shard2_replica2%2F=javabin=2
>[junit4]> Remote error message: Failed synchronous update on shard 
> StdNode: http://127.0.0.1:35050/solr/test_col_shard1_replica2/ update: 
> org.apache.solr.client.solrj.request.UpdateRequest@11acebf
>[junit4]>  at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates$Worker.run(TestStressCloudBlindAtomicUpdates.java:409)
>[junit4]>  at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>[junit4]>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>[junit4]>  at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>[junit4]>  ... 1 more
>[junit4]> Caused by: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://127.0.0.1:34879/solr/test_col: Async exception during 
> distributed update: Error from server at 
> http://127.0.0.1:46166/solr/test_col_shard1_replica1: Server Error
>[junit4]> request: 
> http://127.0.0.1:46166/solr/test_col_shard1_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A34879%2Fsolr%2Ftest_col_shard2_replica2%2F=javabin=2
>[junit4]> Remote error message: Failed synchronous update on shard 
> StdNode: http://127.0.0.1:35050/solr/test_col_shard1_replica2/ update: 
> org.apache.solr.client.solrj.request.UpdateRequest@11acebf
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:610)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
>

[jira] [Assigned] (SOLR-10261) TestStressCloudBlindAtomicUpdates.test_dv() fail

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya reassigned SOLR-10261:
---

Assignee: Ishan Chattopadhyaya

> TestStressCloudBlindAtomicUpdates.test_dv() fail
> 
>
> Key: SOLR-10261
> URL: https://issues.apache.org/jira/browse/SOLR-10261
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Ishan Chattopadhyaya
>
> I found a reproducing seed that cause 
> TestStressCloudBlindAtomicUpdates.test_dv() fail
> {code}
> [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestStressCloudBlindAtomicUpdates -Dtests.method=test_dv 
> -Dtests.seed=AD8E7B56D53B627F -Dtests.nightly=true -Dtests.slow=true 
> -Dtests.locale=bg -Dtests.timezone=America/La_Paz -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   1.21s J2 | TestStressCloudBlindAtomicUpdates.test_dv <<<
>[junit4]> Throwable #1: java.util.concurrent.ExecutionException: 
> java.lang.RuntimeException: Error from server at 
> http://127.0.0.1:49825/solr/test_col: Async exception during distributed 
> update: Error from server at 
> http://127.0.0.1:49824/solr/test_col_shard2_replica2: Server Error
>[junit4]> request: 
> http://127.0.0.1:49824/solr/test_col_shard2_replica2/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A49825%2Fsolr%2Ftest_col_shard5_replica1%2F=javabin=2
>[junit4]> Remote error message: Failed synchronous update on shard 
> StdNode: http://127.0.0.1:49836/solr/test_col_shard2_replica1/ update: 
> org.apache.solr.client.solrj.request.UpdateRequest@5919dfb3
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([AD8E7B56D53B627F:9B9A19105F66586E]:0)
>[junit4]>  at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
>[junit4]>  at 
> java.util.concurrent.FutureTask.get(FutureTask.java:192)
>[junit4]>  at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:281)
>[junit4]>  at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:193)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.RuntimeException: Error from server at 
> http://127.0.0.1:49825/solr/test_col: Async exception during distributed 
> update: Error from server at 
> http://127.0.0.1:49824/solr/test_col_shard2_replica2: Server Error
>[junit4]> request: 
> http://127.0.0.1:49824/solr/test_col_shard2_replica2/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A49825%2Fsolr%2Ftest_col_shard5_replica1%2F=javabin=2
>[junit4]> Remote error message: Failed synchronous update on shard 
> StdNode: http://127.0.0.1:49836/solr/test_col_shard2_replica1/ update: 
> org.apache.solr.client.solrj.request.UpdateRequest@5919dfb3
>[junit4]>  at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates$Worker.run(TestStressCloudBlindAtomicUpdates.java:409)
>[junit4]>  at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>[junit4]>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>[junit4]>  at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>[junit4]>  ... 1 more
>[junit4]> Caused by: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://127.0.0.1:49825/solr/test_col: Async exception during 
> distributed update: Error from server at 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-10372) TestStressCloudBlindAtomicUpdates.test_dv() failure: Failed synchronous update

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya reassigned SOLR-10372:
---

Assignee: Ishan Chattopadhyaya

> TestStressCloudBlindAtomicUpdates.test_dv() failure: Failed synchronous update
> --
>
> Key: SOLR-10372
> URL: https://issues.apache.org/jira/browse/SOLR-10372
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
>
> Policeman Jenkins found a reproducing branch_6x seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3157/]:
> {noformat}
> Checking out Revision 337612259a928ab61f1380470e6e0fbe4e71bca4 
> (refs/remotes/origin/branch_6x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestStressCloudBlindAtomicUpdates -Dtests.method=test_dv 
> -Dtests.seed=72B0B386CE823E83 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=vi-VN -Dtests.timezone=Etc/GMT-14 -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.66s J1 | TestStressCloudBlindAtomicUpdates.test_dv <<<
>[junit4]> Throwable #1: java.util.concurrent.ExecutionException: 
> java.lang.RuntimeException: Error from server at 
> http://127.0.0.1:34879/solr/test_col: Async exception during distributed 
> update: Error from server at 
> http://127.0.0.1:46166/solr/test_col_shard1_replica1: Server Error
>[junit4]> request: 
> http://127.0.0.1:46166/solr/test_col_shard1_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A34879%2Fsolr%2Ftest_col_shard2_replica2%2F=javabin=2
>[junit4]> Remote error message: Failed synchronous update on shard 
> StdNode: http://127.0.0.1:35050/solr/test_col_shard1_replica2/ update: 
> org.apache.solr.client.solrj.request.UpdateRequest@11acebf
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([72B0B386CE823E83:44A4D1C044DF0492]:0)
>[junit4]>  at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
>[junit4]>  at 
> java.util.concurrent.FutureTask.get(FutureTask.java:192)
>[junit4]>  at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:281)
>[junit4]>  at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:193)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.RuntimeException: Error from server at 
> http://127.0.0.1:34879/solr/test_col: Async exception during distributed 
> update: Error from server at 
> http://127.0.0.1:46166/solr/test_col_shard1_replica1: Server Error
>[junit4]> request: 
> http://127.0.0.1:46166/solr/test_col_shard1_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A34879%2Fsolr%2Ftest_col_shard2_replica2%2F=javabin=2
>[junit4]> Remote error message: Failed synchronous update on shard 
> StdNode: http://127.0.0.1:35050/solr/test_col_shard1_replica2/ update: 
> org.apache.solr.client.solrj.request.UpdateRequest@11acebf
>[junit4]>  at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates$Worker.run(TestStressCloudBlindAtomicUpdates.java:409)
>[junit4]>  at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>[junit4]>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>[junit4]>  at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>[junit4]>  ... 1 more
>[junit4]> Caused by: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://127.0.0.1:34879/solr/test_col: Async exception during 
> distributed update: Error from server at 
> http://127.0.0.1:46166/solr/test_col_shard1_replica1: Server Error
>[junit4]> request: 
> http://127.0.0.1:46166/solr/test_col_shard1_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A34879%2Fsolr%2Ftest_col_shard2_replica2%2F=javabin=2
>[junit4]> Remote error message: Failed synchronous update on shard 
> StdNode: http://127.0.0.1:35050/solr/test_col_shard1_replica2/ update: 
> org.apache.solr.client.solrj.request.UpdateRequest@11acebf
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:610)
>[junit4]>  at 
> 

[jira] [Commented] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-6630:


[~ichattopadhyaya] are you actively working on this?

> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Shawn Heisey
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-6630.patch, SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
>  all my documents end up on just one of my 24 shards. What
>  might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router.  that means that
>   documents will be indexed on the shard you sent them
> to, not
>   routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
>  impression that implicit router would use a hash of the
>  uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name.  It's technically
> correct,
>   but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person.  This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead?  Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log.  Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning.  If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-10272:
-

[~ichattopadhyaya] I think this is resolved, but can you confirm?

> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz, 
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience 
> better for users.
> To create a collection we need to specify a configName that needs to be 
> present in ZK. When a new user is starting Solr why should he worry about 
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a 
> configset and references it. This is great. We should extend this idea to API 
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if 
> "/configs/_baseConfigSet" znode is present . If not it uploads the 
> "basic_configs". 
> We can discuss if its the "basic_configs" or something other default config 
> set. 
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API  
> {{admin/collections?action=CREATE=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy 
> over the default config set to a configset with the name of the collection 
> specified.
> collection.configName can truly be an optional parameter. If its specified we 
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do 
> the same thing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10494:
---

Smoke tester is unhappy on master because a Solr query response is in JSON vs 
XML - from [https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/823/]:

{noformat}

[...]
  [smoker] Solr techproducts example launched successfully. Direct your Web 
browser to http://localhost:8983/solr to visit the Solr Admin UI
   [smoker]   test utf8...
   [smoker]   run query...
   [smoker] FAILED: response is:
   [smoker] {
   [smoker]   "responseHeader":{
   [smoker] "status":0,
   [smoker] "QTime":0,
   [smoker] "params":{
   [smoker]   "q":"video"}},
   [smoker]   "response":{"numFound":3,"start":0,"docs":[
[...]
{noformat}

>From {{smokeTestRelease.py}}:

{code}
859: print('  run query...')
860: s = load('http://localhost:8983/solr/techproducts/select/?q=video')
861: if s.find('') == -1:
862:   print('FAILED: response is:\n%s' % s)
{code}

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.0
>Reporter: Trey Grainger
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494.branch_7x.patch, 
> SOLR-10494.patch, SOLR-10494.patch, SOLR-10494.patch, 
> SOLR-10494-withdocs.patch, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 823 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/823/

No tests ran.

Build Log:
[...truncated 25698 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/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:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (42.2 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 28.9 MB in 0.02 sec (1247.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 68.9 MB in 0.05 sec (1258.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 79.2 MB in 0.06 sec (1238.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6128 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6128 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 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] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (261.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-8.0.0-src.tgz...
   [smoker] 49.6 MB in 0.04 sec (1159.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.tgz...
   [smoker] 141.6 MB in 0.12 sec (1172.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.zip...
   [smoker] 142.6 MB in 0.12 sec (1180.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-8.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8
   [smoker] Creating Solr home directory 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=21526). 

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-9-ea+178) - Build # 6777 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6777/
Java: 64bit/jdk-9-ea+178 -XX:-UseCompressedOops -XX:+UseG1GC 
--illegal-access=deny

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.search.TestSearcherReuse

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_FCA5EEE22995C8F9-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_FCA5EEE22995C8F9-001\init-core-data-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_FCA5EEE22995C8F9-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_FCA5EEE22995C8F9-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_FCA5EEE22995C8F9-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_FCA5EEE22995C8F9-001\init-core-data-001
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_FCA5EEE22995C8F9-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_FCA5EEE22995C8F9-001

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


FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.SolrExceptionTest

Error Message:
The test or suite printed 9250 bytes to stdout and stderr, even though the 
limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
completely with @SuppressSysoutChecks or run with -Dtests.verbose=true

Stack Trace:
java.lang.AssertionError: The test or suite printed 9250 bytes to stdout and 
stderr, even though the limit was set to 8192 bytes. Increase the limit with 
@Limit, ignore it completely with @SuppressSysoutChecks or run with 
-Dtests.verbose=true
at __randomizedtesting.SeedInfo.seed([3A9739303F1BABB9]:0)
at 
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:211)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
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:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 11181 lines...]
   [junit4] Suite: org.apache.solr.search.TestSearcherReuse
   [junit4]   2> 609681 INFO  
(SUITE-TestSearcherReuse-seed#[FCA5EEE22995C8F9]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity 

[jira] [Resolved] (SOLR-5927) EnumField thinks DocValue support requires a default value or that the field be required

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-5927.

Resolution: Implemented

resolving this as "part of" SOLR-5846.

I'll slurp the test config fixes into the next patch for SOLR-11023

> EnumField thinks DocValue support requires a default value or that the field 
> be required
> 
>
> Key: SOLR-5927
> URL: https://issues.apache.org/jira/browse/SOLR-5927
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: SOLR-5927.patch
>
>
> {noformat}  
>   @Override
>   public void checkSchemaField(final SchemaField field) {
> if (field.hasDocValues() && !field.multiValued() && !(field.isRequired() 
> || field.getDefaultValue() != null)) {
>   throw new IllegalStateException("Field " + this + " has single-valued 
> doc values enabled, but has no default value and is not required");
> }
>   }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10372) TestStressCloudBlindAtomicUpdates.test_dv() failure: Failed synchronous update

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10372 at 7/24/17 6:32 PM:


This fails every day or two on ASF & Policeman Jenkins.  Here's another 
reproducible one from my Jenkins:

{noformat}
Checking out Revision d5c9ed0b99d5abf56d8f30ebaf3177b4c67bd4a7 
(refs/remotes/origin/branch_7_0)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestStressCloudBlindAtomicUpdates -Dtests.method=test_dv 
-Dtests.seed=1DBA6C72BF3E1122 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=it -Dtests.timezone=America/Detroit -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   4.73s J2 | TestStressCloudBlindAtomicUpdates.test_dv <<<
   [junit4]> Throwable #1: java.util.concurrent.ExecutionException: 
java.lang.RuntimeException: Error from server at 
http://127.0.0.1:54596/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1: Server Error
   [junit4]> request: 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A54596%2Fsolr%2Ftest_col_shard2_replica_n2%2F=javabin=2
   [junit4]> Remote error message: Failed synchronous update on shard 
StdNode: http://127.0.0.1:54596/solr/test_col_shard2_replica_n2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@69f635bb
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([1DBA6C72BF3E1122:2BAE0E3435632B33]:0)
   [junit4]>at 
java.util.concurrent.FutureTask.report(FutureTask.java:122)
   [junit4]>at 
java.util.concurrent.FutureTask.get(FutureTask.java:192)
   [junit4]>at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:283)
   [junit4]>at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:195)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: java.lang.RuntimeException: Error from server at 
http://127.0.0.1:54596/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1: Server Error
   [junit4]> request: 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A54596%2Fsolr%2Ftest_col_shard2_replica_n2%2F=javabin=2
   [junit4]> Remote error message: Failed synchronous update on shard 
StdNode: http://127.0.0.1:54596/solr/test_col_shard2_replica_n2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@69f635bb
   [junit4]>at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates$Worker.run(TestStressCloudBlindAtomicUpdates.java:411)
   [junit4]>at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
   [junit4]>at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)
   [junit4]>at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
   [junit4]>at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
   [junit4]>at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
   [junit4]>... 1 more
   [junit4]> Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:54596/solr/test_col: Async exception during 
distributed update: Error from server at 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1: Server Error
   [junit4]> request: 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A54596%2Fsolr%2Ftest_col_shard2_replica_n2%2F=javabin=2
   [junit4]> Remote error message: Failed synchronous update on shard 
StdNode: http://127.0.0.1:54596/solr/test_col_shard2_replica_n2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@69f635bb
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
   [junit4]>at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
   [junit4]>at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
   [junit4]>at 

[jira] [Comment Edited] (SOLR-10372) TestStressCloudBlindAtomicUpdates.test_dv() failure: Failed synchronous update

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10372 at 7/24/17 6:31 PM:


This fails every day or two on ASF & Policeman Jenkins.  Here's another 
reproducible one from my Jenkins:

{noformat}
Checking out Revision d5c9ed0b99d5abf56d8f30ebaf3177b4c67bd4a7 (refs/remotes/ori
gin/branch_7_0)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestStressCloudBlindAtomicUpdates -Dtests.method=test_dv 
-Dtests.seed=1DBA6C72BF3E1122 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=it -Dtests.timezone=America/Detroit -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   4.73s J2 | TestStressCloudBlindAtomicUpdates.test_dv <<<
   [junit4]> Throwable #1: java.util.concurrent.ExecutionException: 
java.lang.RuntimeException: Error from server at 
http://127.0.0.1:54596/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1: Server Error
   [junit4]> request: 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A54596%2Fsolr%2Ftest_col_shard2_replica_n2%2F=javabin=2
   [junit4]> Remote error message: Failed synchronous update on shard 
StdNode: http://127.0.0.1:54596/solr/test_col_shard2_replica_n2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@69f635bb
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([1DBA6C72BF3E1122:2BAE0E3435632B33]:0)
   [junit4]>at 
java.util.concurrent.FutureTask.report(FutureTask.java:122)
   [junit4]>at 
java.util.concurrent.FutureTask.get(FutureTask.java:192)
   [junit4]>at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:283)
   [junit4]>at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:195)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: java.lang.RuntimeException: Error from server at 
http://127.0.0.1:54596/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1: Server Error
   [junit4]> request: 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A54596%2Fsolr%2Ftest_col_shard2_replica_n2%2F=javabin=2
   [junit4]> Remote error message: Failed synchronous update on shard 
StdNode: http://127.0.0.1:54596/solr/test_col_shard2_replica_n2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@69f635bb
   [junit4]>at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates$Worker.run(TestStressCloudBlindAtomicUpdates.java:411)
   [junit4]>at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
   [junit4]>at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)
   [junit4]>at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
   [junit4]>at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
   [junit4]>at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
   [junit4]>... 1 more
   [junit4]> Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:54596/solr/test_col: Async exception during 
distributed update: Error from server at 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1: Server Error
   [junit4]> request: 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A54596%2Fsolr%2Ftest_col_shard2_replica_n2%2F=javabin=2
   [junit4]> Remote error message: Failed synchronous update on shard 
StdNode: http://127.0.0.1:54596/solr/test_col_shard2_replica_n2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@69f635bb
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
   [junit4]>at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
   [junit4]>at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
   [junit4]>at 

[jira] [Commented] (SOLR-10372) TestStressCloudBlindAtomicUpdates.test_dv() failure: Failed synchronous update

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10372:
---

This fails every day or two on ASF & Policeman Jenkins.  Here's another 
reproducible one from my Jenkins:

{noformat}
Checking out Revision d5c9ed0b99d5abf56d8f30ebaf3177b4c67bd4a7 (refs/remotes/ori
gin/branch_7_0)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestStressCloudBlindAtomicUpdates -Dtests.method=test_dv 
-Dtests.seed=1DBA6C72BF3E1122 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=it -Dtests.timezone=America/Detroit -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   4.73s J2 | TestStressCloudBlindAtomicUpdates.test_dv <<<
   [junit4]> Throwable #1: java.util.concurrent.ExecutionException: 
java.lang.RuntimeException: Error from server at 
http://127.0.0.1:54596/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1: Server Error
   [junit4]> request: 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A54596%2Fsolr%2Ftest_col_shard2_replica_n2%2F=javabin=2
   [junit4]> Remote error message: Failed synchronous update on shard 
StdNode: http://127.0.0.1:54596/solr/test_col_shard2_replica_n2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@69f635bb
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([1DBA6C72BF3E1122:2BAE0E3435632B33]:0)
   [junit4]>at 
java.util.concurrent.FutureTask.report(FutureTask.java:122)
   [junit4]>at 
java.util.concurrent.FutureTask.get(FutureTask.java:192)
   [junit4]>at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:283)
   [junit4]>at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:195)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: java.lang.RuntimeException: Error from server at 
http://127.0.0.1:54596/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1: Server Error
   [junit4]> request: 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A54596%2Fsolr%2Ftest_col_shard2_replica_n2%2F=javabin=2
   [junit4]> Remote error message: Failed synchronous update on shard 
StdNode: http://127.0.0.1:54596/solr/test_col_shard2_replica_n2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@69f635bb
   [junit4]>at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates$Worker.run(TestStressCloudBlindAtomicUpdates.java:411)
   [junit4]>at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
   [junit4]>at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)
   [junit4]>at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
   [junit4]>at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
   [junit4]>at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
   [junit4]>... 1 more
   [junit4]> Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:54596/solr/test_col: Async exception during 
distributed update: Error from server at 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1: Server Error
   [junit4]> request: 
http://127.0.0.1:41137/solr/test_col_shard2_replica_n1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A54596%2Fsolr%2Ftest_col_shard2_replica_n2%2F=javabin=2
   [junit4]> Remote error message: Failed synchronous update on shard 
StdNode: http://127.0.0.1:54596/solr/test_col_shard2_replica_n2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@69f635bb
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
   [junit4]>at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
   [junit4]>at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
   [junit4]>at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates$Worker.doRandomAtomicUpdate(TestStressCloudBlindAtomicUpdates.java:370)
   [junit4]>

[jira] [Issue Comment Deleted] (SOLR-11093) implement Points/Numeric support for graph query

[David Smiley (JIRA)]

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

David Smiley updated SOLR-11093:

Comment: was deleted

(was: Requiring DocValues for numerics on a GraphQuery is fine with me.  Is 
there a back-compat concern?

Maybe LongSet could use more javadocs if it's going to be shared.  The 
constructor should actually assert (or throw) that the argument is a power of 
2.  And it appears that the LongIterator returned *must* be used in a standard 
fashion in which hasNext is *always* called before next(); yes?  Since the set 
size is known, maybe it could be adjusted to use a countDown integer approach, 
yet still be very fast/simple?)

> implement Points/Numeric support for graph query
> 
>
> Key: SOLR-11093
> URL: https://issues.apache.org/jira/browse/SOLR-11093
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 7.0
>
> Attachments: SOLR-11093.patch, SOLR-11093.patch
>
>
> It looks like GraphQueryTest only has tests for strings.  We should add tests 
> for numeric fields and then enable points randomization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Issue Comment Deleted] (SOLR-11093) implement Points/Numeric support for graph query

[David Smiley (JIRA)]

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

David Smiley updated SOLR-11093:

Comment: was deleted

(was: Requiring DocValues for numerics on a GraphQuery is fine with me.  Is 
there a back-compat concern?

Maybe LongSet could use more javadocs if it's going to be shared.  The 
constructor should actually assert (or throw) that the argument is a power of 
2.  And it appears that the LongIterator returned *must* be used in a standard 
fashion in which hasNext is *always* called before next(); yes?  Since the set 
size is known, maybe it could be adjusted to use a countDown integer approach, 
yet still be very fast/simple?)

> implement Points/Numeric support for graph query
> 
>
> Key: SOLR-11093
> URL: https://issues.apache.org/jira/browse/SOLR-11093
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 7.0
>
> Attachments: SOLR-11093.patch, SOLR-11093.patch
>
>
> It looks like GraphQueryTest only has tests for strings.  We should add tests 
> for numeric fields and then enable points randomization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10229) See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests

[Erick Erickson (JIRA)]

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

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

bq: I take it reducing test solrconfig.xml files is out of scope of this issue?
Yep. Although I'm working out a couple of interesting bits, e.g. a sys var to 
turn on and off update logs.

bq: The latest patch seems to be a patch to be applied on top of a previous 
version of the patch, which is very difficult to consume with fresh eyes. Can a 
fresh all-inclusive patch please be attached?
Attached, I'll master Git yet.

bq: in solrconfig-id-version.xml: why change df from text field to id?
Just to have a field there that is always present. I think core startup failed 
if there was no actual definition for the df field. May not have been necessary.

bq: RE copying field types from uber: how are resources like synonyms.txt 
handled? I suspect it "just works" because all these configs are actually in 
the same dir and thus is kinda the same config?
Hasn't been thought through frankly. But so far you're right, it "just works" 
because all the files are in the source tree. Yet another thing to clean up as 
people start to use this.

> See what it would take to shift many of our one-off schemas used for testing 
> to managed schema and construct them as part of the tests
> --
>
> Key: SOLR-10229
> URL: https://issues.apache.org/jira/browse/SOLR-10229
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, 
> SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, 
> SOLR-10229.patch, SOLR-10229-straw-man.patch
>
>
> The test schema files are intimidating. There are about a zillion of them, 
> and making a change in any of them risks breaking some _other_ test. That 
> leaves people three choices:
> 1> add what they need to some existing schema. Which makes schemas bigger and 
> bigger and bigger.
> 2> create a new schema file, adding to the proliferation thereof.
> 3> Look through all the existing tests to see if they have something that 
> works.
> The recent work on LUCENE-7705 is a case in point. We're adding a maxLen 
> parameter to some tokenizers. Putting those parameters into any of the 
> existing schemas, especially to test < 255 char tokens is virtually 
> guaranteed to break other tests, so the only safe thing to do is make another 
> schema file. Adding to the multiplication of files.
> As part of SOLR-5260 I tried creating the schema on the fly rather than 
> creating a new static schema file and it's not hard. WDYT about making this 
> into some better thought-out utility? 
> At present, this is pretty fuzzy, I wanted to get some reactions before 
> putting much effort into it. I expect that the utility methods would 
> eventually get a bunch of canned types. It's reasonably straightforward for 
> primitive types, if lengthy. But when you get into solr.TextField-based types 
> it gets less straight-forward.
> We could manage to just move the "intimidation" from the plethora of schema 
> files to a zillion fieldTypes in the utility to choose from...
> Also, forcing every test to define the fields up-front is arguably less 
> convenient than just having _some_ canned schemas we can use. And erroneous 
> schemas to test failure modes are probably not very good fits for any such 
> framework.
> [~steve_rowe] and [~hossman_luc...@fucit.org] in particular might have 
> something to say.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

via C++, determine if a java object is null

[William Schilp]

i'm using JCC to interface a C++ application to a java application. in the
java application a method can return a "null" java object. i need to
determine if the returned object is a null object. i do not see a way to do
this via the JCC interface. the object i get on the C++ side is an object
residing in memory space. so as far as C++ is concerned, the object is not
NULL as it points to a valid memory address, ie not 0.
so, how do i determine if the returned object is a null java object?

bill

[jira] [Commented] (SOLR-11093) implement Points/Numeric support for graph query

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11093:
-

Requiring DocValues for numerics on a GraphQuery is fine with me.  Is there a 
back-compat concern?

Maybe LongSet could use more javadocs if it's going to be shared.  The 
constructor should actually assert (or throw) that the argument is a power of 
2.  And it appears that the LongIterator returned *must* be used in a standard 
fashion in which hasNext is *always* called before next(); yes?  Since the set 
size is known, maybe it could be adjusted to use a countDown integer approach, 
yet still be very fast/simple?

> implement Points/Numeric support for graph query
> 
>
> Key: SOLR-11093
> URL: https://issues.apache.org/jira/browse/SOLR-11093
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 7.0
>
> Attachments: SOLR-11093.patch, SOLR-11093.patch
>
>
> It looks like GraphQueryTest only has tests for strings.  We should add tests 
> for numeric fields and then enable points randomization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-10494.
-
   Resolution: Fixed
 Assignee: Hoss Man
Fix Version/s: 7.1
   master (8.0)

backport was while jira was down, so gitbot didn't note all the commits...

master - 6a59253ec34e9e08d6b2306b51c81199d3f3d828
7x - 8ea4c0790d003efafe893db3d6ab33ad494a1213
7_0 - 477c2188ef9f2c82902cf4ed1ccb91bfc6ab5ebf




> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.0
>Reporter: Trey Grainger
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494.branch_7x.patch, 
> SOLR-10494.patch, SOLR-10494.patch, SOLR-10494.patch, 
> SOLR-10494-withdocs.patch, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.HardAutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([894EFB234C1AFE08:339C945BCF34101D]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:886)
at 
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:879)
... 40 more




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

Request for Lucene.net 4.8 Beta for .Net Core

[rohit kumar]

Hi,

I am Rohit Kumar Rapolu from Hyderabad, India.  We are working on our
academic project which is web application on .net core framework.  We
trying to implement full text search in our application.  We heard Lucene
is the best for it.  Could we have Lucene 4.8 Beta version which supports
on .net core 1.1 framework.  Could you please help us on this.


Regards

-- 

*RegardsRohit*

[jira] [Commented] (SOLR-11093) implement Points/Numeric support for graph query

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11093:
-

Requiring DocValues for numerics on a GraphQuery is fine with me.  Is there a 
back-compat concern?

Maybe LongSet could use more javadocs if it's going to be shared.  The 
constructor should actually assert (or throw) that the argument is a power of 
2.  And it appears that the LongIterator returned *must* be used in a standard 
fashion in which hasNext is *always* called before next(); yes?  Since the set 
size is known, maybe it could be adjusted to use a countDown integer approach, 
yet still be very fast/simple?

> implement Points/Numeric support for graph query
> 
>
> Key: SOLR-11093
> URL: https://issues.apache.org/jira/browse/SOLR-11093
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 7.0
>
> Attachments: SOLR-11093.patch, SOLR-11093.patch
>
>
> It looks like GraphQueryTest only has tests for strings.  We should add tests 
> for numeric fields and then enable points randomization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11093) implement Points/Numeric support for graph query

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11093:
-

Requiring DocValues for numerics on a GraphQuery is fine with me.  Is there a 
back-compat concern?

Maybe LongSet could use more javadocs if it's going to be shared.  The 
constructor should actually assert (or throw) that the argument is a power of 
2.  And it appears that the LongIterator returned *must* be used in a standard 
fashion in which hasNext is *always* called before next(); yes?  Since the set 
size is known, maybe it could be adjusted to use a countDown integer approach, 
yet still be very fast/simple?

> implement Points/Numeric support for graph query
> 
>
> Key: SOLR-11093
> URL: https://issues.apache.org/jira/browse/SOLR-11093
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 7.0
>
> Attachments: SOLR-11093.patch, SOLR-11093.patch
>
>
> It looks like GraphQueryTest only has tests for strings.  We should add tests 
> for numeric fields and then enable points randomization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10494:


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

SOLR-10494: Make default response format JSON (wt=json), and also indent text 
responses formats (indent=on) by default


> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.0
>Reporter: Trey Grainger
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494.branch_7x.patch, 
> SOLR-10494.patch, SOLR-10494.patch, SOLR-10494.patch, 
> SOLR-10494-withdocs.patch, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 72 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/72/

1 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest.test

Error Message:
Mismatch in counts between replicas

Stack Trace:
java.lang.AssertionError: Mismatch in counts between replicas
at 
__randomizedtesting.SeedInfo.seed([1DCAF47C97CBD60:8988909D6780D098]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.RecoveryZkTest.assertShardConsistency(RecoveryZkTest.java:143)
at org.apache.solr.cloud.RecoveryZkTest.test(RecoveryZkTest.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12734 lines...]
   [junit4] Suite: org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/solr/build/solr-core/test/J0/temp/solr.cloud.hdfs.HdfsRecoveryZkTest_1DCAF47C97CBD60-001/init-core-data-001
   [junit4]   2> 3195771 WARN  

[jira] [Updated] (SOLR-11093) implement Points/Numeric support for graph query

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-11093:

Attachment: SOLR-11093.patch

Here's an updated draft patch that moves LongSet and LongIterator to the util 
package, uses them in conjunction with numeric docvalues to collect numeric 
values, and then uses points fields to create a set query.
Doesn't yet work for some reason... I'm digging into why.

> implement Points/Numeric support for graph query
> 
>
> Key: SOLR-11093
> URL: https://issues.apache.org/jira/browse/SOLR-11093
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 7.0
>
> Attachments: SOLR-11093.patch, SOLR-11093.patch
>
>
> It looks like GraphQueryTest only has tests for strings.  We should add tests 
> for numeric fields and then enable points randomization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11138) JSON terms facet counts change when changing limit parameter

[Yonik Seeley (JIRA)]

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

Yonik Seeley resolved SOLR-11138.
-
Resolution: Duplicate

> JSON terms facet counts change when changing limit parameter
> 
>
> Key: SOLR-11138
> URL: https://issues.apache.org/jira/browse/SOLR-11138
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 5.5.2
>Reporter: def onion
>
> We are running a single node Solr 5.5.2. When querying for facets via the 
> json facets api, the count for the buckets changes when the limit parameter 
> of the requested terms facet is edited.
> The field we facet over is a multivalued keyword field:
> {code:xml}
> 
>
>   
>
> 
>  stored="true" termVectors="false" multiValued="true" />
> {code}
> The queries that produce the different results are: 
> *facet.limit=10*
> {code:javascript}
> {
>"params": {
>   "start": 0,
>   "rows": 0
>},
>"facet": {
>   "nerPersonFacet": {
>  "field": "KLAS_NAME_10045_KEY_MULTI",
>  "limit": 10,
>  "type": "terms"
>   }
>}
> }
> {code}
> *Result:*
> {code:javascript}
> :   "facets":
> :   {
> :   :   "count":26588990,
> :   :   "nerPersonFacet":
> :   :   {
> :   :   :   "buckets":
> :   :   :   [
> :   :   :   :   {
> :   :   :   :   :   "val":"Angela Merkel",
> :   :   :   :   :   "count":32179
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Donald Trump",
> :   :   :   :   :   "count":30418
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Hillary Clinton",
> :   :   :   :   :   "count":30305
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Barack Obama",
> :   :   :   :   :   "count":25683
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Pope Francis",
> :   :   :   :   :   "count":22323
> :   :   :   :   },
> {code}
> *facet.limit=15*
> {code:javascript}
> {
>"params": {
>   "start": 0,
>   "rows": 0
>},
>"facet": {
>   "nerPersonFacet": {
>  "field": "KLAS_NAME_10045_KEY_MULTI",
>  "limit": 15,
>  "type": "terms"
>   }
>}
> }
> {code}
> *Results:*
> {code:javascript}
> :   "facets":
> :   {
> :   :   "count":26588990,
> :   :   "nerPersonFacet":
> :   :   {
> :   :   :   "buckets":
> :   :   :   [
> :   :   :   :   {
> :   :   :   :   :   "val":"Angela Merkel",
> :   :   :   :   :   "count":32179
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Barack Obama",
> :   :   :   :   :   "count":30922
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Donald Trump",
> :   :   :   :   :   "count":30418
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Hillary Clinton",
> :   :   :   :   :   "count":30305
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Pope Francis",
> :   :   :   :   :   "count":22323
> :   :   :   :   },
> {code}
> The count for the bucket "Barack Obama" changes significantly from 25683 to 
> 30922. When querying for KLAS_NAME_10045_KEY_MULTI:"Barack Obama" the count 
> is 30922.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11138) JSON terms facet counts change when changing limit parameter

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-11138:
-

In the upcomming Solr 7, you can add "refine:true" to a field facet, and a 
second phase will retrieve missing bucket statistics to ensure accurate counts.
See SOLR-7452 for more info.

> JSON terms facet counts change when changing limit parameter
> 
>
> Key: SOLR-11138
> URL: https://issues.apache.org/jira/browse/SOLR-11138
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 5.5.2
>Reporter: def onion
>
> We are running a single node Solr 5.5.2. When querying for facets via the 
> json facets api, the count for the buckets changes when the limit parameter 
> of the requested terms facet is edited.
> The field we facet over is a multivalued keyword field:
> {code:xml}
> 
>
>   
>
> 
>  stored="true" termVectors="false" multiValued="true" />
> {code}
> The queries that produce the different results are: 
> *facet.limit=10*
> {code:javascript}
> {
>"params": {
>   "start": 0,
>   "rows": 0
>},
>"facet": {
>   "nerPersonFacet": {
>  "field": "KLAS_NAME_10045_KEY_MULTI",
>  "limit": 10,
>  "type": "terms"
>   }
>}
> }
> {code}
> *Result:*
> {code:javascript}
> :   "facets":
> :   {
> :   :   "count":26588990,
> :   :   "nerPersonFacet":
> :   :   {
> :   :   :   "buckets":
> :   :   :   [
> :   :   :   :   {
> :   :   :   :   :   "val":"Angela Merkel",
> :   :   :   :   :   "count":32179
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Donald Trump",
> :   :   :   :   :   "count":30418
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Hillary Clinton",
> :   :   :   :   :   "count":30305
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Barack Obama",
> :   :   :   :   :   "count":25683
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Pope Francis",
> :   :   :   :   :   "count":22323
> :   :   :   :   },
> {code}
> *facet.limit=15*
> {code:javascript}
> {
>"params": {
>   "start": 0,
>   "rows": 0
>},
>"facet": {
>   "nerPersonFacet": {
>  "field": "KLAS_NAME_10045_KEY_MULTI",
>  "limit": 15,
>  "type": "terms"
>   }
>}
> }
> {code}
> *Results:*
> {code:javascript}
> :   "facets":
> :   {
> :   :   "count":26588990,
> :   :   "nerPersonFacet":
> :   :   {
> :   :   :   "buckets":
> :   :   :   [
> :   :   :   :   {
> :   :   :   :   :   "val":"Angela Merkel",
> :   :   :   :   :   "count":32179
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Barack Obama",
> :   :   :   :   :   "count":30922
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Donald Trump",
> :   :   :   :   :   "count":30418
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Hillary Clinton",
> :   :   :   :   :   "count":30305
> :   :   :   :   },
> :   :   :   :   {
> :   :   :   :   :   "val":"Pope Francis",
> :   :   :   :   :   "count":22323
> :   :   :   :   },
> {code}
> The count for the bucket "Barack Obama" changes significantly from 25683 to 
> 30922. When querying for KLAS_NAME_10045_KEY_MULTI:"Barack Obama" the count 
> is 30922.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11138) JSON terms facet counts change when changing limit parameter

[def onion (JIRA)]

def onion created SOLR-11138:


 Summary: JSON terms facet counts change when changing limit 
parameter
 Key: SOLR-11138
 URL: https://issues.apache.org/jira/browse/SOLR-11138
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Facet Module
Affects Versions: 5.5.2
Reporter: def onion


We are running a single node Solr 5.5.2. When querying for facets via the json 
facets api, the count for the buckets changes when the limit parameter of the 
requested terms facet is edited.
The field we facet over is a multivalued keyword field:
{code:xml}

   
  
   



{code}

The queries that produce the different results are: 
*facet.limit=10*
{code:javascript}
{
   "params": {
  "start": 0,
  "rows": 0
   },
   "facet": {
  "nerPersonFacet": {
 "field": "KLAS_NAME_10045_KEY_MULTI",
 "limit": 10,
 "type": "terms"
  }
   }
}
{code}
*Result:*

{code:javascript}
:   "facets":
:   {
:   :   "count":26588990,
:   :   "nerPersonFacet":
:   :   {
:   :   :   "buckets":
:   :   :   [
:   :   :   :   {
:   :   :   :   :   "val":"Angela Merkel",
:   :   :   :   :   "count":32179
:   :   :   :   },
:   :   :   :   {
:   :   :   :   :   "val":"Donald Trump",
:   :   :   :   :   "count":30418
:   :   :   :   },
:   :   :   :   {
:   :   :   :   :   "val":"Hillary Clinton",
:   :   :   :   :   "count":30305
:   :   :   :   },
:   :   :   :   {
:   :   :   :   :   "val":"Barack Obama",
:   :   :   :   :   "count":25683
:   :   :   :   },
:   :   :   :   {
:   :   :   :   :   "val":"Pope Francis",
:   :   :   :   :   "count":22323
:   :   :   :   },
{code}
*facet.limit=15*
{code:javascript}
{
   "params": {
  "start": 0,
  "rows": 0
   },
   "facet": {
  "nerPersonFacet": {
 "field": "KLAS_NAME_10045_KEY_MULTI",
 "limit": 15,
 "type": "terms"
  }
   }
}
{code}
*Results:*
{code:javascript}
:   "facets":
:   {
:   :   "count":26588990,
:   :   "nerPersonFacet":
:   :   {
:   :   :   "buckets":
:   :   :   [
:   :   :   :   {
:   :   :   :   :   "val":"Angela Merkel",
:   :   :   :   :   "count":32179
:   :   :   :   },
:   :   :   :   {
:   :   :   :   :   "val":"Barack Obama",
:   :   :   :   :   "count":30922
:   :   :   :   },
:   :   :   :   {
:   :   :   :   :   "val":"Donald Trump",
:   :   :   :   :   "count":30418
:   :   :   :   },
:   :   :   :   {
:   :   :   :   :   "val":"Hillary Clinton",
:   :   :   :   :   "count":30305
:   :   :   :   },
:   :   :   :   {
:   :   :   :   :   "val":"Pope Francis",
:   :   :   :   :   "count":22323
:   :   :   :   },
{code}

The count for the bucket "Barack Obama" changes significantly from 25683 to 
30922. When querying for KLAS_NAME_10045_KEY_MULTI:"Barack Obama" the count is 
30922.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.HardAutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([94DB7A043F8BC34A:2E09157CBCA52D5F]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:879)
at 
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:872)
... 40 more




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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 96 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/96/

2 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testSplitShard

Error Message:
Expected 5 slices to be active null Live Nodes: [127.0.0.1:41335_solr, 
127.0.0.1:46163_solr, 127.0.0.1:32862_solr, 127.0.0.1:35371_solr] Last 
available state: 
DocCollection(solrj_test_splitshard//collections/solrj_test_splitshard/state.json/32)={
   "pullReplicas":"0",   "replicationFactor":"1",   "shards":{ "shard1":{   
"range":"8000-",   "state":"inactive",   
"replicas":{"core_node1":{   
"core":"solrj_test_splitshard_shard1_replica_n1",   
"base_url":"http://127.0.0.1:32862/solr;,   
"node_name":"127.0.0.1:32862_solr",   "state":"active",   
"type":"NRT",   "leader":"true"}}}, "shard2":{   
"range":"0-7fff",   "state":"active",   "replicas":{"core_node2":{  
 "core":"solrj_test_splitshard_shard2_replica_n1",   
"base_url":"http://127.0.0.1:41335/solr;,   
"node_name":"127.0.0.1:41335_solr",   "state":"active",   
"type":"NRT",   "leader":"true"}}}, "shard1_0":{   
"range":"8000-95dd",   "state":"active",   
"replicas":{"core_node5":{   
"core":"solrj_test_splitshard_shard1_0_replica_n1",   
"base_url":"http://127.0.0.1:32862/solr;,   
"node_name":"127.0.0.1:32862_solr",   "state":"active",   
"type":"NRT",   "leader":"true"}}}, "shard1_1":{   
"range":"95de-95de",   "state":"active",   
"replicas":{"core_node6":{   
"core":"solrj_test_splitshard_shard1_1_replica_n1",   
"base_url":"http://127.0.0.1:32862/solr;,   
"node_name":"127.0.0.1:32862_solr",   "state":"active",   
"type":"NRT",   "leader":"true"}}}, "shard1_2":{   
"range":"95df-",   "state":"active",   
"replicas":{"core_node7":{   
"core":"solrj_test_splitshard_shard1_2_replica_n1",   
"base_url":"http://127.0.0.1:32862/solr;,   
"node_name":"127.0.0.1:32862_solr",   "state":"active",   
"type":"NRT",   "leader":"true",   "router":{"name":"compositeId"}, 
  "maxShardsPerNode":"1",   "autoAddReplicas":"false",   "nrtReplicas":"1",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Expected 5 slices to be active
null
Live Nodes: [127.0.0.1:41335_solr, 127.0.0.1:46163_solr, 127.0.0.1:32862_solr, 
127.0.0.1:35371_solr]
Last available state: 
DocCollection(solrj_test_splitshard//collections/solrj_test_splitshard/state.json/32)={
  "pullReplicas":"0",
  "replicationFactor":"1",
  "shards":{
"shard1":{
  "range":"8000-",
  "state":"inactive",
  "replicas":{"core_node1":{
  "core":"solrj_test_splitshard_shard1_replica_n1",
  "base_url":"http://127.0.0.1:32862/solr;,
  "node_name":"127.0.0.1:32862_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true"}}},
"shard2":{
  "range":"0-7fff",
  "state":"active",
  "replicas":{"core_node2":{
  "core":"solrj_test_splitshard_shard2_replica_n1",
  "base_url":"http://127.0.0.1:41335/solr;,
  "node_name":"127.0.0.1:41335_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true"}}},
"shard1_0":{
  "range":"8000-95dd",
  "state":"active",
  "replicas":{"core_node5":{
  "core":"solrj_test_splitshard_shard1_0_replica_n1",
  "base_url":"http://127.0.0.1:32862/solr;,
  "node_name":"127.0.0.1:32862_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true"}}},
"shard1_1":{
  "range":"95de-95de",
  "state":"active",
  "replicas":{"core_node6":{
  "core":"solrj_test_splitshard_shard1_1_replica_n1",
  "base_url":"http://127.0.0.1:32862/solr;,
  "node_name":"127.0.0.1:32862_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true"}}},
"shard1_2":{
  "range":"95df-",
  "state":"active",
  "replicas":{"core_node7":{
  "core":"solrj_test_splitshard_shard1_2_replica_n1",
  "base_url":"http://127.0.0.1:32862/solr;,
  "node_name":"127.0.0.1:32862_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"1",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([E22E221696F40F14:39248F7A880133AB]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testSplitShard(CollectionsAPISolrJTest.java:232)
at 

Re: [JENKINS] Lucene-Solr-7.0-Linux (64bit/jdk1.8.0_131) - Build # 74 - Unstable!

[Alan Woodward]

Thanks David!

Alan Woodward
www.flax.co.uk


> On 24 Jul 2017, at 04:00, David Smiley  wrote:
> 
> Alan fixed this on master a week ago but the fix wasn't cherry picked to 7x & 
> 7.0 so I did so now.
> 
> On Sun, Jul 23, 2017 at 5:01 PM Policeman Jenkins Server  > wrote:
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/74/ 
> 
> Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseG1GC
> 
> 1 tests failed.
> FAILED:  org.apache.lucene.spatial.DistanceStrategyTest.testDistanceOrder 
> {strategy=serialized}
> 
> Error Message:
> 
> 
> Stack Trace:
> java.lang.NullPointerException
> at 
> __randomizedtesting.SeedInfo.seed([7D7A85DBA167C639:FF12601D8B89B891]:0)
> at 
> org.apache.lucene.spatial.serialized.SerializedDVStrategy$ShapeDocValueSource$1.advanceExact(SerializedDVStrategy.java:186)
> at 
> org.apache.lucene.spatial.util.DistanceToShapeValueSource$1.advanceExact(DistanceToShapeValueSource.java:73)
> at 
> org.apache.lucene.search.DoubleValues$1.advanceExact(DoubleValues.java:53)
> at 
> org.apache.lucene.spatial.StrategyTestCase.checkValueSource(StrategyTestCase.java:219)
> at 
> org.apache.lucene.spatial.DistanceStrategyTest.checkDistValueSource(DistanceStrategyTest.java:114)
> at 
> org.apache.lucene.spatial.DistanceStrategyTest.testDistanceOrder(DistanceStrategyTest.java:89)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
> at 
> org.apache.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:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
> at 
> 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] [Commented] (SOLR-8736) GET operations on fields, dynamicFields, fieldTypes, copyField should work

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8736: these tests should have been removed


> GET operations on fields, dynamicFields, fieldTypes, copyField should work
> --
>
> Key: SOLR-8736
> URL: https://issues.apache.org/jira/browse/SOLR-8736
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.0, 6.1, 7.0
>
> Attachments: SOLR-8736.patch
>
>
> Commits under this issue changed the implementation for handling GET 
> operations on the following URL paths: {{schema/fields}}, 
> {{schema/dynamicfields}}, {{schema/fieldtypes}}, and {{schema/copyfields}}.
> As part of the changes, the following functionality was removed, as of Solr 
> 6.0.0:
> * {{schema/copyfields}}:
> ** The following information is no longer output:
> *** {{destDynamicBase}}: the matching dynamic field pattern for the 
> destination
> *** {{sourceDynamicBase}}: the matching dynamic field pattern for the source
> ** The following request parameters are no longer supported:
> *** {{dest.fl}}: include only copyFields that have one of these as a 
> destination
> *** {{source.fl}}: include only copyFields that have one of these as a source
> * {{schema/dynamicfields}}:
> ** The following request parameters are no longer supported:
> *** {{fl}}: a comma and/or space separated list of dynamic field patterns to 
> include 
> * {{schema/fields}} and {{schema/fields/_fieldname_}}:
> ** The following information is no longer output:
> *** {{dynamicBase}}: the matching dynamic field pattern, if the 
> {{includeDynamic}} param is given (see below) 
> ** The following request parameters are no longer supported:
> *** {{fl}}: (only supported without {{/_fieldname_}}): a comma and/or space 
> separated list of fields to include 
> *** {{includeDynamic}}: output the matching dynamic field pattern as 
> {{dynamicBase}}, if {{_fieldname_}}, or field(s) listed in {{fl}} param, are 
> not explicitly declared in the schema
> * {{schema/fieldtypes}} and {{schema/fieldtypes/_typename_}}:
> ** The following information is no longer output: 
> *** {{fields}}: the fields with the given field type
> *** {{dynamicFields}}: the dynamic fields with the given field type  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8736) GET operations on fields, dynamicFields, fieldTypes, copyField should work

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8736: these tests should have been removed


> GET operations on fields, dynamicFields, fieldTypes, copyField should work
> --
>
> Key: SOLR-8736
> URL: https://issues.apache.org/jira/browse/SOLR-8736
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.0, 6.1, 7.0
>
> Attachments: SOLR-8736.patch
>
>
> Commits under this issue changed the implementation for handling GET 
> operations on the following URL paths: {{schema/fields}}, 
> {{schema/dynamicfields}}, {{schema/fieldtypes}}, and {{schema/copyfields}}.
> As part of the changes, the following functionality was removed, as of Solr 
> 6.0.0:
> * {{schema/copyfields}}:
> ** The following information is no longer output:
> *** {{destDynamicBase}}: the matching dynamic field pattern for the 
> destination
> *** {{sourceDynamicBase}}: the matching dynamic field pattern for the source
> ** The following request parameters are no longer supported:
> *** {{dest.fl}}: include only copyFields that have one of these as a 
> destination
> *** {{source.fl}}: include only copyFields that have one of these as a source
> * {{schema/dynamicfields}}:
> ** The following request parameters are no longer supported:
> *** {{fl}}: a comma and/or space separated list of dynamic field patterns to 
> include 
> * {{schema/fields}} and {{schema/fields/_fieldname_}}:
> ** The following information is no longer output:
> *** {{dynamicBase}}: the matching dynamic field pattern, if the 
> {{includeDynamic}} param is given (see below) 
> ** The following request parameters are no longer supported:
> *** {{fl}}: (only supported without {{/_fieldname_}}): a comma and/or space 
> separated list of fields to include 
> *** {{includeDynamic}}: output the matching dynamic field pattern as 
> {{dynamicBase}}, if {{_fieldname_}}, or field(s) listed in {{fl}} param, are 
> not explicitly declared in the schema
> * {{schema/fieldtypes}} and {{schema/fieldtypes/_typename_}}:
> ** The following information is no longer output: 
> *** {{fields}}: the fields with the given field type
> *** {{dynamicFields}}: the dynamic fields with the given field type  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 71 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/71/

1 tests failed.
FAILED:  org.apache.solr.client.solrj.TestSolrJErrorHandling.testWithXml

Error Message:
expected:<768> but was:<758>

Stack Trace:
java.lang.AssertionError: expected:<768> but was:<758>
at 
__randomizedtesting.SeedInfo.seed([F755005CC0180749:5CB7B9AA421E1E24]: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.client.solrj.TestSolrJErrorHandling.doThreads(TestSolrJErrorHandling.java:185)
at 
org.apache.solr.client.solrj.TestSolrJErrorHandling.doIt(TestSolrJErrorHandling.java:200)
at 
org.apache.solr.client.solrj.TestSolrJErrorHandling.testWithXml(TestSolrJErrorHandling.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

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

[Apache Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:46115/solr/collection1: Expected mime 
type application/octet-stream but got text/html.Error 
500HTTP ERROR: 500 Problem accessing 
/solr/collection1/select. Reason: java.lang.AssertionError 
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028   

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:46115/solr/collection1: Expected mime type 
application/octet-stream but got text/html. 


Error 500 


HTTP ERROR: 500
Problem accessing /solr/collection1/select. Reason:
java.lang.AssertionError
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028



at 
__randomizedtesting.SeedInfo.seed([872443BC748266E6:27CEED31AFC948C6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:588)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:663)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:638)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.client.solrj.TestLBHttpSolrClient.testTwoServers(TestLBHttpSolrClient.java:191)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxTime

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([2C3C29D4212BA24C:B6C85436BFB13E70]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:879)
at 
org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:270)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:872)
... 40 more


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

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

Stack Trace:
java.lang.AssertionError: expected:<2> but 

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

[Policeman Jenkins Server]

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

11 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI

Error Message:
Could not find collection : implicitcoll

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : implicitcoll
at 
__randomizedtesting.SeedInfo.seed([D54B897E7B0646CE:BFAA0715469CF0B6]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:247)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.CustomCollectionTest.testCreateShardRepFactor

Error Message:
Error from server at http://127.0.0.1:53994/solr: Could not find 

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 15 - Still unstable

[Apache Jenkins Server]

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

7 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.CdcrBootstrapTest

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore, 
MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:478)  
at org.apache.solr.core.SolrCore.(SolrCore.java:928)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:843)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:972) 
 at org.apache.solr.core.CoreContainer.create(CoreContainer.java:908)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:384)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:745)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:726)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:507)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.execute(ExecuteProduceConsume.java:100)
  at org.eclipse.jetty.io.ManagedSelector.run(ManagedSelector.java:147)  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:484)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:332) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:419) 
 at 
org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:757)
  at 
org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:712)
  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 

[JENKINS] Lucene-Solr-7.0-Windows (32bit/jdk1.8.0_131) - Build # 41 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Windows/41/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.schema.TestUseDocValuesAsStored2

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_645945F6B2B60A6E-001\tempDir-003:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_645945F6B2B60A6E-001\tempDir-003
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_645945F6B2B60A6E-001\tempDir-003:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_645945F6B2B60A6E-001\tempDir-003

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




Build Log:
[...truncated 13002 lines...]
   [junit4] Suite: org.apache.solr.schema.TestUseDocValuesAsStored2
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_645945F6B2B60A6E-001\init-core-data-001
   [junit4]   2> 2484959 WARN  
(SUITE-TestUseDocValuesAsStored2-seed#[645945F6B2B60A6E]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2409 numCloses=2409
   [junit4]   2> 2484960 INFO  
(SUITE-TestUseDocValuesAsStored2-seed#[645945F6B2B60A6E]-worker) [] 
o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) 
w/NUMERIC_DOCVALUES_SYSPROP=true
   [junit4]   2> 2484963 INFO  
(SUITE-TestUseDocValuesAsStored2-seed#[645945F6B2B60A6E]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 2484965 INFO  
(TEST-TestUseDocValuesAsStored2.testSchemaAPI-seed#[645945F6B2B60A6E]) [] 
o.a.s.SolrTestCaseJ4 ###Starting testSchemaAPI
   [junit4]   2> 2485453 INFO  
(TEST-TestUseDocValuesAsStored2.testSchemaAPI-seed#[645945F6B2B60A6E]) [] 
o.a.s.SolrTestCaseJ4 initCore
   [junit4]   2> 2485453 INFO  
(TEST-TestUseDocValuesAsStored2.testSchemaAPI-seed#[645945F6B2B60A6E]) [] 
o.a.s.SolrTestCaseJ4 initCore end
   [junit4]   2> 2485453 INFO  
(TEST-TestUseDocValuesAsStored2.testSchemaAPI-seed#[645945F6B2B60A6E]) [] 
o.a.s.SolrTestCaseJ4 Writing core.properties file to 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_645945F6B2B60A6E-001\tempDir-003\cores\core
   [junit4]   2> 2485458 INFO  
(TEST-TestUseDocValuesAsStored2.testSchemaAPI-seed#[645945F6B2B60A6E]) [] 
o.e.j.s.Server jetty-9.3.14.v20161028
   [junit4]   2> 2485459 INFO  
(TEST-TestUseDocValuesAsStored2.testSchemaAPI-seed#[645945F6B2B60A6E]) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@10aa8c6{/solr,null,AVAILABLE}
   [junit4]   2> 2485461 INFO  
(TEST-TestUseDocValuesAsStored2.testSchemaAPI-seed#[645945F6B2B60A6E]) [] 
o.e.j.s.AbstractConnector Started ServerConnector@19b6226{SSL,[ssl, 
http/1.1]}{127.0.0.1:53724}
   [junit4]   2> 2485461 INFO  
(TEST-TestUseDocValuesAsStored2.testSchemaAPI-seed#[645945F6B2B60A6E]) [] 
o.e.j.s.Server Started @2488489ms
   [junit4]   2> 2485461 INFO  
(TEST-TestUseDocValuesAsStored2.testSchemaAPI-seed#[645945F6B2B60A6E]) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: