[jira] [Commented] (SOLR-8030) Transaction log does not store the update chain used for updates

[Ludovic Boutros (JIRA)]

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

Ludovic Boutros commented on SOLR-8030:
---

I will update the test in order to control pre-distributed processors (buffered 
updates during recovery).
I will also rename the processor which locks the replay with a more explicit 
name.

I propose to add one or two flags to the command status to be able to detect 
already processed update commands (before and after distribution).
They should be set in the RunUpdateProcessor and in the 
DistributedUpdateProcessor.

For buffered updates, the replay should start processing update from the 
DistributedUpdateProcessor.
For the other updates, the replay should only use the RunUpdateProcessor.

For the update chain, I think the name could be stored in the tlog and reused 
during replay (With perhaps the last chain cached to prevent the search in the 
update chain map...).



> Transaction log does not store the update chain used for updates
> 
>
> Key: SOLR-8030
> URL: https://issues.apache.org/jira/browse/SOLR-8030
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Ludovic Boutros
> Attachments: SOLR-8030-test.patch
>
>
> Transaction Log does not store the update chain used during updates.
> Therefore tLog uses the default update chain during log replay.
> If we implement custom update logic with multiple update chains, the log 
> replay could break this logic.



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

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

[jira] [Commented] (SOLR-3724) No highlighting for phrases with stop words when FVH is used

[Eran Sela (JIRA)]

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

Eran Sela commented on SOLR-3724:
-

This is basic functionality for highlighter, is there an expected date for a 
fix ?

> No highlighting for phrases with stop words when FVH is used
> 
>
> Key: SOLR-3724
> URL: https://issues.apache.org/jira/browse/SOLR-3724
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 3.6.1
>Reporter: Igor Motov
>
> To reproduce:
> - Index text "foo and bar" into the field "message" with the following schema 
> :
> {code:xml}
> 
>   
> 
>  positionIncrementGap="100">
>   
> 
>  words="lang/stopwords_en.txt" enablePositionIncrements="true"/>
> 
>   
>   
> 
>  words="lang/stopwords_en.txt" enablePositionIncrements="true"/>
>  ignoreCase="true" expand="true"/>
> 
>   
> 
> 
>   
>   
> 
>  required="true" termVectors="true" termPositions="true" termOffsets="true"/>
> 
>   
>   
> 
> {code}
> - Search for the {{message:"foo and bar"}} with highlighting enabled and 
> {{hl.useFastVectorHighlighter=true}}
> - The text is not highlighted
> Standard highlighter works fine. If I set {{enablePositionIncrements=false}} 
> in the analyzer, FVH starts to highlight the entire phrase. You can find 
> complete schema and test data files that I used to reproduce this issue here: 
> https://gist.github.com/3279879 



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

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

[jira] [Commented] (SOLR-4449) Enable backup requests for the internal solr load balancer

[Jeff Wartes (JIRA)]

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

Jeff Wartes commented on SOLR-4449:
---

I pulled this patch out into a freestanding jar and ported it to Solr 5.3. 

I tried to pull in all the things that had changed since they were copied from 
the parent class in 4.4, and added per-request backup time support. 
Sadly, there were still a few places where package-protected restrictions got 
in the way, (Rsp.server and LBHttpSolrClient.doRequest in particular) so even 
as a separate jar, this must be loaded by the same classloader as 
LBHttpSolrClient, not via solr's lib inclusion mechanism.

After this long, it feels unlikely this feature will get merged, but if there's 
any interest in that it should still be pretty simple to just copy the files 
back into the solr source tree, I didn't change any paths or package names, and 
I'd be happy to upload another patch file.

My version can be found here:
https://github.com/whitepages/SOLR-4449

For those who were wondering about the effect of this stuff, in one test today 
I cut my median query response time in half, at a cost of about 15% more 
cluster-wide cpu, simply by using this and setting the backupRequestDelay to 
half my observed ParNew GC pause. The next logical step would be 
performance-aware backup request settings, like "issue a backup request when 
you exceed your 95th percentile latency for a given requestHandler or 
queryPerformanceClass".

My thanks to [~phloy] for authoring this.

> Enable backup requests for the internal solr load balancer
> --
>
> Key: SOLR-4449
> URL: https://issues.apache.org/jira/browse/SOLR-4449
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: philip hoy
>Priority: Minor
> Attachments: SOLR-4449.patch, SOLR-4449.patch, SOLR-4449.patch, 
> patch-4449.txt, solr-back-request-lb-plugin.jar
>
>
> Add the ability to configure the built-in solr load balancer such that it 
> submits a backup request to the next server in the list if the initial 
> request takes too long. Employing such an algorithm could improve the latency 
> of the 9xth percentile albeit at the expense of increasing overall load due 
> to additional requests. 



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

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

[jira] [Comment Edited] (SOLR-6168) enhance collapse QParser so that "group head" documents can be selected by more complex sort options

[Hoss Man (JIRA)]

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

Hoss Man edited comment on SOLR-6168 at 9/22/15 1:02 AM:
-

*EDIT:* Deleted comment that was ment for LUCENE-6808 (and ultimately posted 
there correctly)


was (Author: hossman):
bq. The intention of the FieldComparator.value API is that you would use it to 
look up a value after all collection is complete, e.g. to fill the fields to 
create the FieldDoc for this hit, and so the comparator would naturally not be 
changing it anymore.

ok, but that's not clear/enforced anywhere in the API itself -- if you are only 
suppose to fetch back all the slots after the search is complete, why support 
fetching the individual slots (and compareValues()) at all?

bq. But I don't really understand what SOLR-6168 is trying to do ... maybe 
there is another way to do it w/o abusing this API?

In a nutshell the CollapseQParser is another style of "group collapsing" where 
it picks a single best representative doc for each group on the fly as docs are 
collected -- currently it does this only based on a single field via DocValues, 
SOLR-6168 is about making this work with any arbitrary "Sort" object.  The code 
in the patch (in SOLR-6168) is analogous to the type of logic that 
FieldValueHitQueue does, but instead of tracking the "N best docs" (according 
to the sort) in a single priority queue (which re-orders on the fly), it tracks 
the *1* best doc for every "group" as it makes a single pass collection uses 
value() + compareValues to know when a "better" doc has been found for that 
group.

(The most trivial implementation would be to use a FieldValueHitQueue of size 
'1' for each group, but this approach unwinds the logic a track the values 
directly.  When i was first looking at this approach, i initially considered 
using a FieldComparator "slot" for each group, but the number of groups isn't 
neccessarly known in advance and there's no way to "grow" a FieldComparator)

It doesn't feel like an abuse of the FieldComparator API to do this ... every 
other Comparator works fine as is.  As i mentioned I could always put hacks in 
the caller code (ColapseQParser) to do instanceof/casting/deepCopy when the 
FieldComparator returns BytesRefs -- but fixing Term(Ord)ValComparator.value to 
return "safe" objects seemed saner.

---

Forgetting SOLR-6168, even if you asssume that all callers should know that  
FieldComparator.value is only intended to be usable after the end of a search, 
the BytesRefs returned by Term(Ord)ValComparator.value don't really seem to be 
safe for a caller to hang on to (for later use searchAfter, etc...) in any 
situation where the FieldComparator itself might get re-used -- ie: re-using a 
FieldValueHitQueue (or Collector that uses FieldValueHitQueue) in a subsequent 
search.

what protects the user from those values being changed out from under them in 
that situation?


> enhance collapse QParser so that "group head" documents can be selected by 
> more complex sort options
> 
>
> Key: SOLR-6168
> URL: https://issues.apache.org/jira/browse/SOLR-6168
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.7.1, 4.8.1
>Reporter: Umesh Prasad
>Assignee: Joel Bernstein
> Attachments: CollapsingQParserPlugin-6168.patch.1-1stcut, 
> SOLR-6168-group-head-inconsistent-with-sort.patch, SOLR-6168.patch, 
> SOLR-6168.patch
>
>
> The fundemental goal of this issue is add additional support to the 
> CollapseQParser so that as an alternative to the existing min/max localparam 
> options, more robust sort syntax can be used to sort on multiple criteria 
> when selecting the "group head" documents used to represent each collapsed 
> group.
> Since support for arbitrary, multi-clause, sorting is almost certainly going 
> to require more RAM then the existing min/max functionaly, this new 
> functionality should be in addition to the existing min/max localparam 
> implementation, not a replacement of it.
> (NOTE: early comments made in this jira may be confusing in historical 
> context due to the way this issue was originally filed as a bug report)



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

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

[jira] [Commented] (SOLR-8081) When creating a collection, we need a way to utilize multiple disks available on a node.

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-8081:
-

bq. I'm aware that I could create the collection with rf=1 

We could create a coreless collection and then have the ability to control the 
dataDir for all replicas.

It will be really good if replica placement strategy could have this feature.

> When creating a collection, we need a way to utilize multiple disks available 
> on a node.
> 
>
> Key: SOLR-8081
> URL: https://issues.apache.org/jira/browse/SOLR-8081
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Timothy Potter
>
> Currently, if I want to change the dataDir for a core (such as to utilize 
> multiple disks on a Solr node), I need to either setup a symlink or change 
> the dataDir property in core.properties and restart the Solr node. For 
> instance, if I have a 4-node SolrCloud cluster and want to create a 
> collection with 4 shards with rf=2, then 8 Solr cores will be created across 
> the cluster, 2 per node. If I want to have each core use a separate disk, 
> then I have to do that after the fact. I'm aware that I could create the 
> collection with rf=1 and then use AddReplica to add additional replicas with 
> a different dataDir set, but that feels cumbersome as well.
> What would be nice is to have a way for me to specify available disks and 
> have Solr use that information when provisioning cores on the node. 
> [~anshumg] mentioned this might be best accomplished with a replica placement 
> strategy.



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

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

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2747 - Failure!

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.CdcrRequestHandlerTest.doTest

Error Message:
expected:<[dis]abled> but was:<[en]abled>

Stack Trace:
org.junit.ComparisonFailure: expected:<[dis]abled> but was:<[en]abled>
at 
__randomizedtesting.SeedInfo.seed([129256529B3F8120:B5D6EEF6F6849299]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.assertState(BaseCdcrDistributedZkTest.java:289)
at 
org.apache.solr.cloud.CdcrRequestHandlerTest.doTestBufferActions(CdcrRequestHandlerTest.java:138)
at 
org.apache.solr.cloud.CdcrRequestHandlerTest.doTest(CdcrRequestHandlerTest.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 

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

[Policeman Jenkins Server]

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

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

Error Message:
document count mismatch.  control=85 sum(shards)=84 cloudClient=84

Stack Trace:
java.lang.AssertionError: document count mismatch.  control=85 sum(shards)=84 
cloudClient=84
at 
__randomizedtesting.SeedInfo.seed([1B97BD7B3352B38C:93C382A19DAEDE74]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1298)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:233)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/70/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.security.TestAuthorizationFramework.authorizationFrameworkTest

Error Message:
This should have failed

Stack Trace:
java.lang.AssertionError: This should have failed
at 
__randomizedtesting.SeedInfo.seed([E1DEF61C1FEBAD33:AF7D83CF0E30BC23]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.security.TestAuthorizationFramework.authorizationFrameworkTest(TestAuthorizationFramework.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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11202 

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b78) - Build # 14269 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14269/
Java: 64bit/jdk1.9.0-ea-b78 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 1) Thread[id=546, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)2) Thread[id=545, 
name=ou=system.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)3) Thread[id=544, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)4) Thread[id=543, 
name=apacheds, state=WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] 
at java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)5) Thread[id=547, 
name=groupCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 
   1) Thread[id=546, name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 

[jira] [Closed] (SOLR-6066) CollapsingQParserPlugin + Elevation does not respects "fq" (filter query)

[Joel Bernstein (JIRA)]

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

Joel Bernstein closed SOLR-6066.

Resolution: Fixed

> CollapsingQParserPlugin + Elevation does not respects "fq" (filter query) 
> --
>
> Key: SOLR-6066
> URL: https://issues.apache.org/jira/browse/SOLR-6066
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 4.8
>Reporter: Herb Jiang
>Assignee: Joel Bernstein
> Fix For: 4.9
>
> Attachments: SOLR-6066.patch, SOLR-6066.patch, SOLR-6066.patch, 
> TestCollapseQParserPlugin.java
>
>
> QueryElevationComponent respects the "fq" parameter. But when use 
> CollapsingQParserPlugin with QueryElevationComponent, additional "fq" has no 
> effect.
> I use following test case to show this issue. (It will failed)
> {code:java}
> String[] doc = {"id","1", "term_s", "", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "5", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc));
> assertU(commit());
> String[] doc1 = {"id","2", "term_s","", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "50", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc1));
> String[] doc2 = {"id","3", "term_s", "", "test_ti", "5000", 
> "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc2));
> assertU(commit());
> String[] doc3 = {"id","4", "term_s", "", "test_ti", "500", "test_tl", 
> "1000", "test_tf", "2000"};
> assertU(adoc(doc3));
> String[] doc4 = {"id","5", "term_s", "", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "4", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc4));
> assertU(commit());
> String[] doc5 = {"id","6", "term_s","", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "10", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc5));
> assertU(commit());
> //Test additional filter query when using collapse
> params = new ModifiableSolrParams();
> params.add("q", "");
> params.add("fq", "{!collapse field=group_s}");
> params.add("fq", "category_s:cat1");
> params.add("defType", "edismax");
> params.add("bf", "field(test_ti)");
> params.add("qf", "term_s");
> params.add("qt", "/elevate");
> params.add("elevateIds", "2");
> assertQ(req(params), "*[count(//doc)=1]",
> "//result/doc[1]/float[@name='id'][.='6.0']");
> {code}



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

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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60) - Build # 14270 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14270/
Java: 32bit/jdk1.8.0_60 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([C53278590036040D:6276C0FD6D8D17B4]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319)
at 
org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationAfterPeerSync(CdcrReplicationHandlerTest.java:158)
at 
org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60) - Build # 14264 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14264/
Java: 32bit/jdk1.8.0_60 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CdcrRequestHandlerTest.doTest

Error Message:
expected:<[dis]abled> but was:<[en]abled>

Stack Trace:
org.junit.ComparisonFailure: expected:<[dis]abled> but was:<[en]abled>
at 
__randomizedtesting.SeedInfo.seed([B58C10C7333104AB:12C8A8635E8A1712]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.assertState(BaseCdcrDistributedZkTest.java:289)
at 
org.apache.solr.cloud.CdcrRequestHandlerTest.doTestBufferActions(CdcrRequestHandlerTest.java:138)
at 
org.apache.solr.cloud.CdcrRequestHandlerTest.doTest(CdcrRequestHandlerTest.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 

[jira] [Updated] (SOLR-5750) Data driven spellchecker refers to a non-existent field

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-5750:

Summary: Data driven spellchecker refers to a non-existent field  (was: 
Backup/Restore API for SolrCloud)

> Data driven spellchecker refers to a non-existent field
> ---
>
> Key: SOLR-5750
> URL: https://issues.apache.org/jira/browse/SOLR-5750
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Varun Thacker
> Fix For: 5.2, Trunk
>
> Attachments: SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch
>
>
> We should have an easy way to do backups and restores in SolrCloud. The 
> ReplicationHandler supports a backup command which can create snapshots of 
> the index but that is too little.
> The command should be able to backup:
> # Snapshots of all indexes or indexes from the leader or the shards
> # Config set
> # Cluster state
> # Cluster properties
> # Aliases
> # Overseer work queue?
> A restore should be able to completely restore the cloud i.e. no manual steps 
> required other than bringing nodes back up or setting up a new cloud cluster.
> SOLR-5340 will be a part of this issue.



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

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

[jira] [Updated] (SOLR-8078) Data driven solrconfig spellchecker refers to a non-existent field

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-8078:

Description: 
In the data driven solrconfig.xml file, the "default" spellchecker refers to a 
field called "text" which doesn't exist in the schema. 

So when you run this query 
{{http://localhost:8983/solr/gettingstarted/spell?q=*}} Solr will throw an 
error. 

I guess the field name should be {{\_text\_}} ?

  was:
In the data driven solrconfig.xml file, the "default" spellchecker refers to a 
field called "text" which doesn't exist in the schema. 

So when you run this query 
{{http://localhost:8983/solr/gettingstarted/spell?q=*=text}} Solr will throw 
an error. 

I guess the field name should be {{\_text\_}} ?


> Data driven solrconfig spellchecker refers to a non-existent field
> --
>
> Key: SOLR-8078
> URL: https://issues.apache.org/jira/browse/SOLR-8078
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>
> In the data driven solrconfig.xml file, the "default" spellchecker refers to 
> a field called "text" which doesn't exist in the schema. 
> So when you run this query 
> {{http://localhost:8983/solr/gettingstarted/spell?q=*}} Solr will throw an 
> error. 
> I guess the field name should be {{\_text\_}} ?



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

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

[jira] [Updated] (SOLR-8078) Data driven solrconfig spellchecker refers to a non-existent field

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-8078:

Description: 
In the data driven solrconfig.xml file, the "default" spellchecker refers to a 
field called "text" which doesn't exist in the schema.

Even the "wordbreak" spellchecker refers to a field called "name" which does 
not exist. 

So when you run this query 
{{http://localhost:8983/solr/gettingstarted/spell?q=*}} Solr will throw an 
error. 

I guess the field name should be {{\_text\_}} ?

  was:
In the data driven solrconfig.xml file, the "default" spellchecker refers to a 
field called "text" which doesn't exist in the schema. 

So when you run this query 
{{http://localhost:8983/solr/gettingstarted/spell?q=*}} Solr will throw an 
error. 

I guess the field name should be {{\_text\_}} ?


> Data driven solrconfig spellchecker refers to a non-existent field
> --
>
> Key: SOLR-8078
> URL: https://issues.apache.org/jira/browse/SOLR-8078
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>
> In the data driven solrconfig.xml file, the "default" spellchecker refers to 
> a field called "text" which doesn't exist in the schema.
> Even the "wordbreak" spellchecker refers to a field called "name" which does 
> not exist. 
> So when you run this query 
> {{http://localhost:8983/solr/gettingstarted/spell?q=*}} Solr will throw an 
> error. 
> I guess the field name should be {{\_text\_}} ?



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

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

Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 13979 - Failure!

[david.w.smi...@gmail.com]

This is a duplicate of a known issue. Spatial4j 0.5 fixes this. I'll have a
patch for that later today.
On Mon, Sep 21, 2015 at 4:42 AM Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13979/
> Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseG1GC
>
> 1 tests failed.
> FAILED:
> org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations
> {#14 seed=[81259AC648C50EE8:492E44EF2E21F2EC]}
>
> Error Message:
> [Overlaps] qIdx:6 Should have matched I#2:Circle(Pt(x=37.0,y=-58.0),
> d=41.1° 4571.45km) Q:Circle(Pt(x=-143.0,y=58.0), d=69.5° 7724.04km)
>
> Stack Trace:
> java.lang.AssertionError: [Overlaps] qIdx:6 Should have matched
> I#2:Circle(Pt(x=37.0,y=-58.0), d=41.1° 4571.45km)
> Q:Circle(Pt(x=-143.0,y=58.0), d=69.5° 7724.04km)
> at
> __randomizedtesting.SeedInfo.seed([81259AC648C50EE8:492E44EF2E21F2EC]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:127)
> at
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:121)
> at
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:56)
> at
> org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations(CompositeStrategyTest.java:99)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> 

[jira] [Created] (SOLR-8078) Data driven solrconfig spellchecker refers to a non-existent field

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-8078:
---

 Summary: Data driven solrconfig spellchecker refers to a 
non-existent field
 Key: SOLR-8078
 URL: https://issues.apache.org/jira/browse/SOLR-8078
 Project: Solr
  Issue Type: Bug
Reporter: Varun Thacker


In the data driven solrconfig.xml file, the "default" spellchecker refers to a 
field called "text" which doesn't exist in the schema. 

So when you run this query 
{{http://localhost:8983/solr/gettingstarted/spell?q=*=text}} Solr will throw 
an error. 

I guess the field name should be {{\_text\_}} ?



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

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

Re: test suite counter skipping numbers?

[Dawid Weiss]

Hi Shawn,

Suites which didn't have failures (in setup/teardown) and had zero
tests are omitted from reporting. I think it'd make more sense to
report the total number of suites and the actual number of suites
separately in the summary, leaving the counter without gaps, for
example:

> Tests summary: 100 suites (2 ignored), xx tests, xx ignored (xx assumptions).

Will do it in the next version. Thanks for letting me know.

Dawid

On Fri, Sep 11, 2015 at 3:26 PM, Shawn Heisey  wrote:
> On 9/11/2015 7:06 AM, Shawn Heisey wrote:
>>[junit4] Suite: org.apache.solr.TestCrossCoreJoin
>>[junit4] Completed [522/545] on J1 in 1.38s, 3 tests
>>
>> Suite numbers 518, 519,and 521 did not display.
>>
>> Any idea what's up there?
>
> I did not check all 545 results to see if there were more than those
> three missing.  The ones I know are missing did not not seem to affect
> the overall count.  From the end of that test run:
>
>[junit4] Suite: org.apache.solr.util.TestSolrCLIRunExample
>[junit4] Completed [545/545] on J1 in 17.77s, 3 tests, 1 skipped
>[junit4]
>[junit4] JVM J0: 1.26 ..  3060.03 =  3058.78s
>[junit4] JVM J1: 1.46 ..  3068.68 =  3067.22s
>[junit4] Execution time total: 51 minutes 8 seconds
>[junit4] Tests summary: 545 suites, 2143 tests, 47 ignored (35
> assumptions)
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Commented] (SOLR-7759) DebugComponent's explain should be implemented as a distributed query

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-7759:
-

Hello [~varunthacker], no unfortunately not.

> DebugComponent's explain should be implemented as a distributed query
> -
>
> Key: SOLR-7759
> URL: https://issues.apache.org/jira/browse/SOLR-7759
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>
> Currently when we use debugQuery to see the explanation of the matched 
> documents, the query fired to get the statistics for the matched documents is 
> not a distributed query.
> This is a problem when using distributed idf. The actual documents are being 
> scored using the global stats and not per shard stats , but the explain will 
> show us the score by taking into account the stats from the shard where the 
> document belongs to.
> We should try to implement the explain query as a distributed request so that 
> the scores match the actual document scores.



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

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

[jira] [Updated] (SOLR-5750) Backup/Restore API for SolrCloud

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-5750:

Summary: Backup/Restore API for SolrCloud  (was: Data driven spellchecker 
refers to a non-existent field)

> Backup/Restore API for SolrCloud
> 
>
> Key: SOLR-5750
> URL: https://issues.apache.org/jira/browse/SOLR-5750
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Varun Thacker
> Fix For: 5.2, Trunk
>
> Attachments: SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch
>
>
> We should have an easy way to do backups and restores in SolrCloud. The 
> ReplicationHandler supports a backup command which can create snapshots of 
> the index but that is too little.
> The command should be able to backup:
> # Snapshots of all indexes or indexes from the leader or the shards
> # Config set
> # Cluster state
> # Cluster properties
> # Aliases
> # Overseer work queue?
> A restore should be able to completely restore the cloud i.e. no manual steps 
> required other than bringing nodes back up or setting up a new cloud cluster.
> SOLR-5340 will be a part of this issue.



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

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

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2745 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2745/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
Test abandoned because suite timeout was reached.

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


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

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

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




Build Log:
[...truncated 11038 lines...]
   [junit4] Suite: org.apache.solr.cloud.DistributedVersionInfoTest
   [junit4]   2> Creating dataDir: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.DistributedVersionInfoTest_1ECCCA2E80C07DE9-001/init-core-data-001
   [junit4]   2> 2040054 INFO  
(SUITE-DistributedVersionInfoTest-seed#[1ECCCA2E80C07DE9]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 2040057 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 2040057 INFO  (Thread-5688) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 2040057 INFO  (Thread-5688) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 2040158 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.ZkTestServer start zk server on port:57593
   [junit4]   2> 2040159 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 2040160 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 2040170 INFO  (zkCallback-1711-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@2ff6f03c 
name:ZooKeeperConnection Watcher:127.0.0.1:57593 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 2040170 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 2040171 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 2040171 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 2040177 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 2040179 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 2040181 INFO  (zkCallback-1712-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@6291112f 
name:ZooKeeperConnection Watcher:127.0.0.1:57593/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 2040181 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 2040182 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 2040182 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1
   [junit4]   2> 2040188 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1/shards
   [junit4]   2> 2040194 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection
   [junit4]   2> 2040198 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection/shards
   [junit4]   2> 2040203 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.AbstractZkTestCase put 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 2040203 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.c.SolrZkClient makePath: /configs/conf1/solrconfig.xml
   [junit4]   2> 2040210 INFO  
(TEST-DistributedVersionInfoTest.test-seed#[1ECCCA2E80C07DE9]) [] 
o.a.s.c.AbstractZkTestCase 

[jira] [Commented] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8068:
--

Is this on windows? There is a similar stacktrace on SOLR-8073

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[jira] [Commented] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-8068:
-

Hello - no, this is on Debian Linux running a OpenJDK 1.8.0_66 JVM.

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[jira] [Commented] (SOLR-8069) Ensure that only the valid ZooKeeper registered leader can put a replica into Leader Initiated Recovery.

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8069:


Just looked at it again, it indeed is :-).

In that case let's yank out getLeaderSeqPath. It's not needed elsewhere anyways.

> Ensure that only the valid ZooKeeper registered leader can put a replica into 
> Leader Initiated Recovery.
> 
>
> Key: SOLR-8069
> URL: https://issues.apache.org/jira/browse/SOLR-8069
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Critical
> Attachments: SOLR-8069.patch, SOLR-8069.patch
>
>
> I've seen this twice now. Need to work on a test.
> When some issues hit all the replicas at once, you can end up in a situation 
> where the rightful leader was put or put itself into LIR. Even on restart, 
> this rightful leader won't take leadership and you have to manually clear the 
> LIR nodes.
> It seems that if all the replicas participate in election on startup, LIR 
> should just be cleared.



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

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

[jira] [Updated] (SOLR-6168) enhance collapse QParser so that "group head" documents can be selected by more complex sort options

[Hoss Man (JIRA)]

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

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

Updated patch...

* collapsing on int & float fields now works
** NOTE: randomized testing of collapsing on docValues float fields is disabled 
with nocommit
** SOLR-8082 prevents the verification queries from matching any docs when 
quering the float field
* more testing of various nullPolicies and initial "size" localparams
* more test coverage in TestCollapseQParserPlugin
** some of this new testing is explicitly of the new sort local param
** some general tweaking of testNumericCollapse & testStringCollapse to test 
all of the specified field names every time, not just 1 at random (only 
fractions of a second slower then before


> enhance collapse QParser so that "group head" documents can be selected by 
> more complex sort options
> 
>
> Key: SOLR-6168
> URL: https://issues.apache.org/jira/browse/SOLR-6168
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.7.1, 4.8.1
>Reporter: Umesh Prasad
>Assignee: Joel Bernstein
> Attachments: CollapsingQParserPlugin-6168.patch.1-1stcut, 
> SOLR-6168-group-head-inconsistent-with-sort.patch, SOLR-6168.patch, 
> SOLR-6168.patch, SOLR-6168.patch
>
>
> The fundemental goal of this issue is add additional support to the 
> CollapseQParser so that as an alternative to the existing min/max localparam 
> options, more robust sort syntax can be used to sort on multiple criteria 
> when selecting the "group head" documents used to represent each collapsed 
> group.
> Since support for arbitrary, multi-clause, sorting is almost certainly going 
> to require more RAM then the existing min/max functionaly, this new 
> functionality should be in addition to the existing min/max localparam 
> implementation, not a replacement of it.
> (NOTE: early comments made in this jira may be confusing in historical 
> context due to the way this issue was originally filed as a bug report)



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

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

[jira] [Commented] (SOLR-8069) Ensure that only the valid ZooKeeper registered leader can put a replica into Leader Initiated Recovery.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8069:
---

bq. if it's a node that was a leader but has just been network-partitioned off 
(but clusterstate change hasn't been made since it's asynchronous) and wasn't 
able to actually forward the request to the real leader.

I don't think we really protect against such cases where there is only a single 
leader that can accept an update because all its replicas go bad and then it 
goes away but the replicas come back. That is what min replication factor on 
the request is meant to handle. For full data promises, you want to use it - an 
achieved replication factor of 1 is not going to be fault tolerant.

> Ensure that only the valid ZooKeeper registered leader can put a replica into 
> Leader Initiated Recovery.
> 
>
> Key: SOLR-8069
> URL: https://issues.apache.org/jira/browse/SOLR-8069
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Critical
> Attachments: SOLR-8069.patch, SOLR-8069.patch
>
>
> I've seen this twice now. Need to work on a test.
> When some issues hit all the replicas at once, you can end up in a situation 
> where the rightful leader was put or put itself into LIR. Even on restart, 
> this rightful leader won't take leadership and you have to manually clear the 
> LIR nodes.
> It seems that if all the replicas participate in election on startup, LIR 
> should just be cleared.



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

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

[jira] [Commented] (LUCENE-6808) Term(Ord)ValComparator.value return BytesRefs that are re-used internally

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6808:


bq. OK, in that case I just did a thorough code review to investigate any 
issues. 

Thank you for the thorough code review / explanation ...

But my concern wasn't that we can convince ourselves today that setting to null 
(this change) is OK, it's that the code, to future devs looking at it, looks 
bad/buggy because a getter really should not have side effects.  This class is 
already scary enough, I don't think we should make it worse ...

bq. So the fix prevents the trap that Hoss found

I don't think this is a trap: I think it's abusing the API.

bq.  I think I just found another place where we fell into that same trap

Hmm, where?

> Term(Ord)ValComparator.value return BytesRefs that are re-used internally
> -
>
> Key: LUCENE-6808
> URL: https://issues.apache.org/jira/browse/LUCENE-6808
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: LUCENE-6808.patch, LUCENE-6808.patch
>
>
> While working on SOLR-6168, which involves some non-trivial usage of 
> {{FieldComparator}}, I discovered some weird bugs anytime I was using 
> TermOrdValComparator.  I ultimately tracked this down to the fact that the 
> {{BytesRef}} instances returned by {{TermOrdValComparator.value(int slot)}} 
> are backed by {{BytesRefBuilder}} instances that the Comparator hangs on to 
> and re-uses -- so the values a caller gets back from 
> {{FieldComparator.value(slot)}} might be changed out from under it before it 
> has a chance to use that value in something like 
> {{FieldComparator.compareValues(first,second)}}.
> The general approach when dealing with BytesRef instances (as i understand 
> it) is that the caller is responsible for making a copy if it wants to hang 
> on to it -- but in this case that would violate the generic API of 
> FieldComparator -- callers would have to pay attention to when a 
> {{FieldComparator}} is a 
> {{FieldComparator}} and do casting to copy the BytesRef.
> It seems like the right solution is for {{TermOrdValComparator.value(slot)}} 
> (and {{TermValComparator.value(slot)}} which has a similar BytesRef usage) to 
> return {{BytesRef.deepCopyOf(values\[slot\])}}



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

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

[jira] [Commented] (SOLR-8069) Ensure that only the valid ZooKeeper registered leader can put a replica into Leader Initiated Recovery.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8069:
---

Thanks for taking a look Anshum.

bq. intentional ?

Yup, that's really all of the magic. The CloudDescriptor#isLeader stuff is 
really just a little extra sugar on top.

> Ensure that only the valid ZooKeeper registered leader can put a replica into 
> Leader Initiated Recovery.
> 
>
> Key: SOLR-8069
> URL: https://issues.apache.org/jira/browse/SOLR-8069
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Critical
> Attachments: SOLR-8069.patch, SOLR-8069.patch
>
>
> I've seen this twice now. Need to work on a test.
> When some issues hit all the replicas at once, you can end up in a situation 
> where the rightful leader was put or put itself into LIR. Even on restart, 
> this rightful leader won't take leadership and you have to manually clear the 
> LIR nodes.
> It seems that if all the replicas participate in election on startup, LIR 
> should just be cleared.



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

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

[jira] [Commented] (SOLR-7858) Make Angular UI default

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-7858:



bq. Chris Hostetter I recall you had suggestions as to how we go about 
releasing the new UI, but I haven't been able to track them down. ...

http://mail-archives.apache.org/mod_mbox/lucene-dev/201504.mbox/%3Calpine.DEB.2.02.1504301121010.19000@frisbee%3E

{quote}

My suggestion, along the lines of what we did with the previous UI 
change...

1) ensure that the new UI is fully functional in 5x using an alt path 
(believe this is already true?)

2) add an "Upgrading" note to CHANGES.txt for 5.2 directing people to 
the new "experimental" UI and the URL to access it, note that it 
will likely become the default in 5.3 and users are encouraged to try it 
out and file bugs if they notice any problems.

3) update trunk so that it *is* the default UI, and make the old UI 
available at some alternate path (eg "/solr/old_ui").  Add an Upgrading 
note pointing out that the URLs may be slightly different, and how to 
access the old UI if they have problems

* backport trunk changes (#3) to 5x for 5.3 (or later if problems/delays 
pop up)
{quote}

And: 
http://mail-archives.apache.org/mod_mbox/lucene-dev/201504.mbox/%3Calpine.DEB.2.02.1504301414460.19000@frisbee%3E
{quote}
...
We might want to tweak those URLs slightly to be a little less confusing 
... ie "old.html" and "new.html" (at least until after 5.3) ... i mean, i 
just the paragraph you rwote above, but w/o looking at it i've already 
forgoten if "index.html" is hte new one or hte old one.

So imagine if a 5.2 user has in their browser...

http://localhost:8983/solr/admin.html#/collection1

...and is trying to remember if this is the new one (that they should get 
use to / help test) or the fuly qualified name of the old one that is 
going away.

Likewise imagine if a 5.42 user sees the same URL, and reads a note that 
the "old UI" is going to be removed in 6.0 and is trying to figure out if 
that affects him.
{quote}

A few followup comments...

a) that "step 3" above (changing hte defualt on trunk first) is *really* 
important ... you want that change to sit on trunk for a good while, so that 
devs working on trunk and manually testing things are *using* the new UI 
anytime they run stuff on trunk, and helping to find problems -- even if no 
users "try" the new UI in the released versions of Solr

b) not sure why i didn't mention it before, but adding a generic header to all 
of the "old" UI pages warning people that they are using the old UI and here is 
a link to the new UI is something that should definitely be added once the 
default is changed (it could be added even before the default is changed with 
ome wording tweaks: "Please try the new UI.." vs "You are looking at the old 
deprecated UI, please switch to") to help reduce the # of bug reports / 
feature requests we get about the old UI and to reduce user frustration (ie; 
they see in some future release notes that there is a new collection admin 
screen, but they can't find it when they load "the admin UI" bookmark they 
have.)



bq. Having something like "admin#" or "admin/#/" (whatever makes sense for the 
code) in the URL would likely eliminate that confusion for most people. Even 
"index.html" in the URL (which the new UI has now) would be helpful, but using 
the word "admin" in some way would be better.

In the long term, I don't know if this is will actually help things or decrease 
novice user confusion (the URLs, when loaded in a browser, is already clearly a 
UI, will making the UI urls longer really help people notice "oh hey, maybe 
this UI based URL isn't a URL that programtic client code should talk to" ?)  
but if this approach is taken it should be _very_ carefully considered in terms 
of how it impacts "reserved words" for things like collection names.

It's annoying enough if we (in the short term) have reserved paths like 
"/old.ui.html" but if you try to use "/admin" as a prefix to indicate that it's 
for the UI, you'll probably break things like /admin/cores and 
/admin/collections -- let alone the long term impacts of saying something like 
"You can't have a collection named 'ui' because of the '/ui'." etc...


> Make Angular UI default
> ---
>
> Key: SOLR-7858
> URL: https://issues.apache.org/jira/browse/SOLR-7858
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Reporter: Upayavira
>Assignee: Upayavira
>Priority: Minor
> Attachments: SOLR-7858.patch, new ui link.png, original UI link.png
>
>
> Angular UI is very close to feature complete. Once SOLR-7856 is dealt with, 
> it should function well in most cases. I propose that, as soon as 5.3 has 
> been released, we make the Angular UI default, ready for 

[jira] [Commented] (LUCENE-6808) Term(Ord)ValComparator.value return BytesRefs that are re-used internally

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on LUCENE-6808:
--

bq. And it's not clear on first inspection that this is a safe thing to do

OK, in that case I just did a thorough code review to investigate any issues.  
The approach Hoss came up with is completely safe.

The array being modified is defined as
{code}
private final BytesRefBuilder[] tempBRs;
{code}

And it's only used in this little block of code, and nowhere else:
https://github.com/apache/lucene-solr/blob/72aa5784ecd7024dce7599c358b658bed4b31596/lucene/core/src/java/org/apache/lucene/search/FieldComparator.java#L914-L918

So the fix prevents the trap that Hoss found (and actually, I think I just 
found another place where we fell into that same trap), turns out to be trivial 
and has no downsides!


> Term(Ord)ValComparator.value return BytesRefs that are re-used internally
> -
>
> Key: LUCENE-6808
> URL: https://issues.apache.org/jira/browse/LUCENE-6808
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: LUCENE-6808.patch, LUCENE-6808.patch
>
>
> While working on SOLR-6168, which involves some non-trivial usage of 
> {{FieldComparator}}, I discovered some weird bugs anytime I was using 
> TermOrdValComparator.  I ultimately tracked this down to the fact that the 
> {{BytesRef}} instances returned by {{TermOrdValComparator.value(int slot)}} 
> are backed by {{BytesRefBuilder}} instances that the Comparator hangs on to 
> and re-uses -- so the values a caller gets back from 
> {{FieldComparator.value(slot)}} might be changed out from under it before it 
> has a chance to use that value in something like 
> {{FieldComparator.compareValues(first,second)}}.
> The general approach when dealing with BytesRef instances (as i understand 
> it) is that the caller is responsible for making a copy if it wants to hang 
> on to it -- but in this case that would violate the generic API of 
> FieldComparator -- callers would have to pay attention to when a 
> {{FieldComparator}} is a 
> {{FieldComparator}} and do casting to copy the BytesRef.
> It seems like the right solution is for {{TermOrdValComparator.value(slot)}} 
> (and {{TermValComparator.value(slot)}} which has a similar BytesRef usage) to 
> return {{BytesRef.deepCopyOf(values\[slot\])}}



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

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

[jira] [Created] (SOLR-8082) float query bug when indexed="false" docValues="true" multiValued="false"

[Hoss Man (JIRA)]

Hoss Man created SOLR-8082:
--

 Summary: float query bug when indexed="false" docValues="true" 
multiValued="false"
 Key: SOLR-8082
 URL: https://issues.apache.org/jira/browse/SOLR-8082
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man


Haven't dug into this yet, but something is evidently wrong in how the 
DocValues based queries get build for single valued flaot fields (may affect 
other trie based fields?

Steps to reproduce...

{noformat}
$ bin/solr -e schemaless -noprompt
...
$ curl -X POST -H 'Content-type:application/json' --data-binary '{ 
"add-field":{ "name":"f_dv_multi", "type":"tfloat", "stored":"true", 
"indexed":"false", "docValues":"true", "multiValued":"true" }, "add-field":{ 
"name":"f_dv_single", "type":"tfloat", "stored":"true", "indexed":"false", 
"docValues":"true", "multiValued":"false" } }' 
http://localhost:8983/solr/gettingstarted/schema
{
  "responseHeader":{
"status":0,
"QTime":84}}
$ curl -X POST -H 'Content-type:application/json' --data-binary '[{"id":"test", 
"f_dv_multi":-4.3, "f_dv_single":-4.3}]' 
'http://localhost:8983/solr/gettingstarted/update/json/docs?commit=true'
{"responseHeader":{"status":0,"QTime":57}}
$ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:"-4.3;'
{
  "responseHeader":{
"status":0,
"QTime":5,
"params":{
  "q":"f_dv_multi:\"-4.3\""}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"id":"test",
"f_dv_multi":[-4.3],
"f_dv_single":-4.3,
"_version_":1512962117004689408}]
  }}
$ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:"-4.3;'
{
  "responseHeader":{
"status":0,
"QTime":5,
"params":{
  "q":"f_dv_single:\"-4.3\""}},
  "response":{"numFound":0,"start":0,"docs":[]
  }}
{noformat}

Explicit range queries (which is how numeric "field" queries are implemented 
under the cover) are equally problematic...

{noformat}
$ curl 
'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:%5B-4.3+TO+-4.3%5D'
{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"f_dv_multi:[-4.3 TO -4.3]"}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"id":"test",
"f_dv_multi":[-4.3],
"f_dv_single":-4.3,
"_version_":1512962117004689408}]
  }}
$ curl 
'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:%5B-4.3+TO+-4.3%5D'
{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"f_dv_single:[-4.3 TO -4.3]"}},
  "response":{"numFound":0,"start":0,"docs":[]
  }}
{noformat}



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

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

[jira] [Commented] (SOLR-8080) 'bin/solr start' should print informative errors when the JVM version is insufficient

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8080:
--

[~anshumg], why did you remove 5.4 from the list of affected versions?  I see 
the same behavior on branch_5x as with the 5.3 distribution:

{noformat}
$ java -version
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)

$ echo $JAVA_HOME
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

$ bin/solr start
Waiting up to 30 seconds to see Solr running on port 8983 [\]  Still not seeing 
Solr listening on 8983 after 30 seconds!
tail: ~/svn/lucene/dev/branches/branch_5x/solr/server/logs/solr.log: No such 
file or directory
{noformat}

> 'bin/solr start' should print informative errors when the JVM version is 
> insufficient
> -
>
> Key: SOLR-8080
> URL: https://issues.apache.org/jira/browse/SOLR-8080
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.3, Trunk
>Reporter: Steve Rowe
>Priority: Minor
>
> From the unpacked 5.3.0 distribution, with Java6 set in {{$JAVA_HOME}} and 
> the {{$PATH}}, there is some indication that there is a problem (Java7 is 
> minimum supported JVM version) - bin/solr times out waiting for Solr to start 
> up - but no info is printed about what the problem might be:
> {noformat}
> $ echo $JAVA_HOME
> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> $ java -version
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
> $ bin/solr start
> Waiting up to 30 seconds to see Solr running on port 8983 [\]  Still not 
> seeing Solr listening on 8983 after 30 seconds!
> tail:~/temp/solr-5.3.0/server/logs/solr.log: No such file or directory
> {noformat}
> On trunk (built via {{ant server}} with Java8), the situation is worse - 
> although Solr started, it's not in a usable state, and there is no indication 
> given that there is a problem:
> {noformat}
> $ java -version
> java version "1.7.0_71"
> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
> $ echo $JAVA_HOME
> /Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home
> sarowe@smb [2048]$ bin/solr start
> Waiting up to 30 seconds to see Solr running on port 8983 [/]  
> Started Solr server on port 8983 (pid=50551). Happy searching!
> {noformat}
> From {{server/logs/solr.log}}:
> {noformat}
> 2015-09-21 17:15:28.991 WARN  (main) [   ] o.e.j.u.c.AbstractLifeCycle FAILED 
> So
> lrRequestFilter: java.lang.UnsupportedClassVersionError: 
> org/apache/solr/servlet
> /SolrDispatchFilter : Unsupported major.minor version 52.0
> java.lang.UnsupportedClassVersionError: 
> org/apache/solr/servlet/SolrDispatchFilt
> er : Unsupported major.minor version 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:14
> 2)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> [...]
> 2015-09-21 17:15:29.020 INFO  (main) [   ] o.e.j.s.ServerConnector Started 
> ServerConnector@24d25ddc{HTTP/1.1}{0.0.0.0:8983}
> 2015-09-21 17:15:29.020 INFO  (main) [   ] o.e.j.s.Server Started @1237ms
> {noformat}



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

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

[jira] [Created] (LUCENE-6811) AnalyzingInfixSuggester cannot be used in more than one thread

[Lukhnos Liu (JIRA)]

Lukhnos Liu created LUCENE-6811:
---

 Summary: AnalyzingInfixSuggester cannot be used in more than one 
thread
 Key: LUCENE-6811
 URL: https://issues.apache.org/jira/browse/LUCENE-6811
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/other
Affects Versions: 5.3
Reporter: Lukhnos Liu


Currently AnalyzingInfixSuggester always opens an index writer, even if the 
suggester will be used entirely in read-only mode. I was trying to serve 
suggestions out of the same index in a multithreaded setup, but I could only 
create one suggester per index per process because of this design.

I've created a GitHub project to demonstrate the bug: 
[https://github.com/lukhnos/lucene-analyzing-infix-suggester-bug]

To run the demo:

{code}
./gradlew build
java -jar build/libs/lucene-analyzing-infix-suggester-bug.jar
{code}

The exception reads:

{code}
Exception in thread "Thread-1" java.lang.RuntimeException: 
org.apache.lucene.store.LockObtainFailedException: Lock held by this virtual 
machine: /write.lock
at 
org.lukhnos.lucenestudy.AnalyzingInfixSuggesterBug$1SuggestReader.run(AnalyzingInfixSuggesterBug.java:65)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.lucene.store.LockObtainFailedException: Lock held by this 
virtual machine: /write.lock
at 
org.apache.lucene.store.NativeFSLockFactory.obtainFSLock(NativeFSLockFactory.java:127)
at org.apache.lucene.store.FSLockFactory.obtainLock(FSLockFactory.java:41)
at org.apache.lucene.store.BaseDirectory.obtainLock(BaseDirectory.java:45)
at org.apache.lucene.index.IndexWriter.(IndexWriter.java:775)
at 
org.apache.lucene.search.suggest.analyzing.AnalyzingInfixSuggester.(AnalyzingInfixSuggester.java:251)
at 
org.apache.lucene.search.suggest.analyzing.AnalyzingInfixSuggester.(AnalyzingInfixSuggester.java:163)
at 
org.lukhnos.lucenestudy.AnalyzingInfixSuggesterBug$1SuggestReader.run(AnalyzingInfixSuggesterBug.java:51)
... 1 more
{code}

To work around this problem, I'm currently using my own modified "read only" 
AnalyzingInfixSuggester, in which I commented out the index writer creation 
code in the constructor. Then, in the lookup method, I also commented out the 
part where we get an EarlyTerminatingSortingCollector out of the index writer, 
so that only a TopFieldCollector is used.

I was wondering if a read-only mode can be added to AnalyzingInfixSuggester, or 
at least the contract of getIndexWriterConfig can be changed -- since one will 
have to subclass to use a different index writer config anyway -- such that if 
one returns null in getIndexWriterConfig, the suggester will operate in 
read-only mode, and so no index writer is created. Of course an error will have 
to be thrown if any build or update methods are called in such mode.




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

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

[jira] [Updated] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8068:
---
Attachment: SOLR-8068.patch

Patch that does what I mentioned in my comment. It doesn't make the problem go 
away but doesn't throw an NPE, instead throws an exception and logs.

This really shouldn't ever happen unless maybe, during an edge case when the 
node is shutting down.

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[jira] [Commented] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8068:


[~anshumg] Oops, you beat me to the patch. Feel free to ignore mine.

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 800 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/800/

3 tests failed.
REGRESSION:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Error from server at http://127.0.0.1:34640: Could not load collection from 
ZK:nodes_used_collection

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:34640: Could not load collection from 
ZK:nodes_used_collection
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:302)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:419)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:169)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 

[jira] [Commented] (SOLR-7858) Make Angular UI default

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-7858:


I would like to have the URL seen in the browser include something to make it 
obvious that it's the admin UI, so users are not tempted to grab the URL in 
their browser (containing the # character) and use it as a base URL for a 
client program.  The number of times that I've seen this on the mailing list 
and the IRC channel is an indication that the users are being easily confused.

Having something like "admin#" or "admin/#/" (whatever makes sense for the 
code) in the URL would likely eliminate that confusion for most people.  Even 
"index.html" in the URL (which the new UI has now) would be helpful, but using 
the word "admin" in some way would be better.

> Make Angular UI default
> ---
>
> Key: SOLR-7858
> URL: https://issues.apache.org/jira/browse/SOLR-7858
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Reporter: Upayavira
>Assignee: Upayavira
>Priority: Minor
> Attachments: SOLR-7858.patch, new ui link.png, original UI link.png
>
>
> Angular UI is very close to feature complete. Once SOLR-7856 is dealt with, 
> it should function well in most cases. I propose that, as soon as 5.3 has 
> been released, we make the Angular UI default, ready for the 5.4 release. We 
> can then fix any more bugs as they are found, but more importantly start 
> working on the features that were the reason for doing this work in the first 
> place.



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

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

[jira] [Commented] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8068:


[~markus17] would it be possible for you to share the logs from the machine 
where you saw this happening?

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[jira] [Commented] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-8068:
-

[~anshumg]  

{code}
INFO  - 2015-09-21 15:57:47.311; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] 
org.apache.solr.update.processor.LogUpdateProcessor; 
[relations_shard1_replica1] webapp=/solr path=/update 
params={wt=javabin=2} {deleteByQuery=*:* (-1512939000366628864)} 0 462
INFO  - 2015-09-21 15:57:49.278; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] 
org.apache.solr.update.processor.LogUpdateProcessor; 
[relations_shard1_replica1] webapp=/solr path=/update 
params={wt=javabin=2} {add=[1dd0b2b0-d1ed-4351-8525-b8bd148f25c9 
(1512939000851070976), f069905c-76ac-4a58-8bdf-9d26cecba258 
(1512939000916082688), 3e014831-c77d-4b9c-a022-3b0d8ece28ea 
(1512939000920276992), 55504b5e-f652-49c2-9451-fde598106702 
(1512939000924471296), 13ae8cbd-2d30-4b64-845c-a77910cb1982 
(1512939000927617024), d59810cb-555f-4f12-9798-bbccdf4b18f8 
(1512939000932859904), c5ad5cfc-fcd2-4612-97e3-44cdf70ee865 
(1512939000936005632), d3dfc240-96a3-40ee-b182-4553ed5a2aea 
(1512939000939151360), 12fec088-f181-430d-ae09-c3eee4a2f23c 
(1512939000942297088), 9a88ed71-cdee-4ffc-b38f-cb84820d9a8a 
(1512939000944394240), ... (4186 adds)]} 0 1882
INFO  - 2015-09-21 15:57:49.298; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] org.apache.solr.update.DirectUpdateHandler2; start 
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
INFO  - 2015-09-21 15:57:49.893; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] org.apache.solr.core.SolrDeletionPolicy; 
SolrDeletionPolicy.onCommit: commits: num=2

commit{dir=NRTCachingDirectory(MMapDirectory@/var/lib/solr/relations_shard1_replica1/data/index
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@bbed33; 
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_kh,generation=737}

commit{dir=NRTCachingDirectory(MMapDirectory@/var/lib/solr/relations_shard1_replica1/data/index
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@bbed33; 
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_ki,generation=738}
INFO  - 2015-09-21 15:57:49.895; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] org.apache.solr.core.SolrDeletionPolicy; newest 
commit generation = 738
INFO  - 2015-09-21 15:57:49.906; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] org.apache.solr.search.SolrIndexSearcher; Opening 
Searcher@6e3d2e82[relations_shard1_replica1] main
INFO  - 2015-09-21 15:57:49.910; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] org.apache.solr.core.QuerySenderListener; 
QuerySenderListener sending requests to 
Searcher@6e3d2e82[relations_shard1_replica1] 
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_kh(5.3.0):C4186)))}
ERROR - 2015-09-21 15:57:49.915; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] org.apache.solr.request.SolrRequestInfo; Previous 
SolrRequestInfo was not closed!  
req=waitSearcher=true=true=false=javabin=2
ERROR - 2015-09-21 15:57:49.916; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] org.apache.solr.request.SolrRequestInfo; prev == 
info : false
INFO  - 2015-09-21 15:57:49.919; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] org.apache.solr.core.SolrCore; 
[relations_shard1_replica1] webapp=null path=null 
params={q=*:*=false=newSearcher} hits=4186 status=0 QTime=3 
INFO  - 2015-09-21 15:57:49.926; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] org.apache.solr.core.QuerySenderListener; 
QuerySenderListener done.
INFO  - 2015-09-21 15:57:49.937; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] org.apache.solr.core.SolrCore; 
[relations_shard1_replica1] Registered new searcher 
Searcher@6e3d2e82[relations_shard1_replica1] 
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_kh(5.3.0):C4186)))}
INFO  - 2015-09-21 15:57:49.942; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] org.apache.solr.update.DirectUpdateHandler2; 
end_commit_flush
INFO  - 2015-09-21 15:57:49.952; [c:relations s:shard1 r:core_node1 
x:relations_shard1_replica1] 
org.apache.solr.update.processor.LogUpdateProcessor; 
[relations_shard1_replica1] webapp=/solr path=/update 
params={waitSearcher=true=true=false=javabin=2} 
{commit=} 0 657
{code}

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch
>
>
> 

[JENKINS-EA] Lucene-Solr-5.3-Linux (64bit/jdk1.9.0-ea-b78) - Build # 217 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.3-Linux/217/
Java: 64bit/jdk1.9.0-ea-b78 -XX:+UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testExtraction

Error Message:
Invalid Date String:'Thu Nov 13 14:35:51 MET 2008'

Stack Trace:
org.apache.solr.common.SolrException: Invalid Date String:'Thu Nov 13 14:35:51 
MET 2008'
at 
__randomizedtesting.SeedInfo.seed([8ABDAF93B258EAA7:33CEDBEDCE703A52]:0)
at org.apache.solr.util.DateFormatUtil.parseMath(DateFormatUtil.java:87)
at org.apache.solr.schema.TrieField.createField(TrieField.java:695)
at org.apache.solr.schema.TrieField.createFields(TrieField.java:732)
at 
org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:48)
at 
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:123)
at 
org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:83)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:237)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:163)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:981)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:706)
at 
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:104)
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.doAdd(ExtractingDocumentLoader.java:122)
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.addDoc(ExtractingDocumentLoader.java:127)
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:230)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
at 
org.apache.solr.util.TestHarness.queryAndResponse(TestHarness.java:339)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.loadLocalFromHandler(ExtractingRequestHandlerTest.java:737)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.loadLocal(ExtractingRequestHandlerTest.java:744)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testExtraction(ExtractingRequestHandlerTest.java:63)
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:504)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 

[jira] [Updated] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Ishan Chattopadhyaya (JIRA)]

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

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

IIRC, [~thelabdude] hit upon this once during unit tests; user requests came 
through even before the servlet was initialized. Here's a patch that adds 
checks for core container being null.
However, I'm still not sure how this happened midway through the use of Solr.

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[jira] [Commented] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8068:
--

[~anshumg] If your theory was right, it could have happened only once or twice 
during the startup. If he saw the errors again and again , it has to  be 
something else

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[jira] [Commented] (SOLR-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-7666:
-

[~arafalov] use the one here: http://people.apache.org/~upayavira/webapp.zip 
(don't want to clog JIRA with lots of 1Mb zip files)

> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
> Attachments: SOLR-7666-part2.patch, SOLR-7666-part2.patch, 
> SOLR-7666.patch, admin-ui-7666.zip
>
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



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

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

[jira] [Created] (SOLR-8079) Config API requesthandler command should support "last-components" and "first-components" keys

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-8079:
---

 Summary: Config API requesthandler command should support 
"last-components" and "first-components" keys
 Key: SOLR-8079
 URL: https://issues.apache.org/jira/browse/SOLR-8079
 Project: Solr
  Issue Type: Bug
Reporter: Varun Thacker


There is an example on the reference guide here: 
https://cwiki.apache.org/confluence/display/solr/Config+API

{code}
curl http://localhost:8983/solr/techproducts/config -H 
'Content-type:application/json' -d '{
  "add-requesthandler": {
"name": "/myterms",
"class":"solr.SearchHandler",
"defaults": { "terms":true, "distrib":false },
"components": [ "terms" ]
  }
}'
{code}

I tried extending that and seeing if I could add a spell check component. 

So this is the command I used:

{code}
curl http://localhost:8983/solr/gettingstarted/config -H 
'Content-type:application/json' -d '{
  "create-requesthandler": {
"name": "/myspellcheck",
"class":"solr.SearchHandler",
"last-components": [ "spellcheck" ]
  }
}'
{code}

This seemed to save the information correctly to the configoverlay.json file

{code}
{
  "props":{"updateHandler":{"autoSoftCommit":{"maxTime":3000}}},
  "requestHandler":{"/myspellcheck":{
  "name":"/myspellcheck",
  "class":"solr.SearchHandler",
  "last-components":["spellcheck"]}}
{code}

But I don't think it got loaded as requests didn't have spellcheck responses in 
them.

Example {{http://localhost:8983/solr/gettingstarted/myspellcheck?q=*=text}}

Response 

{noformat}


0
8



{noformat}

So if we are supporting {[components}} we should also support 
{{last-components}} and {{first-components}} as well.



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

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

[jira] [Commented] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8068:


[~noble.paul] correct, that was why I didn't commit this.

[~markus17] thanks for sharing the logs. I just wrote a sample test against 
trunk that creates a collection called "relations" (wanted this to be as close 
as your setup, from the logs) and  #shards as 2, I add a document, commit it 
and then send a delete by query. I use the  CloudSolrClient to do all of this, 
but haven't hit this in multiple runs.

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[jira] [Created] (SOLR-8080) 'bin/solr start' should print informative errors when the JVM version is insufficient

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-8080:


 Summary: 'bin/solr start' should print informative errors when the 
JVM version is insufficient
 Key: SOLR-8080
 URL: https://issues.apache.org/jira/browse/SOLR-8080
 Project: Solr
  Issue Type: Bug
  Components: scripts and tools
Affects Versions: 5.3, Trunk, 5.4
Reporter: Steve Rowe
Priority: Minor


>From the unpacked 5.3.0 distribution, with Java6 set in {{$JAVA_HOME}} and the 
>{{$PATH}}, there is some indication that there is a problem (Java7 is minimum 
>supported JVM version) - bin/solr times out waiting for Solr to start up - but 
>no info is printed about what the problem might be:

{noformat}
$ echo $JAVA_HOME
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

$ java -version
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)

$ bin/solr start
Waiting up to 30 seconds to see Solr running on port 8983 [\]  Still not seeing 
Solr listening on 8983 after 30 seconds!
tail:~/temp/solr-5.3.0/server/logs/solr.log: No such file or directory
{noformat}

On trunk (built via {{ant server}} with Java8), the situation is worse - 
although Solr started, it's not in a usable state, and there is no indication 
given that there is a problem:

{noformat}
$ java -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)

$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home

sarowe@smb [2048]$ bin/solr start
Waiting up to 30 seconds to see Solr running on port 8983 [/]  
Started Solr server on port 8983 (pid=50551). Happy searching!
{noformat}

>From {{server/logs/solr.log}}:

{noformat}
2015-09-21 17:15:28.991 WARN  (main) [   ] o.e.j.u.c.AbstractLifeCycle FAILED So
lrRequestFilter: java.lang.UnsupportedClassVersionError: org/apache/solr/servlet
/SolrDispatchFilter : Unsupported major.minor version 52.0
java.lang.UnsupportedClassVersionError: org/apache/solr/servlet/SolrDispatchFilt
er : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:14
2)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)

[...]

2015-09-21 17:15:29.020 INFO  (main) [   ] o.e.j.s.ServerConnector Started 
ServerConnector@24d25ddc{HTTP/1.1}{0.0.0.0:8983}
2015-09-21 17:15:29.020 INFO  (main) [   ] o.e.j.s.Server Started @1237ms
{noformat}



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

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

[jira] [Commented] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8068:
--

[~markus17] does the same request throw the same error consistently ?

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[jira] [Updated] (SOLR-7569) Create an API to force a leader election between nodes

[Ishan Chattopadhyaya (JIRA)]

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

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

bq. When you use this, it will be because the system is blocking a leader from 
taking over. By running this API command, you remove the blocks, thus 'forcing' 
a leader the system would not normally pick - or at least attempting to force a 
leader the system would not really pick.

That makes sense! :-) I've renamed this to FORCELEADER now. 
Also managed to reincarnate the killed off leaders into the tests.

> Create an API to force a leader election between nodes
> --
>
> Key: SOLR-7569
> URL: https://issues.apache.org/jira/browse/SOLR-7569
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: difficulty-medium, impact-high
> Attachments: SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, 
> SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, 
> SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, 
> SOLR-7569_lir_down_state_test.patch
>
>
> There are many reasons why Solr will not elect a leader for a shard e.g. all 
> replicas' last published state was recovery or due to bugs which cause a 
> leader to be marked as 'down'. While the best solution is that they never get 
> into this state, we need a manual way to fix this when it does get into this  
> state. Right now we can do a series of dance involving bouncing the node 
> (since recovery paths between bouncing and REQUESTRECOVERY are different), 
> but that is difficult when running a large cluster. Although it is possible 
> that such a manual API may lead to some data loss but in some cases, it is 
> the only possible option to restore availability.
> This issue proposes to build a new collection API which can be used to force 
> replicas into recovering a leader while avoiding data loss on a best effort 
> basis.



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

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

[jira] [Commented] (SOLR-8068) NPE in SolrDispatchFilter.authenticateRequest

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-8068:
-

Hello, only when i send a deleteByQuery via SolrJ. I can do a simple commit via 
curl without problems. The deleteAll usually fails, but not always. The error 
is thrown consistently since last week.

> NPE in SolrDispatchFilter.authenticateRequest
> -
>
> Key: SOLR-8068
> URL: https://issues.apache.org/jira/browse/SOLR-8068
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
> Fix For: 5.4
>
> Attachments: SOLR-8068.patch, SOLR-8068.patch
>
>
> Suddenly, one of our Solr 5.3 nodes responds with the following trace when i 
> send a delete all query via SolrJ.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> {code}



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

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

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_60) - Build # 5274 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5274/
Java: 32bit/jdk1.8.0_60 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.lucene.rangetree.TestRangeTree.testRandomMedium

Error Message:
this writer hit an unrecoverable error; cannot complete forceMerge

Stack Trace:
java.lang.IllegalStateException: this writer hit an unrecoverable error; cannot 
complete forceMerge
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1755)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1705)
at 
org.apache.lucene.rangetree.TestRangeTree.verify(TestRangeTree.java:402)
at 
org.apache.lucene.rangetree.TestRangeTree.doTestRandom(TestRangeTree.java:348)
at 
org.apache.lucene.rangetree.TestRangeTree.testRandomMedium(TestRangeTree.java:293)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.AssertionError: 
dir=.\temp\RangeTreeWriter6026117659648459449 still has 
file=.\temp\RangeTreeWriter6026117659648459449\size12437.1937897639691247765
at 
org.apache.lucene.rangetree.RangeTreeWriter.directoryIsEmpty(RangeTreeWriter.java:403)
at 
org.apache.lucene.rangetree.RangeTreeWriter.finish(RangeTreeWriter.java:392)
at 

[jira] [Commented] (SOLR-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7666:
-

Is this definitely the new zip? Because JIRA says the zip is 5 days old.

> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
> Attachments: SOLR-7666-part2.patch, SOLR-7666-part2.patch, 
> SOLR-7666.patch, admin-ui-7666.zip
>
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



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

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

[jira] [Commented] (SOLR-8069) Ensure that only the valid ZooKeeper registered leader can put a replica into Leader Initiated Recovery.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8069:
---

Having had some time to consider this patch, I think this is the right place to 
commit for now. I think further improvements should be spun out into other JIRA 
issues. 

> Ensure that only the valid ZooKeeper registered leader can put a replica into 
> Leader Initiated Recovery.
> 
>
> Key: SOLR-8069
> URL: https://issues.apache.org/jira/browse/SOLR-8069
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Critical
> Attachments: SOLR-8069.patch, SOLR-8069.patch
>
>
> I've seen this twice now. Need to work on a test.
> When some issues hit all the replicas at once, you can end up in a situation 
> where the rightful leader was put or put itself into LIR. Even on restart, 
> this rightful leader won't take leadership and you have to manually clear the 
> LIR nodes.
> It seems that if all the replicas participate in election on startup, LIR 
> should just be cleared.



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

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

[jira] [Created] (SOLR-8081) When creating a collection, we need a way to utilize multiple disks available on a node.

[Timothy Potter (JIRA)]

Timothy Potter created SOLR-8081:


 Summary: When creating a collection, we need a way to utilize 
multiple disks available on a node.
 Key: SOLR-8081
 URL: https://issues.apache.org/jira/browse/SOLR-8081
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Timothy Potter


Currently, if I want to change the dataDir for a core (such as to utilize 
multiple disks on a Solr node), I need to either setup a symlink or change the 
dataDir property in core.properties and restart the Solr node. For instance, if 
I have a 4-node SolrCloud cluster and want to create a collection with 4 shards 
with rf=2, then 8 Solr cores will be created across the cluster, 2 per node. If 
I want to have each core use a separate disk, then I have to do that after the 
fact. I'm aware that I could create the collection with rf=1 and then use 
AddReplica to add additional replicas with a different dataDir set, but that 
feels cumbersome as well.

What would be nice is to have a way for me to specify available disks and have 
Solr use that information when provisioning cores on the node. [~anshumg] 
mentioned this might be best accomplished with a replica placement strategy.



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

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

[jira] [Updated] (LUCENE-6810) Upgrade to Spatial4j 0.5

[David Smiley (JIRA)]

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

David Smiley updated LUCENE-6810:
-
Attachment: LUCENE-6810_Spatial4j_0_5.patch

Here's the patch.

The additional method Shape.getContext() that needs to be implemented accounted 
for the only non-test change.

> Upgrade to Spatial4j 0.5
> 
>
> Key: LUCENE-6810
> URL: https://issues.apache.org/jira/browse/LUCENE-6810
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 5.4
>
> Attachments: LUCENE-6810_Spatial4j_0_5.patch
>
>
> Spatial4j 0.5 was released a few days ago.  There are some bug fixes, most of 
> which were surfaced via the tests here.  It also publishes the test jar 
> (thanks [~nknize] for that one) and with that there are a couple test 
> utilities here I can remove.
> https://github.com/locationtech/spatial4j/blob/master/CHANGES.md



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

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

[jira] [Commented] (SOLR-7666) Umbrella ticket for Angular JS post-5.2.1 issues

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7666:
-

Using the zip at the URL on top of 4.3.1 with URL: 
http://localhost:8983/solr/index.html#/
* Angular error in the logs for the dashboard screen:
{quote}
TypeError: Cannot read property '0' of null
at index.js:27
at angular-resource.min.js:33
at processQueue (angular.js:13193)
at angular.js:13209
at Scope.promises.$get.Scope.$eval (angular.js:14406)
at Scope.promises.$get.Scope.$digest (angular.js:14222)
at Scope.promises.$get.Scope.$apply (angular.js:14511)
at done (angular.js:9669)
at completeRequest (angular.js:9859)
at XMLHttpRequest.requestLoaded (angular.js:9800)
{quote}
* versions are not resolved
* args and bars are not working
* healthcheck message is still there
* the query now has *doNotIntercept* in the request headers
* Logging now seems to return nothing at all though the calls are going out and 
coming back. Initial call missing?
* indent/debug checkboxes seem to work now.


> Umbrella ticket for Angular JS post-5.2.1 issues
> 
>
> Key: SOLR-7666
> URL: https://issues.apache.org/jira/browse/SOLR-7666
> Project: Solr
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 5.3, Trunk
>Reporter: Erick Erickson
>Assignee: Upayavira
> Attachments: SOLR-7666-part2.patch, SOLR-7666-part2.patch, 
> SOLR-7666.patch, admin-ui-7666.zip
>
>
> As of Solr 5.2.1, there's a new admin UI available that has been written 
> almost entirely by Upayavira (thanks!) over the last several months. It's 
> written in Angular JS with an eye towards enhancement/maintainability. The 
> default UI is still the old version, but you can access the new version by 
> going to http:///solr/index.html. There are a couple of fixes 
> between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
> 5.2.1
> The expectation is that in Solr 5.3, the new code will become the default 
> with the old UI deprecated and eventually removed.
> So it would be a great help if volunteers could give the new UI a spin. It 
> should look much the same as the current one at the start, but evolve into 
> something much more interesting and more cloud-friendly. Of course all the 
> new UI code will always be available on trunk/6.0 too, and the up-to-date 
> code will always be on both the trunk and 5x branches.
> Please provide feedback on the user's (or dev) lists about anything you find 
> that doesn't work, or enhancements you'd like to see (or, even better, 
> contribute). If you raise a JIRA, please link it to this one so I can keep 
> track of what needs to be committed. If linking JIRAs is a mystery just add a 
> comment to this JIRA referencing the new JIRA and we can take care of it.
> Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
> track of everything if the patches are attached to sub-JIRAs.
> And a big thanks to Upayavira for this work!



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

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

[jira] [Created] (LUCENE-6810) Upgrade to Spatial4j 0.5

[David Smiley (JIRA)]

David Smiley created LUCENE-6810:


 Summary: Upgrade to Spatial4j 0.5
 Key: LUCENE-6810
 URL: https://issues.apache.org/jira/browse/LUCENE-6810
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 5.4


Spatial4j 0.5 was released a few days ago.  There are some bug fixes, most of 
which were surfaced via the tests here.  It also publishes the test jar (thanks 
[~nknize] for that one) and with that there are a couple test utilities here I 
can remove.

https://github.com/locationtech/spatial4j/blob/master/CHANGES.md



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

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

[jira] [Commented] (SOLR-8069) Ensure that only the valid ZooKeeper registered leader can put a replica into Leader Initiated Recovery.

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8069:


This makes sense and it's also pretty contained. Here are a suggestions:

* That should be CoreDescriptor in the comment.
{code:title=ZkController.java}
+leaderCd); // core node name of current leader
{code}
* Unused import MockCoreContainer in HttpPartitionTest
* In ZkController.markShardAsDownIfLeader(), was the move from using 
getLeaderSeqPath to {{new 
org.apache.hadoop.fs.Path(((ShardLeaderElectionContextBase)context).leaderPath).getParent().toString()}}
 intentional ? 

> Ensure that only the valid ZooKeeper registered leader can put a replica into 
> Leader Initiated Recovery.
> 
>
> Key: SOLR-8069
> URL: https://issues.apache.org/jira/browse/SOLR-8069
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Critical
> Attachments: SOLR-8069.patch, SOLR-8069.patch
>
>
> I've seen this twice now. Need to work on a test.
> When some issues hit all the replicas at once, you can end up in a situation 
> where the rightful leader was put or put itself into LIR. Even on restart, 
> this rightful leader won't take leadership and you have to manually clear the 
> LIR nodes.
> It seems that if all the replicas participate in election on startup, LIR 
> should just be cleared.



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

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

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

[Apache Jenkins Server]

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

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

Error Message:
ERROR: SolrIndexSearcher opens=51 closes=50

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50
at __randomizedtesting.SeedInfo.seed([65FC1865C21E821E]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:467)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:233)
at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=7677, name=searcherExecutor-3802-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=7677, name=searcherExecutor-3802-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([65FC1865C21E821E]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=7677, name=searcherExecutor-3802-thread-1, state=WAITING, 

[jira] [Updated] (SOLR-8080) 'bin/solr start' should print informative errors when the JVM version is insufficient

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8080:
---
Affects Version/s: (was: 5.4)

> 'bin/solr start' should print informative errors when the JVM version is 
> insufficient
> -
>
> Key: SOLR-8080
> URL: https://issues.apache.org/jira/browse/SOLR-8080
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.3, Trunk
>Reporter: Steve Rowe
>Priority: Minor
>
> From the unpacked 5.3.0 distribution, with Java6 set in {{$JAVA_HOME}} and 
> the {{$PATH}}, there is some indication that there is a problem (Java7 is 
> minimum supported JVM version) - bin/solr times out waiting for Solr to start 
> up - but no info is printed about what the problem might be:
> {noformat}
> $ echo $JAVA_HOME
> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> $ java -version
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
> $ bin/solr start
> Waiting up to 30 seconds to see Solr running on port 8983 [\]  Still not 
> seeing Solr listening on 8983 after 30 seconds!
> tail:~/temp/solr-5.3.0/server/logs/solr.log: No such file or directory
> {noformat}
> On trunk (built via {{ant server}} with Java8), the situation is worse - 
> although Solr started, it's not in a usable state, and there is no indication 
> given that there is a problem:
> {noformat}
> $ java -version
> java version "1.7.0_71"
> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
> $ echo $JAVA_HOME
> /Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home
> sarowe@smb [2048]$ bin/solr start
> Waiting up to 30 seconds to see Solr running on port 8983 [/]  
> Started Solr server on port 8983 (pid=50551). Happy searching!
> {noformat}
> From {{server/logs/solr.log}}:
> {noformat}
> 2015-09-21 17:15:28.991 WARN  (main) [   ] o.e.j.u.c.AbstractLifeCycle FAILED 
> So
> lrRequestFilter: java.lang.UnsupportedClassVersionError: 
> org/apache/solr/servlet
> /SolrDispatchFilter : Unsupported major.minor version 52.0
> java.lang.UnsupportedClassVersionError: 
> org/apache/solr/servlet/SolrDispatchFilt
> er : Unsupported major.minor version 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:14
> 2)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> [...]
> 2015-09-21 17:15:29.020 INFO  (main) [   ] o.e.j.s.ServerConnector Started 
> ServerConnector@24d25ddc{HTTP/1.1}{0.0.0.0:8983}
> 2015-09-21 17:15:29.020 INFO  (main) [   ] o.e.j.s.Server Started @1237ms
> {noformat}



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

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

[jira] [Commented] (LUCENE-6808) Term(Ord)ValComparator.value return BytesRefs that are re-used internally

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6808:


I know that's a compromise (thank you), in that it would in fact create no new 
garbage, but I think it's dangerous/unexpected for what is supposed to be a 
"getter" like API to have unexpected side effects like that.

And it's not clear on first inspection that this is a safe thing to do (nowhere 
else do we set this to null) ... all to support what I think is really an abuse 
case of this API (peeking into the slots while collection is still running).

> Term(Ord)ValComparator.value return BytesRefs that are re-used internally
> -
>
> Key: LUCENE-6808
> URL: https://issues.apache.org/jira/browse/LUCENE-6808
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: LUCENE-6808.patch, LUCENE-6808.patch
>
>
> While working on SOLR-6168, which involves some non-trivial usage of 
> {{FieldComparator}}, I discovered some weird bugs anytime I was using 
> TermOrdValComparator.  I ultimately tracked this down to the fact that the 
> {{BytesRef}} instances returned by {{TermOrdValComparator.value(int slot)}} 
> are backed by {{BytesRefBuilder}} instances that the Comparator hangs on to 
> and re-uses -- so the values a caller gets back from 
> {{FieldComparator.value(slot)}} might be changed out from under it before it 
> has a chance to use that value in something like 
> {{FieldComparator.compareValues(first,second)}}.
> The general approach when dealing with BytesRef instances (as i understand 
> it) is that the caller is responsible for making a copy if it wants to hang 
> on to it -- but in this case that would violate the generic API of 
> FieldComparator -- callers would have to pay attention to when a 
> {{FieldComparator}} is a 
> {{FieldComparator}} and do casting to copy the BytesRef.
> It seems like the right solution is for {{TermOrdValComparator.value(slot)}} 
> (and {{TermValComparator.value(slot)}} which has a similar BytesRef usage) to 
> return {{BytesRef.deepCopyOf(values\[slot\])}}



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13979/
Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations {#14 
seed=[81259AC648C50EE8:492E44EF2E21F2EC]}

Error Message:
[Overlaps] qIdx:6 Should have matched I#2:Circle(Pt(x=37.0,y=-58.0), d=41.1° 
4571.45km) Q:Circle(Pt(x=-143.0,y=58.0), d=69.5° 7724.04km)

Stack Trace:
java.lang.AssertionError: [Overlaps] qIdx:6 Should have matched 
I#2:Circle(Pt(x=37.0,y=-58.0), d=41.1° 4571.45km) Q:Circle(Pt(x=-143.0,y=58.0), 
d=69.5° 7724.04km)
at 
__randomizedtesting.SeedInfo.seed([81259AC648C50EE8:492E44EF2E21F2EC]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:127)
at 
org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:121)
at 
org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:56)
at 
org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations(CompositeStrategyTest.java:99)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 

[jira] [Commented] (SOLR-7858) Make Angular UI default

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-7858:
-

[~hossman_luc...@fucit.org] I recall you had suggestions as to how we go about 
releasing the new UI, but I haven't been able to track them down. Are you able 
to repeat them here? (in terms of which URLs are used, and for what).

My proposal would be to leave the current UI as index.html, and have /solr/ 
point at it, and then move admin.html to original.html, such that 
/solr/original.html will point to the old UI.


> Make Angular UI default
> ---
>
> Key: SOLR-7858
> URL: https://issues.apache.org/jira/browse/SOLR-7858
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Reporter: Upayavira
>Assignee: Upayavira
>Priority: Minor
> Attachments: SOLR-7858.patch, new ui link.png, original UI link.png
>
>
> Angular UI is very close to feature complete. Once SOLR-7856 is dealt with, 
> it should function well in most cases. I propose that, as soon as 5.3 has 
> been released, we make the Angular UI default, ready for the 5.4 release. We 
> can then fix any more bugs as they are found, but more importantly start 
> working on the features that were the reason for doing this work in the first 
> place.



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

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