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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testCloudInfoInCoreStatus

Error Message:


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




Build Log:
[...truncated 11729 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPISolrJTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-11000) Changes made via AutoScalingHandler should be atomic

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11000:
--

Thanks Andrzej. I'm glad you got rid of the json maps. Just a few comments on 
the latest code on the branch:
# minor nit -- AutoScalingHandler.handleRemoveTrigger -- loop for removing all 
active listeners can be replaced by 
listeners.keySet().removeAll(activeListeners)
# minor nit - Unused listeners variable in handleSetListener
# The way zkSetAutoScalingConfig is implemented is no longer correct. The loop 
used to read the latest from ZK, update it with the result of the operation 
being performed and then try to write the result using compare-and-set. If 
there is a BadVersionException, all the steps were tried again. Now it will 
just loop forever on a BadVersionException because the read from ZK part is 
never tried again. It'd be nice to add a test to exercise this path. I think it 
wasn't correct earlier too but it was bad in a different way (infinite loop vs 
incorrect data) 
# Is the deep copy of jsonMap in the constructor of AutoScalingConfig still 
necessary? same for the parseInt call for version

> Changes made via AutoScalingHandler should be atomic
> 
>
> Key: SOLR-11000
> URL: https://issues.apache.org/jira/browse/SOLR-11000
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
>  Labels: autoscaling
> Fix For: 7.0
>
> Attachments: SOLR-11000.patch, SOLR-11000.patch
>
>
> Currently, AutoScalingHandler writes the result of each command to ZK 
> individually. So if you send 3 commands in a payload, it will write them 
> individually. We really should make it atomic so that the result of all the 
> commands are persisted together or none at all.



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

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

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

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test

Error Message:
The Monkey ran for over 45 seconds and no jetties were stopped - this is worth 
investigating!

Stack Trace:
java.lang.AssertionError: The Monkey ran for over 45 seconds and no jetties 
were stopped - this is worth investigating!
at 
__randomizedtesting.SeedInfo.seed([57BDCF540E9917CD:DFE9F08EA0657A35]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.apache.solr.cloud.ChaosMonkey.stopTheMonkey(ChaosMonkey.java:587)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-7905) Optimizations for OrdinalMap

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7905:
-

I think its good to pull out OrdinalMap into its own class from MultiDocValues, 
but i think its a little trappy that it then has no warnings on it and just 
some cool sounding javadocs.

MultiDocValues still warns you twice: 
https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/MultiDocValues.java#L40-L46

But I think we should have some kind of doc about the cost of this thing in 
OrdinalMap now that its separated? The "tax" of multiple segments is real here, 
makes it a hotspot just like it is for blocktree term dictionaries at merge.

> Optimizations for OrdinalMap
> 
>
> Key: LUCENE-7905
> URL: https://issues.apache.org/jira/browse/LUCENE-7905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 7.1
>
> Attachments: LUCENE-7905.patch, LUCENE-7905.patch, 
> LUCENE-7905-specialized.patch
>
>
> {{OrdinalMap}} is a useful class to quickly map per-segment ordinals to 
> global space, but it's fairly costly to build, which must typically be done 
> on every NRT refresh.
> I'm using it quite heavily in two different places, one for 
> {{SortedSetDocValuesFacetCounts}}, and another custom usage, and I found some 
> small optimizations to improve its construction time.
> I switched it to use a simple priority queue to merge the terms instead of 
> the more general {{MultiTermsEnum}}, which does extra work since it must also 
> provide postings, implement seekExact, etc.
> I also pulled {{OrdinalMap}} out into its own oal.index class.
> When testing construction time for my case the patch is ~16% faster (159.9s 
> -> 134.2s) in one case with 91.4 M terms and ~9% faster (115.6s -> 105.7s) in 
> another case with 26.6 M terms.



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

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

[JENKINS-EA] Lucene-Solr-7.x-Windows (64bit/jdk-9-ea+173) - Build # 35 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/35/
Java: 64bit/jdk-9-ea+173 -XX:+UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([BB85313FF1D1B767:D9E8CF7E3E5FD759]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.junit.Assert.assertNotNull(Assert.java:537)
at 
org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter(MetricsHandlerTest.java:201)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.component.InfixSuggestersTest

Error Message:
Could not remove the following files (in the order of attempts):

[jira] [Commented] (SOLR-11050) Ref Guide: Remove Confluence-style anchor refs & clean up duplicate section titles

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11050:


Commit 8b65515f073e6b9de063fda2df775dc8595339c1 in lucene-solr's branch 
refs/heads/master from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8b65515 ]

SOLR-11050: remove Confluence-style anchors and fix all incoming links


> Ref Guide: Remove Confluence-style anchor refs & clean up duplicate section 
> titles
> --
>
> Key: SOLR-11050
> URL: https://issues.apache.org/jira/browse/SOLR-11050
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: 7.0
>
>
> To ensure section and page title uniqueness during conversion, we retained 
> Confluence-style anchor references in the new .adoc files, which lead to long 
> links and confusion about how to construct a link to another page/section. It 
> was always the intention to remove these, but we didn't do it during the 
> initial post-conversion cleanup and I neglected to file an issue for it.
> A script for this has been suggested, but that's problematic because many 
> section titles are repeated on different pages (like "Input", etc.), and 
> someone needs to decide how to modify the section titles to ensure clarity 
> and uniqueness at the same time. Otherwise, Ref Guide builds will fail.



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

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

Re: [JENKINS] Solr-reference-guide-7.0 - Build # 66 - Still Failing

[Cassandra Targett]

The errors from earlier builds (and the last failing on for
Solr-reference-guide-master) seem to indicate a possible Ruby version
issue, if this SO article is a valid clue:
https://stackoverflow.com/questions/40085215/listen-conflict-when-installing-jekyll-with-docker

"listen" is installed with the jekyll gem as a dependency. See also
https://github.com/guard/listen and notes about Ruby versions there.

Not clear to me why this would have suddenly changed - I checked
release history for these gems and Jekyll did have a new version
release Jun 15, but I think we would have seen this way earlier if it
was from dependency changes in that update.

Let me know if you need help looking into this further.

On Wed, Jul 12, 2017 at 7:22 PM, Steve Rowe  wrote:
> I’ve disabled the ref guide builds until I can get to the bottom of the Ruby 
> problems.
>
> --
> Steve
> www.lucidworks.com
>
>> On Jul 12, 2017, at 8:18 PM, Apache Jenkins Server 
>>  wrote:
>>
>> Build: https://builds.apache.org/job/Solr-reference-guide-7.0/66/
>>
>> Log:
>> Started by user sarowe
>> [EnvInject] - Loading node environment variables.
>> Building remotely on H20 (git-websites) in workspace 
>> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-7.0
>>> git rev-parse --is-inside-work-tree # timeout=10
>> Fetching changes from the remote Git repository
>>> git config remote.origin.url git://git.apache.org/lucene-solr.git # 
>>> timeout=10
>> Cleaning workspace
>>> git rev-parse --verify HEAD # timeout=10
>> Resetting working tree
>>> git reset --hard # timeout=10
>>> git clean -fdx # timeout=10
>> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>>> git --version # timeout=10
>>> git fetch --tags --progress git://git.apache.org/lucene-solr.git 
>>> +refs/heads/*:refs/remotes/origin/*
>>> git rev-parse refs/remotes/origin/branch_7_0^{commit} # timeout=10
>>> git rev-parse refs/remotes/origin/origin/branch_7_0^{commit} # timeout=10
>> Checking out Revision 8c000d9ae67ce3a6942173263570b3b1770bd788 
>> (refs/remotes/origin/branch_7_0)
>>> git config core.sparsecheckout # timeout=10
>>> git checkout -f 8c000d9ae67ce3a6942173263570b3b1770bd788
>>> git rev-list 8c000d9ae67ce3a6942173263570b3b1770bd788 # timeout=10
>> No emails were triggered.
>> [Solr-reference-guide-7.0] $ /bin/bash -xe /tmp/hudson1083622664334795049.sh
>> + echo 'Set ruby path to avoid writing to /usr directory'
>> Set ruby path to avoid writing to /usr directory
>> + export RUBY_PATH=/home/jenkins/shared/.rvm
>> + RUBY_PATH=/home/jenkins/shared/.rvm
>> + export GEM_HOME=/home/jenkins/shared/.rvm/gems
>> + GEM_HOME=/home/jenkins/shared/.rvm/gems
>> + curl -sSL https://get.rvm.io
>> + grep -v __rvm_print_headline
>> + bash -s stable --ruby --path /home/jenkins/shared/.rvm
>> Downloading https://github.com/rvm/rvm/archive/1.29.2.tar.gz
>> Downloading 
>> https://github.com/rvm/rvm/releases/download/1.29.2/1.29.2.tar.gz.asc
>> Found PGP signature at: 
>> 'https://github.com/rvm/rvm/releases/download/1.29.2/1.29.2.tar.gz.asc',
>> but no GPG software exists to validate it, skipping.
>>
>> Upgrading the RVM installation in /home/jenkins/shared/.rvm/
>>RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
>> /home/jenkins/.bashrc /home/jenkins/.zshrc.
>>RVM sourcing line found in /home/jenkins/.profile 
>> /home/jenkins/.bash_profile /home/jenkins/.zlogin.
>> Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
>>
>> # jenkins,
>> #
>> #   Thank you for using RVM!
>> #   We sincerely hope that RVM helps to make your life easier and more 
>> enjoyable!!!
>> #
>> # ~Wayne, Michal & team.
>>
>> In case of problems: https://rvm.io/help and https://twitter.com/rvm_io
>>
>> Upgrade Notes:
>>
>>  * It looks like some old stuff is laying around RVM, you can cleanup with: 
>> rvm cleanup all
>>
>>  * No new notes to display.
>>
>> Warning! PATH is not properly set up, '/home/jenkins/shared/.rvm/gems/bin' 
>> is not available.
>> Usually this is caused by shell initialization files. Search for 
>> 'PATH=...' entries.
>> You can also re-add RVM to your profile by running: 'rvm get stable 
>> --auto-dotfiles'.
>> To fix it temporarily in this shell session run: 'rvm use gems'.
>> To ignore this error add rvm_silence_path_mismatch_check_flag=1 to 
>> your ~/.rvmrc file.
>> Searching for binary rubies, this might take some time.
>> Found remote file 
>> https://rvm_io.global.ssl.fastly.net/binaries/ubuntu/16.04/x86_64/ruby-2.4.0.tar.bz2
>> Checking requirements for ubuntu.
>> Installing requirements for ubuntu.
>> Updating system...
>> Error running 'requirements_debian_update_system ruby-2.4.0',
>> showing last 15 lines of 
>> /home/jenkins/shared/.rvm/log/1499905133_ruby-2.4.0/update_system.log
>> ++ /scripts/functions/utility : __rvm_try_sudo()  377 > [[ -d /usr/sbin ]]
>> ++ /scripts/functions/utility : __rvm_try_sudo()  377 > [[ 
>> 

[jira] [Commented] (SOLR-11050) Ref Guide: Remove Confluence-style anchor refs & clean up duplicate section titles

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11050:


Commit 74ab16168c8a988e5190cc6e032039c43a262f0e in lucene-solr's branch 
refs/heads/master from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=74ab161 ]

SOLR-11050: remove unneeded anchors for pages that have no incoming links from 
other pages


> Ref Guide: Remove Confluence-style anchor refs & clean up duplicate section 
> titles
> --
>
> Key: SOLR-11050
> URL: https://issues.apache.org/jira/browse/SOLR-11050
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: 7.0
>
>
> To ensure section and page title uniqueness during conversion, we retained 
> Confluence-style anchor references in the new .adoc files, which lead to long 
> links and confusion about how to construct a link to another page/section. It 
> was always the intention to remove these, but we didn't do it during the 
> initial post-conversion cleanup and I neglected to file an issue for it.
> A script for this has been suggested, but that's problematic because many 
> section titles are repeated on different pages (like "Input", etc.), and 
> someone needs to decide how to modify the section titles to ensure clarity 
> and uniqueness at the same time. Otherwise, Ref Guide builds will fail.



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

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

Re: [JENKINS] Solr-reference-guide-7.0 - Build # 66 - Still Failing

[Steve Rowe]

I’ve disabled the ref guide builds until I can get to the bottom of the Ruby 
problems.

--
Steve
www.lucidworks.com

> On Jul 12, 2017, at 8:18 PM, Apache Jenkins Server 
>  wrote:
> 
> Build: https://builds.apache.org/job/Solr-reference-guide-7.0/66/
> 
> Log: 
> Started by user sarowe
> [EnvInject] - Loading node environment variables.
> Building remotely on H20 (git-websites) in workspace 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-7.0
>> git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>> git config remote.origin.url git://git.apache.org/lucene-solr.git # 
>> timeout=10
> Cleaning workspace
>> git rev-parse --verify HEAD # timeout=10
> Resetting working tree
>> git reset --hard # timeout=10
>> git clean -fdx # timeout=10
> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>> git --version # timeout=10
>> git fetch --tags --progress git://git.apache.org/lucene-solr.git 
>> +refs/heads/*:refs/remotes/origin/*
>> git rev-parse refs/remotes/origin/branch_7_0^{commit} # timeout=10
>> git rev-parse refs/remotes/origin/origin/branch_7_0^{commit} # timeout=10
> Checking out Revision 8c000d9ae67ce3a6942173263570b3b1770bd788 
> (refs/remotes/origin/branch_7_0)
>> git config core.sparsecheckout # timeout=10
>> git checkout -f 8c000d9ae67ce3a6942173263570b3b1770bd788
>> git rev-list 8c000d9ae67ce3a6942173263570b3b1770bd788 # timeout=10
> No emails were triggered.
> [Solr-reference-guide-7.0] $ /bin/bash -xe /tmp/hudson1083622664334795049.sh
> + echo 'Set ruby path to avoid writing to /usr directory'
> Set ruby path to avoid writing to /usr directory
> + export RUBY_PATH=/home/jenkins/shared/.rvm
> + RUBY_PATH=/home/jenkins/shared/.rvm
> + export GEM_HOME=/home/jenkins/shared/.rvm/gems
> + GEM_HOME=/home/jenkins/shared/.rvm/gems
> + curl -sSL https://get.rvm.io
> + grep -v __rvm_print_headline
> + bash -s stable --ruby --path /home/jenkins/shared/.rvm
> Downloading https://github.com/rvm/rvm/archive/1.29.2.tar.gz
> Downloading 
> https://github.com/rvm/rvm/releases/download/1.29.2/1.29.2.tar.gz.asc
> Found PGP signature at: 
> 'https://github.com/rvm/rvm/releases/download/1.29.2/1.29.2.tar.gz.asc',
> but no GPG software exists to validate it, skipping.
> 
> Upgrading the RVM installation in /home/jenkins/shared/.rvm/
>RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
> /home/jenkins/.bashrc /home/jenkins/.zshrc.
>RVM sourcing line found in /home/jenkins/.profile 
> /home/jenkins/.bash_profile /home/jenkins/.zlogin.
> Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
> 
> # jenkins,
> #
> #   Thank you for using RVM!
> #   We sincerely hope that RVM helps to make your life easier and more 
> enjoyable!!!
> #
> # ~Wayne, Michal & team.
> 
> In case of problems: https://rvm.io/help and https://twitter.com/rvm_io
> 
> Upgrade Notes:
> 
>  * It looks like some old stuff is laying around RVM, you can cleanup with: 
> rvm cleanup all
> 
>  * No new notes to display.
> 
> Warning! PATH is not properly set up, '/home/jenkins/shared/.rvm/gems/bin' is 
> not available.
> Usually this is caused by shell initialization files. Search for 
> 'PATH=...' entries.
> You can also re-add RVM to your profile by running: 'rvm get stable 
> --auto-dotfiles'.
> To fix it temporarily in this shell session run: 'rvm use gems'.
> To ignore this error add rvm_silence_path_mismatch_check_flag=1 to 
> your ~/.rvmrc file.
> Searching for binary rubies, this might take some time.
> Found remote file 
> https://rvm_io.global.ssl.fastly.net/binaries/ubuntu/16.04/x86_64/ruby-2.4.0.tar.bz2
> Checking requirements for ubuntu.
> Installing requirements for ubuntu.
> Updating system...
> Error running 'requirements_debian_update_system ruby-2.4.0',
> showing last 15 lines of 
> /home/jenkins/shared/.rvm/log/1499905133_ruby-2.4.0/update_system.log
> ++ /scripts/functions/utility : __rvm_try_sudo()  377 > [[ -d /usr/sbin ]]
> ++ /scripts/functions/utility : __rvm_try_sudo()  377 > [[ 
> :/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/jenkins/shared/.rvm/bin:
>  != *\:\/\u\s\r\/\s\b\i\n\:* ]]
> ++ /scripts/functions/utility : __rvm_try_sudo()  375 > for sbin_path in 
> /sbin /usr/sbin /usr/local/sbin
> ++ /scripts/functions/utility : __rvm_try_sudo()  377 > [[ -d /usr/local/sbin 
> ]]
> ++ /scripts/functions/utility : __rvm_try_sudo()  377 > [[ 
> :/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/jenkins/shared/.rvm/bin:
>  != *\:\/\u\s\r\/\l\o\c\a\l\/\s\b\i\n\:* ]]
> ++ /scripts/functions/utility : __rvm_try_sudo()  381 > [[ -n '' ]]
> ++ /scripts/functions/utility : __rvm_try_sudo()  384 > 
> command_to_run=(__rvm_sudo -p "%p password required for '$*': " 
> "${command_to_run[@]}")
> ++ 

[jira] [Resolved] (SOLR-11060) Randomize PointFields in schema-custom-field.xml and all related tests

[Anshum Gupta (JIRA)]

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

Anshum Gupta resolved SOLR-11060.
-
Resolution: Fixed

> Randomize PointFields in schema-custom-field.xml and all related tests
> --
>
> Key: SOLR-11060
> URL: https://issues.apache.org/jira/browse/SOLR-11060
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0, master (8.0), 7.1
>
>




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

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

[jira] [Commented] (SOLR-11060) Randomize PointFields in schema-custom-field.xml and all related tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11060:


Commit 8c000d9ae67ce3a6942173263570b3b1770bd788 in lucene-solr's branch 
refs/heads/branch_7_0 from [~anshumg]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8c000d9 ]

SOLR-11060: Randomize PointFields in schema-custom-field.xml and all related 
tests


> Randomize PointFields in schema-custom-field.xml and all related tests
> --
>
> Key: SOLR-11060
> URL: https://issues.apache.org/jira/browse/SOLR-11060
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0, master (8.0), 7.1
>
>




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

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

[JENKINS] Solr-reference-guide-7.0 - Build # 66 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-7.0/66/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on H20 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-7.0
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_7_0^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_7_0^{commit} # timeout=10
Checking out Revision 8c000d9ae67ce3a6942173263570b3b1770bd788 
(refs/remotes/origin/branch_7_0)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 8c000d9ae67ce3a6942173263570b3b1770bd788
 > git rev-list 8c000d9ae67ce3a6942173263570b3b1770bd788 # timeout=10
No emails were triggered.
[Solr-reference-guide-7.0] $ /bin/bash -xe /tmp/hudson1083622664334795049.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ grep -v __rvm_print_headline
+ bash -s stable --ruby --path /home/jenkins/shared/.rvm
Downloading https://github.com/rvm/rvm/archive/1.29.2.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.2/1.29.2.tar.gz.asc
Found PGP signature at: 
'https://github.com/rvm/rvm/releases/download/1.29.2/1.29.2.tar.gz.asc',
but no GPG software exists to validate it, skipping.

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

# jenkins,
#
#   Thank you for using RVM!
#   We sincerely hope that RVM helps to make your life easier and more 
enjoyable!!!
#
# ~Wayne, Michal & team.

In case of problems: https://rvm.io/help and https://twitter.com/rvm_io

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

Warning! PATH is not properly set up, '/home/jenkins/shared/.rvm/gems/bin' is 
not available.
 Usually this is caused by shell initialization files. Search for 
'PATH=...' entries.
 You can also re-add RVM to your profile by running: 'rvm get stable 
--auto-dotfiles'.
 To fix it temporarily in this shell session run: 'rvm use gems'.
 To ignore this error add rvm_silence_path_mismatch_check_flag=1 to 
your ~/.rvmrc file.
Searching for binary rubies, this might take some time.
Found remote file 
https://rvm_io.global.ssl.fastly.net/binaries/ubuntu/16.04/x86_64/ruby-2.4.0.tar.bz2
Checking requirements for ubuntu.
Installing requirements for ubuntu.
Updating system...
Error running 'requirements_debian_update_system ruby-2.4.0',
showing last 15 lines of 
/home/jenkins/shared/.rvm/log/1499905133_ruby-2.4.0/update_system.log
++ /scripts/functions/utility : __rvm_try_sudo()  377 > [[ -d /usr/sbin ]]
++ /scripts/functions/utility : __rvm_try_sudo()  377 > [[ 
:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/jenkins/shared/.rvm/bin:
 != *\:\/\u\s\r\/\s\b\i\n\:* ]]
++ /scripts/functions/utility : __rvm_try_sudo()  375 > for sbin_path in /sbin 
/usr/sbin /usr/local/sbin
++ /scripts/functions/utility : __rvm_try_sudo()  377 > [[ -d /usr/local/sbin ]]
++ /scripts/functions/utility : __rvm_try_sudo()  377 > [[ 
:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/jenkins/shared/.rvm/bin:
 != *\:\/\u\s\r\/\l\o\c\a\l\/\s\b\i\n\:* ]]
++ /scripts/functions/utility : __rvm_try_sudo()  381 > [[ -n '' ]]
++ /scripts/functions/utility : __rvm_try_sudo()  384 > 
command_to_run=(__rvm_sudo -p "%p password required for '$*': " 
"${command_to_run[@]}")
++ /scripts/functions/utility : __rvm_try_sudo()  391 > __rvm_sudo -p '%p 
password required for '\''apt-get --quiet --yes update'\'': ' apt-get --quiet 
--yes update
++ /scripts/functions/support : __rvm_sudo()  358 > command sudo -p '%p 
password required for '\''apt-get --quiet --yes update'\'': ' apt-get --quiet 
--yes update
++ /scripts/functions/support : __rvm_sudo()  358 > sudo -p '%p password 

[jira] [Commented] (SOLR-11060) Randomize PointFields in schema-custom-field.xml and all related tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11060:


Commit e8c74e8ce68da7f6050f5024315f190bf58d75ce in lucene-solr's branch 
refs/heads/branch_7x from [~anshumg]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e8c74e8 ]

SOLR-11060: Randomize PointFields in schema-custom-field.xml and all related 
tests


> Randomize PointFields in schema-custom-field.xml and all related tests
> --
>
> Key: SOLR-11060
> URL: https://issues.apache.org/jira/browse/SOLR-11060
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0
>
>




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

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

[jira] [Updated] (SOLR-11060) Randomize PointFields in schema-custom-field.xml and all related tests

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-11060:

Fix Version/s: 7.1
   master (8.0)

> Randomize PointFields in schema-custom-field.xml and all related tests
> --
>
> Key: SOLR-11060
> URL: https://issues.apache.org/jira/browse/SOLR-11060
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0, master (8.0), 7.1
>
>




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

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

[jira] [Created] (SOLR-11060) Randomize PointFields in schema-custom-field.xml and all related tests

[Anshum Gupta (JIRA)]

Anshum Gupta created SOLR-11060:
---

 Summary: Randomize PointFields in schema-custom-field.xml and all 
related tests
 Key: SOLR-11060
 URL: https://issues.apache.org/jira/browse/SOLR-11060
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Anshum Gupta
Assignee: Anshum Gupta






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

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

[jira] [Commented] (SOLR-11060) Randomize PointFields in schema-custom-field.xml and all related tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11060:


Commit 47731ce0a4a0606dc351bf69e941b654d5fd9a4f in lucene-solr's branch 
refs/heads/master from [~anshumg]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=47731ce ]

SOLR-11060: Randomize PointFields in schema-custom-field.xml and all related 
tests


> Randomize PointFields in schema-custom-field.xml and all related tests
> --
>
> Key: SOLR-11060
> URL: https://issues.apache.org/jira/browse/SOLR-11060
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0
>
>




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

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

[JENKINS] Solr-reference-guide-master - Build # 526 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/526/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H19 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 7b5c50c3c8cf904263e81def84783a4988548930 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7b5c50c3c8cf904263e81def84783a4988548930
 > git rev-list 8d7e3cc9294a1cdb5323ac1d068de3ec387ee0fb # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/hudson8287330954236613870.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s -- --path /home/jenkins/shared/.rvm
Downloading https://github.com/rvm/rvm/archive/master.tar.gz

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

+ mkdir -p /home/jenkins/shared/.rvm/gems/gems
+ gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll 
jekyll-asciidoc pygments.rb
ERROR:  Error installing jekyll:
"listen" from sass-listen conflicts with installed executable from 
listen
ERROR:  Error installing jekyll-asciidoc:
"listen" from sass-listen conflicts with installed executable from 
listen
Successfully installed pygments.rb-1.1.2
1 gem installed
Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-NightlyTests-7.0 - Build # 3 - Failure

[Apache Jenkins Server]

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

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

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([51B24AF99DC8185A:3DA7193FAC87B1A]:0)
at java.lang.StringCoding.decode(StringCoding.java:215)
at java.lang.String.(String.java:463)
at org.apache.lucene.store.DataInput.readString(DataInput.java:238)
at 
org.apache.lucene.store.DataInput.readMapOfStrings(DataInput.java:273)
at 
org.apache.lucene.codecs.lucene70.Lucene70SegmentInfoFormat.read(Lucene70SegmentInfoFormat.java:119)
at 
org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:355)
at 
org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:289)
at 
org.apache.lucene.index.DirectoryReader.listCommits(DirectoryReader.java:277)
at 
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressConcurrentAddAndDeleteAndCommit(TestIndexingSequenceNumbers.java:554)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)




Build Log:
[...truncated 851 lines...]
   [junit4] Suite: org.apache.lucene.index.TestIndexingSequenceNumbers
   [junit4]   2> NOTE: download the large Jenkins line-docs file by running 
'ant get-jenkins-line-docs' in the lucene directory.
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestIndexingSequenceNumbers 
-Dtests.method=testStressConcurrentAddAndDeleteAndCommit 
-Dtests.seed=51B24AF99DC8185A -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.0/test-data/enwiki.random.lines.txt
 -Dtests.locale=id -Dtests.timezone=America/Grenada -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR586s J0 | 
TestIndexingSequenceNumbers.testStressConcurrentAddAndDeleteAndCommit <<<
   [junit4]> Throwable #1: java.lang.OutOfMemoryError: Java heap space
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([51B24AF99DC8185A:3DA7193FAC87B1A]:0)
   [junit4]>at java.lang.StringCoding.decode(StringCoding.java:215)
   [junit4]>at java.lang.String.(String.java:463)
   [junit4]>at 
org.apache.lucene.store.DataInput.readString(DataInput.java:238)
   [junit4]>at 
org.apache.lucene.store.DataInput.readMapOfStrings(DataInput.java:273)
   [junit4]>at 
org.apache.lucene.codecs.lucene70.Lucene70SegmentInfoFormat.read(Lucene70SegmentInfoFormat.java:119)
   [junit4]>at 

[JENKINS] Solr-reference-guide-7.0 - Build # 62 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-7.0/62/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on H20 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-7.0
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_7_0^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_7_0^{commit} # timeout=10
Checking out Revision da1afd596bc83235918d19ff5fdbe5267c76f457 
(refs/remotes/origin/branch_7_0)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f da1afd596bc83235918d19ff5fdbe5267c76f457
 > git rev-list da1afd596bc83235918d19ff5fdbe5267c76f457 # timeout=10
No emails were triggered.
[Solr-reference-guide-7.0] $ /bin/bash -xe /tmp/hudson5653265034154279224.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s --ruby -- --path /home/jenkins/shared/.rvm
bash: --: invalid option
Usage:  bash [GNU long option] [option] ...
bash [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--rcfile
--restricted
--verbose
--version
Shell options:
-ilrsD or -c command or -O shopt_option (invocation only)
-abefhkmnptuvxBCHP or -o option
curl: (23) Failed writing body (2171 != 2759)
Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Solr-reference-guide-7.0 - Build # 61 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-7.0/61/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on H20 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-7.0
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_7_0^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_7_0^{commit} # timeout=10
Checking out Revision da1afd596bc83235918d19ff5fdbe5267c76f457 
(refs/remotes/origin/branch_7_0)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f da1afd596bc83235918d19ff5fdbe5267c76f457
 > git rev-list da1afd596bc83235918d19ff5fdbe5267c76f457 # timeout=10
No emails were triggered.
[Solr-reference-guide-7.0] $ /bin/bash -xe /tmp/hudson7638003946236217237.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s stable --ruby -- --path /home/jenkins/shared/.rvm


Usage

  rvm-installer [options] [action]

Options

  [[--]version] 

The version or tag to install. Valid values are:

  latest - The latest tagged version.
  latest-minor   - The latest minor version of the current major version.
  latest- - The latest minor version of version x.
  latest-. - The latest patch version of version x.y.
  ..- Major version x, minor version y and patch z.

  [--]branch 

The name of the branch from which RVM is installed. This option can be used
with the following formats for :

  /

If account is rvm or mpapis, installs from one of the following:

  https://github.com/rvm/rvm/archive/master.tar.gz
  https://bitbucket.org/mpapis/rvm/get/master.tar.gz

   Otherwise, installs from:

 https://github.com//rvm/archive/master.tar.gz

  /

If account is rvm or mpapis, installs from one of the following:

  https://github.com/rvm/rvm/archive/.tar.gz
  https://bitbucket.org/mpapis/rvm/get/.tar.gz

Otherwise, installs from:

  https://github.com//rvm/archive/.tar.gz

  [/]

Installs the branch from one of the following:

  https://github.com/rvm/rvm/archive/.tar.gz
  https://bitbucket.org/mpapis/rvm/get/.tar.gz

  [--]source 

Defines the repository from which RVM is retrieved and installed in the 
format:

  //

Where:

- Is bitbucket.org, github.com or a github enterprise site 
serving
  an RVM repository.
   - Is the user account in which the RVM repository resides.
  - Is the name of the RVM repository.

Note that when using the [--]source option, one should only use the 
[/]branch format
with the [--]branch option. Failure to do so will result in undefined 
behavior.

  --trace

Provides debug logging for the installation script.
Actions

  master - Installs RVM from the master branch at rvm/rvm on github or 
mpapis/rvm
   on bitbucket.org.
  stable - Installs RVM from the stable branch a rvm/rvm on github or mpapis/rvm
   on bitbucket.org.
  help   - Displays this output.

Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Updated] (SOLR-11057) RangeQuery can overflow in PointFields when quering the type limits

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-11057:
-
Attachment: SOLR-11057.patch

Same patch including DatePointField

> RangeQuery can overflow in PointFields when quering the type limits
> ---
>
> Key: SOLR-11057
> URL: https://issues.apache.org/jira/browse/SOLR-11057
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-11057.patch, SOLR-11057.patch
>
>
> This can happen when the upper limit of the range is the lowest value of the 
> type or when the lower limit is the max value of the type. For example:
> {{q=field_i:{Integer.MAX_VALUE TO Integer.MAX_VALUE]}}. Note that this should 
> not return any docs



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

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

[JENKINS] Solr-reference-guide-7.0 - Build # 60 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-7.0/60/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on H20 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-7.0
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_7_0^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_7_0^{commit} # timeout=10
Checking out Revision da1afd596bc83235918d19ff5fdbe5267c76f457 
(refs/remotes/origin/branch_7_0)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f da1afd596bc83235918d19ff5fdbe5267c76f457
 > git rev-list da1afd596bc83235918d19ff5fdbe5267c76f457 # timeout=10
No emails were triggered.
[Solr-reference-guide-7.0] $ /bin/bash -xe /tmp/hudson8878552537968658861.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s -- --path /home/jenkins/shared/.rvm --ruby '--gems=jekyll 
jekyll-asciidoc pygments.rb'
Downloading https://github.com/rvm/rvm/archive/master.tar.gz

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

Ruby enVironment Manager 1.29.2 (master) (c) 2009-2017 Michal Papis, Piotr 
Kuczynski, Wayne E. Seguin

Warning! PATH is not properly set up, '/home/jenkins/shared/.rvm/gems/bin' is 
not available.
 Usually this is caused by shell initialization files. Search for 
'PATH=...' entries.
 You can also re-add RVM to your profile by running: 'rvm get stable 
--auto-dotfiles'.
 To fix it temporarily in this shell session run: 'rvm use gems'.
 To ignore this error add rvm_silence_path_mismatch_check_flag=1 to 
your ~/.rvmrc file.
Searching for binary rubies, this might take some time.
Found remote file 
https://rvm_io.global.ssl.fastly.net/binaries/ubuntu/16.04/x86_64/ruby-2.4.1.tar.bz2
Checking requirements for ubuntu.
Installing requirements for ubuntu.
Updating system...
Error running 'requirements_debian_update_system ruby-2.4.1',
please read 
/home/jenkins/shared/.rvm/log/1499903762_ruby-2.4.1/update_system.log
Requirements installation failed with status: 1.
Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Solr-reference-guide-7.0 - Build # 59 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-7.0/59/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on H20 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-7.0
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_7_0^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_7_0^{commit} # timeout=10
Checking out Revision da1afd596bc83235918d19ff5fdbe5267c76f457 
(refs/remotes/origin/branch_7_0)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f da1afd596bc83235918d19ff5fdbe5267c76f457
 > git rev-list da1afd596bc83235918d19ff5fdbe5267c76f457 # timeout=10
No emails were triggered.
[Solr-reference-guide-7.0] $ /bin/bash -xe /tmp/hudson4008915445306486527.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s stable --path /home/jenkins/shared/.rvm --ruby '--gems=jekyll 
jekyll-asciidoc pygments.rb'
Downloading https://github.com/rvm/rvm/archive/1.29.2.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.2/1.29.2.tar.gz.asc
Found PGP signature at: 
'https://github.com/rvm/rvm/releases/download/1.29.2/1.29.2.tar.gz.asc',
but no GPG software exists to validate it, skipping.

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

# jenkins,
#
#   Thank you for using RVM!
#   We sincerely hope that RVM helps to make your life easier and more 
enjoyable!!!
#
# ~Wayne, Michal & team.

In case of problems: https://rvm.io/help and https://twitter.com/rvm_io

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

bash: line 880: __rvm_print_headline: command not found
Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Solr-reference-guide-7.0 - Build # 58 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-7.0/58/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on H20 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-7.0
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_7_0^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_7_0^{commit} # timeout=10
Checking out Revision da1afd596bc83235918d19ff5fdbe5267c76f457 
(refs/remotes/origin/branch_7_0)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f da1afd596bc83235918d19ff5fdbe5267c76f457
 > git rev-list da1afd596bc83235918d19ff5fdbe5267c76f457 # timeout=10
No emails were triggered.
[Solr-reference-guide-7.0] $ /bin/bash -xe /tmp/hudson8164475392279456249.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s stable --path /home/jenkins/shared/.rvm --ruby '--gems=jekyll 
jekyll-asciidoc pygments.rb'
Downloading https://github.com/rvm/rvm/archive/1.29.2.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.2/1.29.2.tar.gz.asc
Found PGP signature at: 
'https://github.com/rvm/rvm/releases/download/1.29.2/1.29.2.tar.gz.asc',
but no GPG software exists to validate it, skipping.

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

# jenkins,
#
#   Thank you for using RVM!
#   We sincerely hope that RVM helps to make your life easier and more 
enjoyable!!!
#
# ~Wayne, Michal & team.

In case of problems: https://rvm.io/help and https://twitter.com/rvm_io

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

bash: line 880: __rvm_print_headline: command not found
Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

Re: [JENKINS] Lucene-Solr-NightlyTests-master - Build # 1352 - Still Failing

[Steve Rowe]

The disk allocation for the “lucene2” node was increased and it’s back in 
rotation now after being offline for a while to perform the operation.  
 is in progress 
now.

--
Steve
www.lucidworks.com

> On Jul 12, 2017, at 9:26 AM, Steve Rowe  wrote:
> 
> I created  for the 
> "lucene2” disk space problem.
> 
> On Hipchat Chris Thistlthwaite (@christ) said he would start looking at the 
> box.
> 
> --
> Steve
> www.lucidworks.com
> 
>> On Jul 12, 2017, at 8:54 AM, Steve Rowe  wrote:
>> 
>> Looks like the new lucene2 node has run out of disk space.  I’ll go ask 
>> about it on Infra’s hipchat channel.
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>>> On Jul 12, 2017, at 3:11 AM, Apache Jenkins Server 
>>>  wrote:
>>> 
>>> Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1352/
>>> 
>>> 1 tests failed.
>>> FAILED:  
>>> TEST-org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs.xml.[empty]
>>> 
>>> Error Message:
>>> 
>>> 
>>> Stack Trace:
>>> Test report file 
>>> /home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/lucene/build/core/test/TEST-org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs.xml
>>>  was length 0
>>> 
>>> 
>>> 
>>> Build Log:
>>> [...truncated 262 lines...]
>>> [junit4] JVM J0: stderr was not empty, see: 
>>> /home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/lucene/build/core/test/temp/junit4-J0-20170712_070941_6163200394456052706494.syserr
>>> [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
>>> [junit4] WARN: Unhandled exception in event serialization. -> 
>>> java.security.PrivilegedActionException: java.io.IOException: No space left 
>>> on device
>>> [junit4]at java.security.AccessController.doPrivileged(Native Method)
>>> [junit4]at 
>>> com.carrotsearch.ant.tasks.junit4.events.Serializer.flushQueue(Serializer.java:114)
>>> [junit4]at 
>>> com.carrotsearch.ant.tasks.junit4.events.Serializer.serialize(Serializer.java:99)
>>> [junit4]at 
>>> com.carrotsearch.ant.tasks.junit4.slave.SlaveMain$3$2.write(SlaveMain.java:472)
>>> [junit4]at 
>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
>>> [junit4]at 
>>> java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
>>> [junit4]at java.io.PrintStream.flush(PrintStream.java:338)
>>> [junit4]at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
>>> [junit4]at java.io.PrintStream.write(PrintStream.java:482)
>>> [junit4]at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
>>> [junit4]at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282)
>>> [junit4]at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
>>> [junit4]at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:135)
>>> [junit4]at java.io.OutputStreamWriter.write(OutputStreamWriter.java:220)
>>> [junit4]at java.io.Writer.write(Writer.java:157)
>>> [junit4]at 
>>> java.util.logging.StreamHandler.publish(StreamHandler.java:224)
>>> [junit4]at 
>>> java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:116)
>>> [junit4]at java.util.logging.Logger.log(Logger.java:738)
>>> [junit4]at java.util.logging.Logger.doLog(Logger.java:765)
>>> [junit4]at java.util.logging.Logger.log(Logger.java:876)
>>> [junit4]at 
>>> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler.uncaughtException(RandomizedRunner.java:531)
>>> [junit4]at 
>>> java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1057)
>>> [junit4]at 
>>> java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1052)
>>> [junit4]at 
>>> java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1052)
>>> [junit4]at 
>>> com.carrotsearch.randomizedtesting.RunnerThreadGroup.uncaughtException(RunnerThreadGroup.java:28)
>>> [junit4]at java.lang.Thread.dispatchUncaughtException(Thread.java:1959)
>>> [junit4] Caused by: java.io.IOException: No space left on device
>>> [junit4]at java.io.FileOutputStream.writeBytes(Native Method)
>>> [junit4]at java.io.FileOut
>>> [junit4] putStream.write(FileOutputStream.java:326)
>>> [junit4]at 
>>> java.io.BufferedOutputStream.write(BufferedOutputStream.java:122)
>>> [junit4]at 
>>> com.carrotsearch.ant.tasks.junit4.slave.EventsOutputStream.write(EventsOutputStream.java:28)
>>> [junit4]at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
>>> [junit4]at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282)
>>> [junit4]at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
>>> [junit4]at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:135)
>>> [junit4]at java.io.OutputStreamWriter.write(OutputStreamWriter.java:220)
>>> [junit4]at 
>>> 

[jira] [Updated] (SOLR-11059) Randomize PointFields in schema-blockjoinfacetcomponent.xml and all related tests

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-11059:

Fix Version/s: 7.1
   master (8.0)

> Randomize PointFields in schema-blockjoinfacetcomponent.xml and all related 
> tests
> -
>
> Key: SOLR-11059
> URL: https://issues.apache.org/jira/browse/SOLR-11059
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0, master (8.0), 7.1
>
>




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

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

[JENKINS] Solr-reference-guide-7.0 - Build # 57 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-7.0/57/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H20 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-7.0
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_7_0^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_7_0^{commit} # timeout=10
Checking out Revision da1afd596bc83235918d19ff5fdbe5267c76f457 
(refs/remotes/origin/branch_7_0)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f da1afd596bc83235918d19ff5fdbe5267c76f457
 > git rev-list fb23b630f3db73989430c6025fa13d160dc3daaa # timeout=10
No emails were triggered.
[Solr-reference-guide-7.0] $ /bin/bash -xe /tmp/hudson7283452217198627310.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s -- --path /home/jenkins/shared/.rvm
Downloading https://github.com/rvm/rvm/archive/master.tar.gz

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

+ mkdir -p /home/jenkins/shared/.rvm/gems/gems
+ gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll 
jekyll-asciidoc pygments.rb
ERROR:  Error installing jekyll:
"listen" from sass-listen conflicts with installed executable from 
listen
ERROR:  Error installing jekyll-asciidoc:
"listen" from sass-listen conflicts with installed executable from 
listen
Successfully installed pygments.rb-1.1.2
1 gem installed
Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Commented] (SOLR-11059) Randomize PointFields in schema-blockjoinfacetcomponent.xml and all related tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11059:


Commit da1afd596bc83235918d19ff5fdbe5267c76f457 in lucene-solr's branch 
refs/heads/branch_7_0 from [~anshumg]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=da1afd5 ]

SOLR-11059: Randomize PointFields in schema-blockjoinfacetcomponent.xml and all 
related tests


> Randomize PointFields in schema-blockjoinfacetcomponent.xml and all related 
> tests
> -
>
> Key: SOLR-11059
> URL: https://issues.apache.org/jira/browse/SOLR-11059
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0
>
>




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

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

[jira] [Resolved] (SOLR-11059) Randomize PointFields in schema-blockjoinfacetcomponent.xml and all related tests

[Anshum Gupta (JIRA)]

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

Anshum Gupta resolved SOLR-11059.
-
Resolution: Fixed

> Randomize PointFields in schema-blockjoinfacetcomponent.xml and all related 
> tests
> -
>
> Key: SOLR-11059
> URL: https://issues.apache.org/jira/browse/SOLR-11059
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0, master (8.0), 7.1
>
>




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

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

[jira] [Created] (SOLR-11059) Randomize PointFields in schema-blockjoinfacetcomponent.xml and all related tests

[Anshum Gupta (JIRA)]

Anshum Gupta created SOLR-11059:
---

 Summary: Randomize PointFields in 
schema-blockjoinfacetcomponent.xml and all related tests
 Key: SOLR-11059
 URL: https://issues.apache.org/jira/browse/SOLR-11059
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Anshum Gupta
Assignee: Anshum Gupta






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

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

[jira] [Commented] (SOLR-11059) Randomize PointFields in schema-blockjoinfacetcomponent.xml and all related tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11059:


Commit 52ebad5827c2423ae1856ba58333ebc47f160ed9 in lucene-solr's branch 
refs/heads/branch_7x from [~anshumg]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=52ebad5 ]

SOLR-11059: Randomize PointFields in schema-blockjoinfacetcomponent.xml and all 
related tests


> Randomize PointFields in schema-blockjoinfacetcomponent.xml and all related 
> tests
> -
>
> Key: SOLR-11059
> URL: https://issues.apache.org/jira/browse/SOLR-11059
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0
>
>




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

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

[jira] [Commented] (SOLR-11059) Randomize PointFields in schema-blockjoinfacetcomponent.xml and all related tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11059:


Commit 7b5c50c3c8cf904263e81def84783a4988548930 in lucene-solr's branch 
refs/heads/master from [~anshumg]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7b5c50c ]

SOLR-11059: Randomize PointFields in schema-blockjoinfacetcomponent.xml and all 
related tests


> Randomize PointFields in schema-blockjoinfacetcomponent.xml and all related 
> tests
> -
>
> Key: SOLR-11059
> URL: https://issues.apache.org/jira/browse/SOLR-11059
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0
>
>




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

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

[jira] [Updated] (SOLR-11057) RangeQuery can overflow in PointFields when quering the type limits

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-11057:
-
Attachment: SOLR-11057.patch

Here us a patch that creates a MatchNoDocsQuery in those cases, similar to what 
we do in the DV range query case. This is not an issue with Float/Double, but 
it probably is with Dates. Will add a test for that too

> RangeQuery can overflow in PointFields when quering the type limits
> ---
>
> Key: SOLR-11057
> URL: https://issues.apache.org/jira/browse/SOLR-11057
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-11057.patch
>
>
> This can happen when the upper limit of the range is the lowest value of the 
> type or when the lower limit is the max value of the type. For example:
> {{q=field_i:{Integer.MAX_VALUE TO Integer.MAX_VALUE]}}. Note that this should 
> not return any docs



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

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

[jira] [Created] (SOLR-11058) Investigate TestTlogReplica.testOnlyLeaderIndexes failure on Windows

[JIRA]

Tomás Fernández Löbbe created SOLR-11058:


 Summary: Investigate TestTlogReplica.testOnlyLeaderIndexes failure 
on Windows
 Key: SOLR-11058
 URL: https://issues.apache.org/jira/browse/SOLR-11058
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Tests
Reporter: Tomás Fernández Löbbe


{noformat}
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Windows/5/
Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([39520FC56F2F6595:255372481A8A1B06]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at org.junit.Assert.assertFalse(Assert.java:79)
at 
org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes(TestTlogReplica.java:497)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Updated] (SOLR-11058) Investigate TestTlogReplica.testOnlyLeaderIndexes failure on Windows

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-11058:
-
Attachment: 5.txt

Attached full log

> Investigate TestTlogReplica.testOnlyLeaderIndexes failure on Windows
> 
>
> Key: SOLR-11058
> URL: https://issues.apache.org/jira/browse/SOLR-11058
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
> Attachments: 5.txt
>
>
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Windows/5/
> Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseSerialGC
> 1 tests failed.
> FAILED:  org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes
> Error Message:
> Stack Trace:
> java.lang.AssertionError
> at 
> __randomizedtesting.SeedInfo.seed([39520FC56F2F6595:255372481A8A1B06]:0)
> at org.junit.Assert.fail(Assert.java:92)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertFalse(Assert.java:68)
> at org.junit.Assert.assertFalse(Assert.java:79)
> at 
> org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes(TestTlogReplica.java:497)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> 

[jira] [Updated] (SOLR-11055) Add 'commitWithin' testing (of both soft/hard commits) to SoftAutoCommitTest

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-11055:

Attachment: SOLR-11055.patch

here's a patch i'm currently testing seems to be working fine.

NOTE: this does make SoftAutoCommitTest take longer (because it's essentially 
testing 3x as much stuff).  An alternative approach would be to refactor the 
test methods into the base class, and let subclasses just declare a (static) 
CommitWithinType instance.  That approach would also let us avoid the changes 
to DUH2: each test could just set the sysprop statically before initCore.

> Add 'commitWithin' testing (of both soft/hard commits) to SoftAutoCommitTest 
> -
>
> Key: SOLR-11055
> URL: https://issues.apache.org/jira/browse/SOLR-11055
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-11055.patch
>
>
> SoftAutoCommitTest should be enhanced with it's monitor based polling to also 
> check that commitWithin works just as well as autocommit maxTime for either 
> softCommit or hardCommit (can't test both at the same time due to how 
> commitWithin is configured)



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

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

[jira] [Resolved] (SOLR-11048) Randomize PointFields in schema-add-schema-fields-update-processor.xml in core/src/test-files/solr/collection1

[Anshum Gupta (JIRA)]

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

Anshum Gupta resolved SOLR-11048.
-
   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)

> Randomize PointFields in schema-add-schema-fields-update-processor.xml in 
> core/src/test-files/solr/collection1
> --
>
> Key: SOLR-11048
> URL: https://issues.apache.org/jira/browse/SOLR-11048
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0, master (8.0), 7.1
>
>




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

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

[jira] [Updated] (SOLR-11056) Add random range query test for PointFields

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-11056:
-
Attachment: SOLR-11056.patch

[~steve_rowe] Is also working on improving the tests, so this patch may not be 
committed (in addition to needing more work), but it exposes some issues with 
Float/Double.INFINITY in DV range queries, and with some edge cases in point 
range queries.

> Add random range query test for PointFields
> ---
>
> Key: SOLR-11056
> URL: https://issues.apache.org/jira/browse/SOLR-11056
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-11056.patch
>
>
> While working on SOLR-11043 I had some issues with range queries. I'm working 
> on adding a random test for range queries in points



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

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

[jira] [Commented] (SOLR-11048) Randomize PointFields in schema-add-schema-fields-update-processor.xml in core/src/test-files/solr/collection1

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11048:


Commit fb23b630f3db73989430c6025fa13d160dc3daaa in lucene-solr's branch 
refs/heads/branch_7_0 from [~anshumg]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fb23b63 ]

SOLR-11048: Randomize PointsFields in 
schema-add-schema-fields-update-processor.xml in solr-core collection1 and all 
affected tests


> Randomize PointFields in schema-add-schema-fields-update-processor.xml in 
> core/src/test-files/solr/collection1
> --
>
> Key: SOLR-11048
> URL: https://issues.apache.org/jira/browse/SOLR-11048
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0
>
>




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

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

[jira] [Commented] (SOLR-11048) Randomize PointFields in schema-add-schema-fields-update-processor.xml in core/src/test-files/solr/collection1

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11048:


Commit 31ca5baf3ad8837d7796bc6d77e3b9baa94cf3b3 in lucene-solr's branch 
refs/heads/branch_7x from [~anshumg]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=31ca5ba ]

SOLR-11048: Randomize PointsFields in 
schema-add-schema-fields-update-processor.xml in solr-core collection1 and all 
affected tests


> Randomize PointFields in schema-add-schema-fields-update-processor.xml in 
> core/src/test-files/solr/collection1
> --
>
> Key: SOLR-11048
> URL: https://issues.apache.org/jira/browse/SOLR-11048
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0
>
>




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

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

[jira] [Created] (SOLR-11057) RangeQuery can overflow in PointFields when quering the type limits

[JIRA]

Tomás Fernández Löbbe created SOLR-11057:


 Summary: RangeQuery can overflow in PointFields when quering the 
type limits
 Key: SOLR-11057
 URL: https://issues.apache.org/jira/browse/SOLR-11057
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tomás Fernández Löbbe
Assignee: Tomás Fernández Löbbe


This can happen when the upper limit of the range is the lowest value of the 
type or when the lower limit is the max value of the type. For example:
{{q=field_i:{Integer.MAX_VALUE TO Integer.MAX_VALUE]}}. Note that this should 
not return any docs



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

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

[jira] [Commented] (SOLR-11048) Randomize PointFields in schema-add-schema-fields-update-processor.xml in core/src/test-files/solr/collection1

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11048:


Commit 8d7e3cc9294a1cdb5323ac1d068de3ec387ee0fb in lucene-solr's branch 
refs/heads/master from [~anshumg]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8d7e3cc ]

SOLR-11048: Randomize PointsFields in 
schema-add-schema-fields-update-processor.xml in solr-core collection1 and all 
affected tests


> Randomize PointFields in schema-add-schema-fields-update-processor.xml in 
> core/src/test-files/solr/collection1
> --
>
> Key: SOLR-11048
> URL: https://issues.apache.org/jira/browse/SOLR-11048
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0
>
>




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

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

[jira] [Created] (SOLR-11056) Add random range query test for PointFields

[JIRA]

Tomás Fernández Löbbe created SOLR-11056:


 Summary: Add random range query test for PointFields
 Key: SOLR-11056
 URL: https://issues.apache.org/jira/browse/SOLR-11056
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Tests
Reporter: Tomás Fernández Löbbe
Assignee: Tomás Fernández Löbbe


While working on SOLR-11043 I had some issues with range queries. I'm working 
on adding a random test for range queries in points



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/7/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseParallelGC

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

Error Message:
Exception during query

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

00


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




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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Windows/5/
Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([39520FC56F2F6595:255372481A8A1B06]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at org.junit.Assert.assertFalse(Assert.java:79)
at 
org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes(TestTlogReplica.java:497)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 10906 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestTlogReplica
   [junit4]   2> Creating dataDir: 

[jira] [Updated] (LUCENE-7905) Optimizations for OrdinalMap

[Michael McCandless (JIRA)]

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

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

New patch, folding in Adrien's suggestion to fully decouple {{MultiTermsEnum}} 
and {{OrdinalMap}}, and adding a couple new TODOs.  I think it's ready.

> Optimizations for OrdinalMap
> 
>
> Key: LUCENE-7905
> URL: https://issues.apache.org/jira/browse/LUCENE-7905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 7.1
>
> Attachments: LUCENE-7905.patch, LUCENE-7905.patch, 
> LUCENE-7905-specialized.patch
>
>
> {{OrdinalMap}} is a useful class to quickly map per-segment ordinals to 
> global space, but it's fairly costly to build, which must typically be done 
> on every NRT refresh.
> I'm using it quite heavily in two different places, one for 
> {{SortedSetDocValuesFacetCounts}}, and another custom usage, and I found some 
> small optimizations to improve its construction time.
> I switched it to use a simple priority queue to merge the terms instead of 
> the more general {{MultiTermsEnum}}, which does extra work since it must also 
> provide postings, implement seekExact, etc.
> I also pulled {{OrdinalMap}} out into its own oal.index class.
> When testing construction time for my case the patch is ~16% faster (159.9s 
> -> 134.2s) in one case with 91.4 M terms and ~9% faster (115.6s -> 105.7s) in 
> another case with 26.6 M terms.



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

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

[jira] [Commented] (SOLR-7232) DIH should extract multiple values for metadata fields extracted by Tika

[Tim Allison (JIRA)]

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

Tim Allison commented on SOLR-7232:
---

Wanted to ping on this while I came across it.  I'll try to put together a PR 
shortly.

> DIH should extract multiple values for metadata fields extracted by Tika
> 
>
> Key: SOLR-7232
> URL: https://issues.apache.org/jira/browse/SOLR-7232
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Priority: Trivial
>
> The TikaEntityProcessor is currently pulling only the first value for a given 
> metadata key.  If there are multiple values for a given metadata key as 
> extracted by Tika, those values are currently being ignored.



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

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

[jira] [Comment Edited] (SOLR-2416) Solr Cell fails to index Zip file contents

[Tim Allison (JIRA)]

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

Tim Allison edited comment on SOLR-2416 at 7/12/17 8:20 PM:


For more fun with embedded docs, see the issue on adding the 
RecursiveParserWrapper's behavior to Solr -- SOLR-7229 .  This would create a 
separate Solr document for each document embedded in the zip (perhaps child 
documents?).


was (Author: talli...@mitre.org):
For more fun with embedded docs, see the issue on adding the 
RecursiveParserWrapper's behavior to Solr -- SOLR-7229

> Solr Cell fails to index Zip file contents
> --
>
> Key: SOLR-2416
> URL: https://issues.apache.org/jira/browse/SOLR-2416
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler, contrib - Solr Cell (Tika 
> extraction)
>Affects Versions: 1.4.1
>Reporter: Jayendra Patil
> Fix For: 6.0
>
> Attachments: SOLR-2416_ExtractingDocumentLoader.patch, SOLR-4216.patch
>
>
> Working with the latest Solr Trunk code and seems the Tika handlers for Solr 
> Cell (ExtractingDocumentLoader.java) and Data Import handler 
> (TikaEntityProcessor.java) fails to index the zip file contents again.
> It just indexes the file names again.
> This issue was addressed some time back, late last year, but seems to have 
> reappeared with the latest code.
> Jira for the Data Import handler part with the patch and the testcase - 
> https://issues.apache.org/jira/browse/SOLR-2332.



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

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

[jira] [Updated] (SOLR-11000) Changes made via AutoScalingHandler should be atomic

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-11000:
-
Attachment: SOLR-11000.patch

Updated patch:
* moved {{getAutoScalingConfig()}} from {{ZkController}} to {{ZkStateReader}}, 
and add a version where you can set a Watcher.
* convert a few other uses of JSON maps so that they use AutoScalingConfig.

> Changes made via AutoScalingHandler should be atomic
> 
>
> Key: SOLR-11000
> URL: https://issues.apache.org/jira/browse/SOLR-11000
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
>  Labels: autoscaling
> Fix For: 7.0
>
> Attachments: SOLR-11000.patch, SOLR-11000.patch
>
>
> Currently, AutoScalingHandler writes the result of each command to ZK 
> individually. So if you send 3 commands in a payload, it will write them 
> individually. We really should make it atomic so that the result of all the 
> commands are persisted together or none at all.



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

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

[jira] [Updated] (SOLR-10335) Upgrade to Tika 1.16 when available

[Tim Allison (JIRA)]

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

Tim Allison updated SOLR-10335:
---
Summary: Upgrade to Tika 1.16 when available  (was: Upgrade to Tika 1.15 
when available)

> Upgrade to Tika 1.16 when available
> ---
>
> Key: SOLR-10335
> URL: https://issues.apache.org/jira/browse/SOLR-10335
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tim Allison
>Priority: Minor
>
> Once POI 3.16-beta3 is out (early/mid April?), we'll push for a release of 
> Tika 1.15.
> Please let us know if you have any requests.



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

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

[jira] [Commented] (SOLR-10335) Upgrade to Tika 1.15 when available

[Tim Allison (JIRA)]

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

Tim Allison commented on SOLR-10335:


We wound up getting more into 1.15 than we had initially planned, so the next 
version is 1.16, not 1.15.1.  We just released that today.  Should I update my 
PR on 1.14 (SOLR-9552) or should I close that and start from scratch?

> Upgrade to Tika 1.15 when available
> ---
>
> Key: SOLR-10335
> URL: https://issues.apache.org/jira/browse/SOLR-10335
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tim Allison
>Priority: Minor
>
> Once POI 3.16-beta3 is out (early/mid April?), we'll push for a release of 
> Tika 1.15.
> Please let us know if you have any requests.



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

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

[jira] [Commented] (SOLR-2416) Solr Cell fails to index Zip file contents

[Tim Allison (JIRA)]

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

Tim Allison commented on SOLR-2416:
---

For more fun with embedded docs, see the issue on adding the 
RecursiveParserWrapper's behavior to Solr -- SOLR-7229

> Solr Cell fails to index Zip file contents
> --
>
> Key: SOLR-2416
> URL: https://issues.apache.org/jira/browse/SOLR-2416
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler, contrib - Solr Cell (Tika 
> extraction)
>Affects Versions: 1.4.1
>Reporter: Jayendra Patil
> Fix For: 6.0
>
> Attachments: SOLR-2416_ExtractingDocumentLoader.patch, SOLR-4216.patch
>
>
> Working with the latest Solr Trunk code and seems the Tika handlers for Solr 
> Cell (ExtractingDocumentLoader.java) and Data Import handler 
> (TikaEntityProcessor.java) fails to index the zip file contents again.
> It just indexes the file names again.
> This issue was addressed some time back, late last year, but seems to have 
> reappeared with the latest code.
> Jira for the Data Import handler part with the patch and the testcase - 
> https://issues.apache.org/jira/browse/SOLR-2332.



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

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

[jira] [Commented] (SOLR-6889) Highlight using multiple threads

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-6889:


I do think there would be a benefit for some cases, yes.  ANALYSIS offset 
source most likely, perhaps also with lots of fields to highlight to add to the 
workload.

> Highlight using multiple threads
> 
>
> Key: SOLR-6889
> URL: https://issues.apache.org/jira/browse/SOLR-6889
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Shinichiro Abe
> Attachments: SOLR-6889.patch
>
>
> I think we could gain search performance a little bit using 
> Stream.parallel().forEach()~ which has processors awareness via f/j framework 
> under the hood.
> Especially it would affect docList's for-loop processes, e.g. debugging, 
> highlighting.
> It seems to me that this improvement is effective for many CPUs environment.
> My test condition:
> 1. Core i5(2core 4thead), standalone Solr.
> 2. q=日本=true=true, other parameters are 
> [here|https://github.com/anond2/simplesearch/blob/master/conf/solrconfig.xml#L836].
> 3. 7171 hits / 12000 docs(taken from ja.wikipedia dump)
> 4. compared to trunk, parallel streams are faster a little.
> My query execution results(QTime):
> {noformat}
> == rows=10 ==
> trunk  patch 
> 1st 236146
> 2nd 179100
> 3rd 79 72
> 4th 75 53
> 5th 91 80
> == rows=50 ==
> trunk  patch 
> 1st 485325
> 2nd 225243
> 3rd 199151
> 4th 168127
> 5th 149118
> == rows=100 ==
> trunk  patch 
> 1st 948607
> 2nd 472390
> 3rd 237201
> 4th 256200
> 5th 224178
> == rows=500 ==
> trunk  patch 
> 1st 3248   2826
> 2nd 1545   1067
> 3rd 1563   801
> 4th 1551   816
> 5th 1452   777
> {noformat}



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

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

[jira] [Commented] (SOLR-2416) Solr Cell fails to index Zip file contents

[Tim Allison (JIRA)]

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

Tim Allison commented on SOLR-2416:
---

This should have been fixed by SOLR-7189, no?  Or am I confusing DIH and Solr 
Cell?

In Tika 1.15 (TIKA-2096), we changed the default behavior to add an embedded 
parser if a user fails to pass one in via the parse context.  So, if we upgrade 
to Tika 1.16 (just out), this will be fixed, too.  We'll probably want to let 
Solr users configure turning off embedded document handling...

> Solr Cell fails to index Zip file contents
> --
>
> Key: SOLR-2416
> URL: https://issues.apache.org/jira/browse/SOLR-2416
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler, contrib - Solr Cell (Tika 
> extraction)
>Affects Versions: 1.4.1
>Reporter: Jayendra Patil
> Fix For: 6.0
>
> Attachments: SOLR-2416_ExtractingDocumentLoader.patch, SOLR-4216.patch
>
>
> Working with the latest Solr Trunk code and seems the Tika handlers for Solr 
> Cell (ExtractingDocumentLoader.java) and Data Import handler 
> (TikaEntityProcessor.java) fails to index the zip file contents again.
> It just indexes the file names again.
> This issue was addressed some time back, late last year, but seems to have 
> reappeared with the latest code.
> Jira for the Data Import handler part with the patch and the testcase - 
> https://issues.apache.org/jira/browse/SOLR-2332.



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

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (32bit/jdk-9-ea+175) - Build # 64 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/64/
Java: 32bit/jdk-9-ea+175 -server -XX:+UseParallelGC --illegal-access=deny

2 tests failed.
FAILED:  
org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest

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

Stack Trace:
java.lang.AssertionError: expected:<4> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([844DB3E5804411D6:F0BD52A0C4605659]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest(TestCloudRecovery.java:102)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.update.AutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:

[jira] [Commented] (LUCENE-7848) QueryBuilder.analyzeGraphPhrase does not handle gaps correctly

[Tim Allison (JIRA)]

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

Tim Allison commented on LUCENE-7848:
-

bq. Could be a bug somewhere in span queries.

Related to LUCENE-7398?

> QueryBuilder.analyzeGraphPhrase does not handle gaps correctly
> --
>
> Key: LUCENE-7848
> URL: https://issues.apache.org/jira/browse/LUCENE-7848
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.5, 6.6
>Reporter: Jim Ferenczi
> Attachments: capture-3.png, LUCENE-7848-branching-spanOr.patch, 
> LUCENE-7848.patch, LUCENE-7848.patch
>
>
> Position increments greater than 1 are ignored when the query builder creates 
> a graph phrase query. 
> Instead it should use SpanNearQuery.addGap for pos incr > 1.



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

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

[jira] [Updated] (LUCENE-7905) Optimizations for OrdinalMap

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-7905:
---
Attachment: LUCENE-7905-specialized.patch

I tried specializing the PQ (patch attached) but it was only a small 
improvement so I don't plan to pursue it any more.  It could be I should have 
also specialized the logic to look for all subs sharing the same term?  But I 
ran out of time I have to play with this so much ;)

I also ran YourKit and found some silly slow code in 
{{DefaultSortedSetDocValuesReaderState}}, where it does a linear scan of all 
ord -> BytesRef to find the ord range of each dimension; we could do this much 
more efficiently with binary searching instead.  I'll put a TODO but don't plan 
to tackle that now/here.  That was 12% of the time.

Other hot areas were calling {{next()}} on the doc values (~25%) and 
{{updateTop}} in the tem queue (~46%).

I do feel like how we compare terms in the PQ is inefficient, and we should be 
able to do something like what radix sort does, because at any given time, the 
terms in the queue likely share long common prefixes yet we keep inefficiently 
re-comparing those long common prefixes.  It seems like there should be a 
powerful optimization here, where if we could somehow efficiently know that 
e.g. right now all terms have a common prefix of length=5, and then only do our 
comparisons starting from the 6th digit, or something ... but I don't see how 
to do it.


> Optimizations for OrdinalMap
> 
>
> Key: LUCENE-7905
> URL: https://issues.apache.org/jira/browse/LUCENE-7905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 7.1
>
> Attachments: LUCENE-7905.patch, LUCENE-7905-specialized.patch
>
>
> {{OrdinalMap}} is a useful class to quickly map per-segment ordinals to 
> global space, but it's fairly costly to build, which must typically be done 
> on every NRT refresh.
> I'm using it quite heavily in two different places, one for 
> {{SortedSetDocValuesFacetCounts}}, and another custom usage, and I found some 
> small optimizations to improve its construction time.
> I switched it to use a simple priority queue to merge the terms instead of 
> the more general {{MultiTermsEnum}}, which does extra work since it must also 
> provide postings, implement seekExact, etc.
> I also pulled {{OrdinalMap}} out into its own oal.index class.
> When testing construction time for my case the patch is ~16% faster (159.9s 
> -> 134.2s) in one case with 91.4 M terms and ~9% faster (115.6s -> 105.7s) in 
> another case with 26.6 M terms.



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

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

[jira] [Created] (SOLR-11053) Improve SoftAutoCommitTest to the point that we can delete AutoCommitTest and HardAutoCommitTest

[Hoss Man (JIRA)]

Hoss Man created SOLR-11053:
---

 Summary: Improve SoftAutoCommitTest to the point that we can 
delete AutoCommitTest and HardAutoCommitTest
 Key: SOLR-11053
 URL: https://issues.apache.org/jira/browse/SOLR-11053
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man



This jira serves as a parent with the objective of being able to delete 
AutoCommitTest and HardAutoCommitTest -- w/o any loss in what core 
functionality is being tested -- by adding equivilent test logic to 
SoftAutoCommitTest using the (superior) strategies currently found in 
SoftAutoCommitTest.

Sub-Tasks will be used to track the discrete changes to be made, so we can 
phase them in gradually.




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

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

[jira] [Commented] (SOLR-11055) Add 'commitWithin' testing (of both soft/hard commits) to SoftAutoCommitTest

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-11055:
-

I have not tried this yet, but here's a rough outline/psuedo-code of what i 
think would make sense for this...

* add some {{enum CommitWithinType ( HARD, SOFT, NONE )}}
* refactor all existing {{\*MaxTime\*}} based tests, so the meat of the tests 
are parameterized by {{CommitWithinType}}, ala...{code}
public void testSoftAndHardCommitMaxTimeMixedAdds() throws Exception {
   doTestSoftAndHardCommitMaxTimeMixedAdds(NONE);
}
public void testSoftCommitWithinAndHardCommitMaxTimeMixedAdds() throws 
Exception {
   doTestSoftAndHardCommitMaxTimeMixedAdds(SOFT);
}
public void testHardCommitWithinAndSoftCommitMaxTimeMixedAdds() throws 
Exception {
   doTestSoftAndHardCommitMaxTimeMixedAdds(HARD);
}
private void doTestSoftAndHardCommitMaxTimeMixedAdds(final CommitWithinType 
commitWithinType) throws Exception {
  ...
}
{code}
* in the "meat" of these refactored methods...
** Do "something" to set the DUH2.commitWithinSoftCommit value
*** this might require refactoring the test to do initCore inside each method 
after setting the sysprop
*** Or we add a new test only method to DUH2 to change this on the fly?
** change the tracker setup to only set tthe autoCommit times when they don't 
match the commitWithinType...{code}
softTracker.setTimeUpperBound(commitWithinType.equals(SOFT) ? -1 : 
softCommitWaitMillis);
softTracker.setDocsUpperBound(-1);
hardTracker.setTimeUpperBound(commitWithinType.equals(HARD) ? -1 : 
hardCommitWaitMillis);
hardTracker.setDocsUpperBound(-1);
{code}
** init a new {{commitWithin}} var in the test via some helper method on the 
enum... {code}
// NONE returns -1
// HARD returns hardCommitWaitMillis
// SOFT returns softCommitWaitMillis
final long commitWithin = commitWithinType.useValue(softCommitWaitMillis, 
hardCommitWaitMillis);
{code}
** update all {{adoc(...)}} calls in the test to use the alternative version 
that takes in {{commitWithin}}
* the existing polling and assertions based on {{hardCommitWaitMillis}} and 
{{softCommitWaitMillis}} in all of these test methods should continue to work 
as expected -- regardless of wether the commits are being triggered by the 
autoCommit timmer or the commitWithin timers


> Add 'commitWithin' testing (of both soft/hard commits) to SoftAutoCommitTest 
> -
>
> Key: SOLR-11055
> URL: https://issues.apache.org/jira/browse/SOLR-11055
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> SoftAutoCommitTest should be enhanced with it's monitor based polling to also 
> check that commitWithin works just as well as autocommit maxTime for either 
> softCommit or hardCommit (can't test both at the same time due to how 
> commitWithin is configured)



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

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

[jira] [Commented] (SOLR-11053) Improve SoftAutoCommitTest to the point that we can delete AutoCommitTest and HardAutoCommitTest

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-11053:
-


When Miller first wrote SoftAutoCommitTest back in 2011, it was with the 
expressly started purpose to "Test auto commit functionality in a way that 
doesn't suck."

As the javadocs put it...

{code}
/**
 * Test auto commit functionality in a way that doesn't suck.
 * 
 * AutoCommitTest is an abomination that is way to brittle in how it 
 * tries to check that commits happened, and when they happened.
 * The goal of this test class is to (ultimately) completely replace all 
 * of the functionality of that test class using:
 * 
 * 
 *   A more robust monitor of commit/newSearcher events that records 
 *   the times of those events in a queue that can be polled.  
 *   Multiple events in rapid succession are not lost.
 *   
 *   Timing checks that are forgiving of slow machines and use 
 *   knowledge of how slow A-B was to affect the expectation of 
 *   how slow B-C will be
 *   
 * 
 */
{code}

The jenkins failure emails (especially fromthe past few months) back up the 
implication that the strategy used in SoftAutoCommitTest is much hardier (even 
on flaky machines) then the approaches taken in AutoCommitTest and 
HardAutoCommitTest.



AFAICT there are esentially only 3 things these "bad" tests currently check 
that aren't already covered by the existing logic in SoftAutoCommitTest:

* maxDocs
** AutoCommitTest.testMaxDocs() currently checks the "softCommit" aspect (via 
newSearcher)
** nothing currently seems to test the "hardCommit" side
* commitWithin
** AutoCommitTest.testCommitWithin() currently checks the "softCommit" aspect 
(via newSearcher)
** HardAutoCommitTest.testCommitWithin() currently checks the "hardCommit" 
aspect (but also via newSearcher)

...I'll put my thoughts on these in individual sub-tasks



> Improve SoftAutoCommitTest to the point that we can delete AutoCommitTest and 
> HardAutoCommitTest
> 
>
> Key: SOLR-11053
> URL: https://issues.apache.org/jira/browse/SOLR-11053
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> This jira serves as a parent with the objective of being able to delete 
> AutoCommitTest and HardAutoCommitTest -- w/o any loss in what core 
> functionality is being tested -- by adding equivilent test logic to 
> SoftAutoCommitTest using the (superior) strategies currently found in 
> SoftAutoCommitTest.
> Sub-Tasks will be used to track the discrete changes to be made, so we can 
> phase them in gradually.



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

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

[jira] [Created] (SOLR-11055) Add 'commitWithin' testing (of both soft/hard commits) to SoftAutoCommitTest

[Hoss Man (JIRA)]

Hoss Man created SOLR-11055:
---

 Summary: Add 'commitWithin' testing (of both soft/hard commits) to 
SoftAutoCommitTest 
 Key: SOLR-11055
 URL: https://issues.apache.org/jira/browse/SOLR-11055
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


SoftAutoCommitTest should be enhanced with it's monitor based polling to also 
check that commitWithin works just as well as autocommit maxTime for either 
softCommit or hardCommit (can't test both at the same time due to how 
commitWithin is configured)



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

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

[jira] [Updated] (SOLR-11054) Add SoftAutoCommitTest.testSoftAndHardCommitMaxDocs

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-11054:

Attachment: SOLR-11054.patch

Here's a patch that i think would work well for this.

it covers that basics of asserting via the monitor that the each type of commit 
is fired no sooner then expected, and that no extra commits are fired, and 
doesn't get bogged down in any assumptions about the searcher

> Add SoftAutoCommitTest.testSoftAndHardCommitMaxDocs
> ---
>
> Key: SOLR-11054
> URL: https://issues.apache.org/jira/browse/SOLR-11054
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-11054.patch
>
>
> SoftAutoCommitTest should have a testSoftAndHardCommitMaxDocs that checks the 
> maxDocs option for autocommit using the same monitor polling used by other 
> existing SoftAutoCommitTest tests.



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

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

[jira] [Created] (SOLR-11054) Add SoftAutoCommitTest.testSoftAndHardCommitMaxDocs

[Hoss Man (JIRA)]

Hoss Man created SOLR-11054:
---

 Summary: Add SoftAutoCommitTest.testSoftAndHardCommitMaxDocs
 Key: SOLR-11054
 URL: https://issues.apache.org/jira/browse/SOLR-11054
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man



SoftAutoCommitTest should have a testSoftAndHardCommitMaxDocs that checks the 
maxDocs option for autocommit using the same monitor polling used by other 
existing SoftAutoCommitTest tests.




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

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

[jira] [Commented] (SOLR-6889) Highlight using multiple threads

[Shinichiro Abe (JIRA)]

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

Shinichiro Abe commented on SOLR-6889:
--

I agree. But could it make much faster by being parallelized when using 
FieldOffsetStrategy#getOffsetsEnums(), especially OffsetSource.ANALYSIS 
strategy case, i.e. storeOffsetsWithPositions = false case in which user can 
select fields to highlight after indexing? I assumed text analysis work, which 
the standard highlighter has, would be able to be parallelized, borrowed by an 
idea of facet.threads method at that time. Although I saw a benchmark where 
UH's offsetSource=ANALYSIS is already much faster than the standard one.

> Highlight using multiple threads
> 
>
> Key: SOLR-6889
> URL: https://issues.apache.org/jira/browse/SOLR-6889
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Shinichiro Abe
> Attachments: SOLR-6889.patch
>
>
> I think we could gain search performance a little bit using 
> Stream.parallel().forEach()~ which has processors awareness via f/j framework 
> under the hood.
> Especially it would affect docList's for-loop processes, e.g. debugging, 
> highlighting.
> It seems to me that this improvement is effective for many CPUs environment.
> My test condition:
> 1. Core i5(2core 4thead), standalone Solr.
> 2. q=日本=true=true, other parameters are 
> [here|https://github.com/anond2/simplesearch/blob/master/conf/solrconfig.xml#L836].
> 3. 7171 hits / 12000 docs(taken from ja.wikipedia dump)
> 4. compared to trunk, parallel streams are faster a little.
> My query execution results(QTime):
> {noformat}
> == rows=10 ==
> trunk  patch 
> 1st 236146
> 2nd 179100
> 3rd 79 72
> 4th 75 53
> 5th 91 80
> == rows=50 ==
> trunk  patch 
> 1st 485325
> 2nd 225243
> 3rd 199151
> 4th 168127
> 5th 149118
> == rows=100 ==
> trunk  patch 
> 1st 948607
> 2nd 472390
> 3rd 237201
> 4th 256200
> 5th 224178
> == rows=500 ==
> trunk  patch 
> 1st 3248   2826
> 2nd 1545   1067
> 3rd 1563   801
> 4th 1551   816
> 5th 1452   777
> {noformat}



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

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

[JENKINS-EA] Lucene-Solr-7.x-Windows (32bit/jdk-9-ea+173) - Build # 34 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/34/
Java: 32bit/jdk-9-ea+173 -server -XX:+UseG1GC

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

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_B808C34BD07D5692-001\init-core-data-001:
 java.nio.file.NoSuchFileException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_B808C34BD07D5692-001\init-core-data-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_B808C34BD07D5692-001\init-core-data-001:
 java.nio.file.NoSuchFileException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_B808C34BD07D5692-001\init-core-data-001

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




Build Log:
[...truncated 12499 lines...]
   [junit4] Suite: org.apache.solr.EchoParamsTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_B808C34BD07D5692-001\init-core-data-001
   [junit4]   2> 2158191 WARN  
(SUITE-EchoParamsTest-seed#[B808C34BD07D5692]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=1 numCloses=1
   [junit4]   2> 2158191 INFO  
(SUITE-EchoParamsTest-seed#[B808C34BD07D5692]-worker) [] 
o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 2158194 INFO  
(SUITE-EchoParamsTest-seed#[B808C34BD07D5692]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason="", value=0.0/0.0, ssl=0.0/0.0, 
clientAuth=0.0/0.0)
   [junit4]   2> 2158195 INFO  
(SUITE-EchoParamsTest-seed#[B808C34BD07D5692]-worker) [] 
o.a.s.SolrTestCaseJ4 initCore
   [junit4]   2> 2158196 INFO  
(SUITE-EchoParamsTest-seed#[B808C34BD07D5692]-worker) [] 
o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths: 
[/C:/Users/jenkins/workspace/Lucene-Solr-7.x-Windows/solr/core/src/test-files/solr/collection1/lib,
 
/C:/Users/jenkins/workspace/Lucene-Solr-7.x-Windows/solr/core/src/test-files/solr/collection1/lib/classes]
   [junit4]   2> 2158225 INFO  
(SUITE-EchoParamsTest-seed#[B808C34BD07D5692]-worker) [] o.a.s.c.SolrConfig 
Using Lucene MatchVersion: 7.1.0
   [junit4]   2> 2158234 INFO  
(SUITE-EchoParamsTest-seed#[B808C34BD07D5692]-worker) [] 
o.a.s.s.IndexSchema [null] Schema name=test
   [junit4]   2> 2158237 INFO  
(SUITE-EchoParamsTest-seed#[B808C34BD07D5692]-worker) [] 
o.a.s.s.IndexSchema Loaded schema test/1.0 with uniqueid field id
   [junit4]   2> 2158295 INFO  
(SUITE-EchoParamsTest-seed#[B808C34BD07D5692]-worker) [] 
o.a.s.m.r.SolrJmxReporter JMX monitoring for 'solr.node' (registry 'solr.node') 
enabled at server: com.sun.jmx.mbeanserver.JmxMBeanServer@2d9451
   [junit4]   2> 2158299 INFO  
(SUITE-EchoParamsTest-seed#[B808C34BD07D5692]-worker) [] 
o.a.s.m.r.SolrJmxReporter JMX monitoring for 'solr.jvm' (registry 'solr.jvm') 
enabled at server: com.sun.jmx.mbeanserver.JmxMBeanServer@2d9451
   [junit4]   2> 2158299 INFO  
(SUITE-EchoParamsTest-seed#[B808C34BD07D5692]-worker) [] 
o.a.s.m.r.SolrJmxReporter JMX monitoring for 'solr.jetty' (registry 
'solr.jetty') enabled at server: com.sun.jmx.mbeanserver.JmxMBeanServer@2d9451
   [junit4]   2> 2158301 INFO  (coreLoadExecutor-8716-thread-1) [] 
o.a.s.c.SolrResourceLoader [null] Added 2 

[jira] [Comment Edited] (LUCENE-7848) QueryBuilder.analyzeGraphPhrase does not handle gaps correctly

[Michael Gibney (JIRA)]

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

Michael Gibney edited comment on LUCENE-7848 at 7/12/17 5:36 PM:
-

"Could be a bug somewhere in span queries."^ -- I think the remaining problem 
here is that only one branch (the shortest) of a SpanOrQuery is evaluated, at 
which point the "spanOr" is designated a match (or not) of the 
width/positionEnd of the shortest branch. When the branches of a "spanOr" 
differ in length (as they will as a matter of course for uses of GraphFilters 
such as in the above test), the shorter branch is evaluated, but if a longer 
branch is also a match, it affects the offset of subsequent tokens, and the 
enclosing "spanNear" sees a larger-than-expected slop, and fails to match. 

[^LUCENE-7848-branching-spanOr.patch] adjusts SpanOrQuery to support repeated 
calls to nextStartPosition() which return the same startPosition, but different 
endPositions. The subSpan clauses of the "spanOr" are popped off the 
priorityQueue, retained, and restored upon exhaustion of subSpans (when it's 
time to move on to the next potential match). Some corresponding changes were 
necessary to make NearSpansOrdered aware of the new "spanOr" behavior, and 
conditionally evaluate as many branches of "spanOr" clauses as necessary to 
match (or not) on the full "nearSpan".

There may be other modifications needed in code that can call the modified 
"spanOr" and would need to be aware of its new behavior, but with this patch 
applied, all the tests in the TestWordDelimiterGraphFilter pass (including the 
new testLucene7848()). 

EDIT: original patch had a bug, was re-uploaded a few hours after initially 
posted.


was (Author: mgibney):
"Could be a bug somewhere in span queries."^ -- I think the remaining problem 
here is that only one branch (the shortest) of a SpanOrQuery is evaluated, at 
which point the "spanOr" is designated a match (or not) of the 
width/positionEnd of the shortest branch. When the branches of a "spanOr" 
differ in length (as they will as a matter of course for uses of GraphFilters 
such as in the above test), the shorter branch is evaluated, but if a longer 
branch is also a match, it affects the offset of subsequent tokens, and the 
enclosing "spanNear" sees a larger-than-expected slop, and fails to match. 

[^LUCENE-7848-branching-spanOr.patch] adjusts SpanOrQuery to support repeated 
calls to nextStartPosition() which return the same startPosition, but different 
endPositions. The subSpan clauses of the "spanOr" are popped off the 
priorityQueue, retained, and restored upon exhaustion of subSpans (when it's 
time to move on to the next potential match). Some corresponding changes were 
necessary to make NearSpansOrdered aware of the new "spanOr" behavior, and 
conditionally evaluate as many branches of "spanOr" clauses as necessary to 
match (or not) on the full "nearSpan".

There may be other modifications needed in code that can call the modified 
"spanOr" and would need to be aware of its new behavior, but with this patch 
applied, all the tests in the TestWordDelimiterGraphFilter pass (including the 
new testLucene7848()). 

> QueryBuilder.analyzeGraphPhrase does not handle gaps correctly
> --
>
> Key: LUCENE-7848
> URL: https://issues.apache.org/jira/browse/LUCENE-7848
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.5, 6.6
>Reporter: Jim Ferenczi
> Attachments: capture-3.png, LUCENE-7848-branching-spanOr.patch, 
> LUCENE-7848.patch, LUCENE-7848.patch
>
>
> Position increments greater than 1 are ignored when the query builder creates 
> a graph phrase query. 
> Instead it should use SpanNearQuery.addGap for pos incr > 1.



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

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

[jira] [Updated] (LUCENE-7848) QueryBuilder.analyzeGraphPhrase does not handle gaps correctly

[Michael Gibney (JIRA)]

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

Michael Gibney updated LUCENE-7848:
---
Attachment: (was: LUCENE-7848-branching-spanOr.patch)

> QueryBuilder.analyzeGraphPhrase does not handle gaps correctly
> --
>
> Key: LUCENE-7848
> URL: https://issues.apache.org/jira/browse/LUCENE-7848
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.5, 6.6
>Reporter: Jim Ferenczi
> Attachments: capture-3.png, LUCENE-7848-branching-spanOr.patch, 
> LUCENE-7848.patch, LUCENE-7848.patch
>
>
> Position increments greater than 1 are ignored when the query builder creates 
> a graph phrase query. 
> Instead it should use SpanNearQuery.addGap for pos incr > 1.



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

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

[jira] [Updated] (LUCENE-7848) QueryBuilder.analyzeGraphPhrase does not handle gaps correctly

[Michael Gibney (JIRA)]

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

Michael Gibney updated LUCENE-7848:
---
Attachment: LUCENE-7848-branching-spanOr.patch

> QueryBuilder.analyzeGraphPhrase does not handle gaps correctly
> --
>
> Key: LUCENE-7848
> URL: https://issues.apache.org/jira/browse/LUCENE-7848
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.5, 6.6
>Reporter: Jim Ferenczi
> Attachments: capture-3.png, LUCENE-7848-branching-spanOr.patch, 
> LUCENE-7848.patch, LUCENE-7848.patch
>
>
> Position increments greater than 1 are ignored when the query builder creates 
> a graph phrase query. 
> Instead it should use SpanNearQuery.addGap for pos incr > 1.



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

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

[jira] [Updated] (LUCENE-7848) QueryBuilder.analyzeGraphPhrase does not handle gaps correctly

[Michael Gibney (JIRA)]

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

Michael Gibney updated LUCENE-7848:
---
Attachment: (was: LUCENE-7848-branching-spanOr.patch)

> QueryBuilder.analyzeGraphPhrase does not handle gaps correctly
> --
>
> Key: LUCENE-7848
> URL: https://issues.apache.org/jira/browse/LUCENE-7848
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.5, 6.6
>Reporter: Jim Ferenczi
> Attachments: capture-3.png, LUCENE-7848-branching-spanOr.patch, 
> LUCENE-7848.patch, LUCENE-7848.patch
>
>
> Position increments greater than 1 are ignored when the query builder creates 
> a graph phrase query. 
> Instead it should use SpanNearQuery.addGap for pos incr > 1.



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

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

[jira] [Issue Comment Deleted] (LUCENE-7848) QueryBuilder.analyzeGraphPhrase does not handle gaps correctly

[Michael Gibney (JIRA)]

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

Michael Gibney updated LUCENE-7848:
---
Comment: was deleted

(was: sorry, updated patch)

> QueryBuilder.analyzeGraphPhrase does not handle gaps correctly
> --
>
> Key: LUCENE-7848
> URL: https://issues.apache.org/jira/browse/LUCENE-7848
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.5, 6.6
>Reporter: Jim Ferenczi
> Attachments: capture-3.png, LUCENE-7848-branching-spanOr.patch, 
> LUCENE-7848.patch, LUCENE-7848.patch
>
>
> Position increments greater than 1 are ignored when the query builder creates 
> a graph phrase query. 
> Instead it should use SpanNearQuery.addGap for pos incr > 1.



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

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

[jira] [Updated] (LUCENE-7848) QueryBuilder.analyzeGraphPhrase does not handle gaps correctly

[Michael Gibney (JIRA)]

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

Michael Gibney updated LUCENE-7848:
---
Attachment: LUCENE-7848-branching-spanOr.patch

sorry, updated patch

> QueryBuilder.analyzeGraphPhrase does not handle gaps correctly
> --
>
> Key: LUCENE-7848
> URL: https://issues.apache.org/jira/browse/LUCENE-7848
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.5, 6.6
>Reporter: Jim Ferenczi
> Attachments: capture-3.png, LUCENE-7848-branching-spanOr.patch, 
> LUCENE-7848.patch, LUCENE-7848.patch
>
>
> Position increments greater than 1 are ignored when the query builder creates 
> a graph phrase query. 
> Instead it should use SpanNearQuery.addGap for pos incr > 1.



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

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

[jira] [Commented] (LUCENE-7905) Optimizations for OrdinalMap

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7905:
-

{quote}
That's it, except I also changed:
  while (segmentOrds[segmentIndex] <= segmentOrd) {
ordDeltaBits[segmentIndex] |= delta;
ordDeltas[segmentIndex].add(delta);
segmentOrds[segmentIndex]++;
  }
{quote}

OK, I have to look in more detail later. We should be a little careful because 
this class is also used by merging, and merging has a strange case that you 
won't encounter during manual construction: the case where there are "holes" in 
the ords (deleted ords when all documents containing that ord are merged away). 
Might be best if can test some of this directly...

> Optimizations for OrdinalMap
> 
>
> Key: LUCENE-7905
> URL: https://issues.apache.org/jira/browse/LUCENE-7905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 7.1
>
> Attachments: LUCENE-7905.patch
>
>
> {{OrdinalMap}} is a useful class to quickly map per-segment ordinals to 
> global space, but it's fairly costly to build, which must typically be done 
> on every NRT refresh.
> I'm using it quite heavily in two different places, one for 
> {{SortedSetDocValuesFacetCounts}}, and another custom usage, and I found some 
> small optimizations to improve its construction time.
> I switched it to use a simple priority queue to merge the terms instead of 
> the more general {{MultiTermsEnum}}, which does extra work since it must also 
> provide postings, implement seekExact, etc.
> I also pulled {{OrdinalMap}} out into its own oal.index class.
> When testing construction time for my case the patch is ~16% faster (159.9s 
> -> 134.2s) in one case with 91.4 M terms and ~9% faster (115.6s -> 105.7s) in 
> another case with 26.6 M terms.



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

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

[jira] [Commented] (LUCENE-7905) Optimizations for OrdinalMap

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7905:


bq. Its a bit tricky to see the diffs since the file got moved too, but 
basically it just replaces MultiTermsEnum with a standard PQ?

That's it, except I also changed:

{noformat}
  while (segmentOrds[segmentIndex] <= segmentOrd) {
ordDeltaBits[segmentIndex] |= delta;
ordDeltas[segmentIndex].add(delta);
segmentOrds[segmentIndex]++;
  }
{noformat}

to:

{noformat}
assert segmentOrds[segmentIndex] <= segmentOrd;
do {
  ordDeltas[segmentIndex].add(delta);
  segmentOrds[segmentIndex]++;
} while (segmentOrds[segmentIndex] <= segmentOrd);
{noformat}

Which should make the branch easier to predict (since the loop will always run 
the first time), but maybe the effect is negligible.

I think likely the cost we're saving from MTE is its {{TermMergeQueue.fillTop}} 
method?  It's doing a lot of work, sort of recursing into the PQ, with a if 
inside a for inside a while, to find all subs on the current term, and then it 
has to do {{pushTop}} after that.  In general MTE is not allowed to .next() the 
subs because it doesn't know if the caller will ask for postings on this term.  
[~rcmuir] suggested we could maybe make pullTop()/pushTop() lazy which is a 
neat idea...

> Optimizations for OrdinalMap
> 
>
> Key: LUCENE-7905
> URL: https://issues.apache.org/jira/browse/LUCENE-7905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 7.1
>
> Attachments: LUCENE-7905.patch
>
>
> {{OrdinalMap}} is a useful class to quickly map per-segment ordinals to 
> global space, but it's fairly costly to build, which must typically be done 
> on every NRT refresh.
> I'm using it quite heavily in two different places, one for 
> {{SortedSetDocValuesFacetCounts}}, and another custom usage, and I found some 
> small optimizations to improve its construction time.
> I switched it to use a simple priority queue to merge the terms instead of 
> the more general {{MultiTermsEnum}}, which does extra work since it must also 
> provide postings, implement seekExact, etc.
> I also pulled {{OrdinalMap}} out into its own oal.index class.
> When testing construction time for my case the patch is ~16% faster (159.9s 
> -> 134.2s) in one case with 91.4 M terms and ~9% faster (115.6s -> 105.7s) in 
> another case with 26.6 M terms.



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/6/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateWithDefaultConfigSet

Error Message:


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




Build Log:
[...truncated 12019 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPISolrJTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (LUCENE-7905) Optimizations for OrdinalMap

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7905:


bq. Maybe we should also check how much better things would be with a 
specialized priority queue too? As far as I remember, it helped a lot with 
disjunction scorers.

I like that idea!  I'll look at what we did there and see if it can work here.

bq. Maybe we should decouple OrdinalMap and MultiTermsEnum entirely and give 
OrdinalMap its own TermsEnum+index wrapper?

+1, I'll do that.

> Optimizations for OrdinalMap
> 
>
> Key: LUCENE-7905
> URL: https://issues.apache.org/jira/browse/LUCENE-7905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 7.1
>
> Attachments: LUCENE-7905.patch
>
>
> {{OrdinalMap}} is a useful class to quickly map per-segment ordinals to 
> global space, but it's fairly costly to build, which must typically be done 
> on every NRT refresh.
> I'm using it quite heavily in two different places, one for 
> {{SortedSetDocValuesFacetCounts}}, and another custom usage, and I found some 
> small optimizations to improve its construction time.
> I switched it to use a simple priority queue to merge the terms instead of 
> the more general {{MultiTermsEnum}}, which does extra work since it must also 
> provide postings, implement seekExact, etc.
> I also pulled {{OrdinalMap}} out into its own oal.index class.
> When testing construction time for my case the patch is ~16% faster (159.9s 
> -> 134.2s) in one case with 91.4 M terms and ~9% faster (115.6s -> 105.7s) in 
> another case with 26.6 M terms.



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

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.analytics.NoFacetCloudTest

Error Message:
Error from server at https://127.0.0.1:40201/solr/collection1: Async exception 
during distributed update: Broken pipe (Write failed)

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:40201/solr/collection1: Async exception during 
distributed update: Broken pipe (Write failed)
at __randomizedtesting.SeedInfo.seed([88158922EFDF39A8]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.analytics.AbstractAnalyticsStatsCloudTest.cleanIndex(AbstractAnalyticsStatsCloudTest.java:84)
at 
org.apache.solr.analytics.AbstractAnalyticsStatsCloudTest.setupCluster(AbstractAnalyticsStatsCloudTest.java:78)
at 
org.apache.solr.analytics.NoFacetCloudTest.populate(NoFacetCloudTest.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 15777 lines...]
   [junit4] Suite: org.apache.solr.analytics.NoFacetCloudTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/contrib/solr-analytics/test/J2/temp/solr.analytics.NoFacetCloudTest_88158922EFDF39A8-001/init-core-data-001
   [junit4]   2> Jul 12, 2017 4:18:42 PM 
com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
   [junit4]   2> WARNING: Will linger awaiting termination of 1 leaked 
thread(s).
   [junit4]   2> NOTE: test params are: 

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


Commit 00b5930cc9066ec14cc16aa665f01dc0996e9f1f in lucene-solr's branch 
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=00b5930 ]

SOLR-10796: comment out debug printing


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


Commit 833b4278aca4f56af885c4f0cd03d5a8fc140279 in lucene-solr's branch 
refs/heads/branch_7_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=833b427 ]

SOLR-10796: comment out debug printing


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


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

SOLR-10796: comment out debug printing


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Updated] (SOLR-11052) reserveCommitDuration from Integer to Long

[Ramsey Haddad (JIRA)]

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

Ramsey Haddad updated SOLR-11052:
-
Attachment: SOLR-11052.patch

Small fix.

> reserveCommitDuration from Integer to Long
> --
>
> Key: SOLR-11052
> URL: https://issues.apache.org/jira/browse/SOLR-11052
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Reporter: Ramsey Haddad
>Priority: Trivial
> Attachments: SOLR-11052.patch
>
>
> reserveCommitDuration gets created as a Long and then stored as an Integer.
> It is used as a Long and hence get reconverted back from Integer to Long.
> Let's just leave it as a Long the whole time.



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

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

[jira] [Updated] (SOLR-11052) reserveCommitDuration from Integer to Long

[Ramsey Haddad (JIRA)]

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

Ramsey Haddad updated SOLR-11052:
-
Security: (was: Public)

> reserveCommitDuration from Integer to Long
> --
>
> Key: SOLR-11052
> URL: https://issues.apache.org/jira/browse/SOLR-11052
> Project: Solr
>  Issue Type: Improvement
>  Components: replication (java)
>Reporter: Ramsey Haddad
>Priority: Trivial
> Attachments: SOLR-11052.patch
>
>
> reserveCommitDuration gets created as a Long and then stored as an Integer.
> It is used as a Long and hence get reconverted back from Integer to Long.
> Let's just leave it as a Long the whole time.



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

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

[jira] [Commented] (SOLR-11046) Add residuals Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11046:


Commit d35da77b72af3a6ed2132e7d59712713c2ca4a3a in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d35da77 ]

SOLR-11046: Add residuals Stream Evaluator


> Add residuals Stream Evaluator
> --
>
> Key: SOLR-11046
> URL: https://issues.apache.org/jira/browse/SOLR-11046
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-11046.patch, SOLR-11046.patch
>
>
> The residuals stream evaluator returns an array of the residuals (difference 
> between predicted and actual values) from applying a simple regression model 
> to a sample set.
> {code}
> a = regress(b, c)
> d = residuals(a, b, c)
> {code}



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

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


Commit 6188c8ce389d187e49453668bc194074cac72842 in lucene-solr's branch 
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6188c8c ]

SOLR-10796: fix long overflow in testLongPointFieldRangeFacet()


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


Commit 821caefe12e8ecde7434f94d517c239121d5768d in lucene-solr's branch 
refs/heads/branch_7_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=821caef ]

SOLR-10796: fix long overflow in testLongPointFieldRangeFacet()


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


Commit 79515eda6c01cf0591b4cf8ed42a34f7465f934a in lucene-solr's branch 
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=79515ed ]

SOLR-10796: fix long overflow in testLongPointFieldRangeFacet()


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Created] (SOLR-11052) reserveCommitDuration from Integer to Long

[Ramsey Haddad (JIRA)]

Ramsey Haddad created SOLR-11052:


 Summary: reserveCommitDuration from Integer to Long
 Key: SOLR-11052
 URL: https://issues.apache.org/jira/browse/SOLR-11052
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: replication (java)
Reporter: Ramsey Haddad
Priority: Trivial


reserveCommitDuration gets created as a Long and then stored as an Integer.
It is used as a Long and hence get reconverted back from Integer to Long.

Let's just leave it as a Long the whole time.




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

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

[jira] [Commented] (LUCENE-7905) Optimizations for OrdinalMap

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7905:
--

I like the idea of switching to a simple priority queue to remove overhead. 
Maybe we should also check how much better things would be with a specialized 
priority queue too? As far as I remember, it helped a lot with disjunction 
scorers.

One minor thing that confuses me with the patch is that it moves off 
{{MultiTermsEnum}} but reuses {{MultiTermsEnum.TermsEnumIndex}} and adds an 
additional method to it. Maybe we should decouple {{OrdinalMap}} and  
{{MultiTermsEnum}} entirely and give {{OrdinalMap}} its own {{TermsEnum}}+index 
wrapper?

> Optimizations for OrdinalMap
> 
>
> Key: LUCENE-7905
> URL: https://issues.apache.org/jira/browse/LUCENE-7905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 7.1
>
> Attachments: LUCENE-7905.patch
>
>
> {{OrdinalMap}} is a useful class to quickly map per-segment ordinals to 
> global space, but it's fairly costly to build, which must typically be done 
> on every NRT refresh.
> I'm using it quite heavily in two different places, one for 
> {{SortedSetDocValuesFacetCounts}}, and another custom usage, and I found some 
> small optimizations to improve its construction time.
> I switched it to use a simple priority queue to merge the terms instead of 
> the more general {{MultiTermsEnum}}, which does extra work since it must also 
> provide postings, implement seekExact, etc.
> I also pulled {{OrdinalMap}} out into its own oal.index class.
> When testing construction time for my case the patch is ~16% faster (159.9s 
> -> 134.2s) in one case with 91.4 M terms and ~9% faster (115.6s -> 105.7s) in 
> another case with 26.6 M terms.



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

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

[jira] [Commented] (LUCENE-7905) Optimizations for OrdinalMap

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7905:
-

Its a bit tricky to see the diffs since the file got moved too, but basically 
it just replaces MultiTermsEnum with a standard PQ?

Do we know why this is a speedup? Is it an inefficiency in MultiTermsEnum?

> Optimizations for OrdinalMap
> 
>
> Key: LUCENE-7905
> URL: https://issues.apache.org/jira/browse/LUCENE-7905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 7.1
>
> Attachments: LUCENE-7905.patch
>
>
> {{OrdinalMap}} is a useful class to quickly map per-segment ordinals to 
> global space, but it's fairly costly to build, which must typically be done 
> on every NRT refresh.
> I'm using it quite heavily in two different places, one for 
> {{SortedSetDocValuesFacetCounts}}, and another custom usage, and I found some 
> small optimizations to improve its construction time.
> I switched it to use a simple priority queue to merge the terms instead of 
> the more general {{MultiTermsEnum}}, which does extra work since it must also 
> provide postings, implement seekExact, etc.
> I also pulled {{OrdinalMap}} out into its own oal.index class.
> When testing construction time for my case the patch is ~16% faster (159.9s 
> -> 134.2s) in one case with 91.4 M terms and ~9% faster (115.6s -> 105.7s) in 
> another case with 26.6 M terms.



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

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

[jira] [Commented] (LUCENE-7905) Optimizations for OrdinalMap

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7905:
-

>From your explain that MTE must do more work because it "provides postings", 
>this doesn't seem right to me that it would slow down the actual merging of 
>terms. I can see the argument about seekExact because next() has some special 
>code to accomodate that:

https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/MultiTermsEnum.java#L287-L298


> Optimizations for OrdinalMap
> 
>
> Key: LUCENE-7905
> URL: https://issues.apache.org/jira/browse/LUCENE-7905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 7.1
>
> Attachments: LUCENE-7905.patch
>
>
> {{OrdinalMap}} is a useful class to quickly map per-segment ordinals to 
> global space, but it's fairly costly to build, which must typically be done 
> on every NRT refresh.
> I'm using it quite heavily in two different places, one for 
> {{SortedSetDocValuesFacetCounts}}, and another custom usage, and I found some 
> small optimizations to improve its construction time.
> I switched it to use a simple priority queue to merge the terms instead of 
> the more general {{MultiTermsEnum}}, which does extra work since it must also 
> provide postings, implement seekExact, etc.
> I also pulled {{OrdinalMap}} out into its own oal.index class.
> When testing construction time for my case the patch is ~16% faster (159.9s 
> -> 134.2s) in one case with 91.4 M terms and ~9% faster (115.6s -> 105.7s) in 
> another case with 26.6 M terms.



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

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

[jira] [Resolved] (SOLR-11046) Add residuals Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein resolved SOLR-11046.
---
   Resolution: Resolved
Fix Version/s: 7.1
   master (8.0)

> Add residuals Stream Evaluator
> --
>
> Key: SOLR-11046
> URL: https://issues.apache.org/jira/browse/SOLR-11046
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11046.patch, SOLR-11046.patch
>
>
> The residuals stream evaluator returns an array of the residuals (difference 
> between predicted and actual values) from applying a simple regression model 
> to a sample set.
> {code}
> a = regress(b, c)
> d = residuals(a, b, c)
> {code}



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

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

[jira] [Updated] (LUCENE-7905) Optimizations for OrdinalMap

[Michael McCandless (JIRA)]

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

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

Patch; I think it's ready.

> Optimizations for OrdinalMap
> 
>
> Key: LUCENE-7905
> URL: https://issues.apache.org/jira/browse/LUCENE-7905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 7.1
>
> Attachments: LUCENE-7905.patch
>
>
> {{OrdinalMap}} is a useful class to quickly map per-segment ordinals to 
> global space, but it's fairly costly to build, which must typically be done 
> on every NRT refresh.
> I'm using it quite heavily in two different places, one for 
> {{SortedSetDocValuesFacetCounts}}, and another custom usage, and I found some 
> small optimizations to improve its construction time.
> I switched it to use a simple priority queue to merge the terms instead of 
> the more general {{MultiTermsEnum}}, which does extra work since it must also 
> provide postings, implement seekExact, etc.
> I also pulled {{OrdinalMap}} out into its own oal.index class.
> When testing construction time for my case the patch is ~16% faster (159.9s 
> -> 134.2s) in one case with 91.4 M terms and ~9% faster (115.6s -> 105.7s) in 
> another case with 26.6 M terms.



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

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

[jira] [Commented] (SOLR-10994) CREATE & CREATESHARD to support replica types when using policy

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-10994:
--

Shouldn't this also work with addReplica API?

> CREATE & CREATESHARD to support replica types when using policy
> ---
>
> Key: SOLR-10994
> URL: https://issues.apache.org/jira/browse/SOLR-10994
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>




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

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

[jira] [Commented] (SOLR-11046) Add residuals Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11046:


Commit 840a3c9d4c2bc38b137984894db151cd395c1548 in lucene-solr's branch 
refs/heads/branch_7x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=840a3c9 ]

SOLR-11046: Update CHANGES.txt


> Add residuals Stream Evaluator
> --
>
> Key: SOLR-11046
> URL: https://issues.apache.org/jira/browse/SOLR-11046
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-11046.patch, SOLR-11046.patch
>
>
> The residuals stream evaluator returns an array of the residuals (difference 
> between predicted and actual values) from applying a simple regression model 
> to a sample set.
> {code}
> a = regress(b, c)
> d = residuals(a, b, c)
> {code}



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

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

[jira] [Commented] (SOLR-11046) Add residuals Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11046:


Commit d65cbac7b289a97385385c4586e555c7a7952c54 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d65cbac ]

SOLR-11046: Update CHANGES.txt


> Add residuals Stream Evaluator
> --
>
> Key: SOLR-11046
> URL: https://issues.apache.org/jira/browse/SOLR-11046
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-11046.patch, SOLR-11046.patch
>
>
> The residuals stream evaluator returns an array of the residuals (difference 
> between predicted and actual values) from applying a simple regression model 
> to a sample set.
> {code}
> a = regress(b, c)
> d = residuals(a, b, c)
> {code}



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

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

[jira] [Created] (LUCENE-7905) Optimizations for OrdinalMap

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-7905:
--

 Summary: Optimizations for OrdinalMap
 Key: LUCENE-7905
 URL: https://issues.apache.org/jira/browse/LUCENE-7905
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 7.1
 Attachments: LUCENE-7905.patch

{{OrdinalMap}} is a useful class to quickly map per-segment ordinals to global 
space, but it's fairly costly to build, which must typically be done on every 
NRT refresh.

I'm using it quite heavily in two different places, one for 
{{SortedSetDocValuesFacetCounts}}, and another custom usage, and I found some 
small optimizations to improve its construction time.

I switched it to use a simple priority queue to merge the terms instead of the 
more general {{MultiTermsEnum}}, which does extra work since it must also 
provide postings, implement seekExact, etc.

I also pulled {{OrdinalMap}} out into its own oal.index class.

When testing construction time for my case the patch is ~16% faster (159.9s -> 
134.2s) in one case with 91.4 M terms and ~9% faster (115.6s -> 105.7s) in 
another case with 26.6 M terms.




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

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

[jira] [Commented] (SOLR-11046) Add residuals Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11046:


Commit caed6f83107dd6cffbf15a8ef62a05628e90fc23 in lucene-solr's branch 
refs/heads/branch_7x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=caed6f8 ]

SOLR-11046: Add residuals Stream Evaluator


> Add residuals Stream Evaluator
> --
>
> Key: SOLR-11046
> URL: https://issues.apache.org/jira/browse/SOLR-11046
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-11046.patch, SOLR-11046.patch
>
>
> The residuals stream evaluator returns an array of the residuals (difference 
> between predicted and actual values) from applying a simple regression model 
> to a sample set.
> {code}
> a = regress(b, c)
> d = residuals(a, b, c)
> {code}



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:50823/solr: ADDREPLICA failed to create 
replica

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:50823/solr: ADDREPLICA failed to create replica
at 
__randomizedtesting.SeedInfo.seed([DEDE741B70AABF46:B43FFA704D30093E]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks

[Vivek Narang (JIRA)]

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

Vivek Narang commented on SOLR-10317:
-

Hello [~ichattopadhyaya]

Wikipedia data - done.
Unified page view - pending.
Merging menu items - done.
Code formatting - in progress, partially done.
Args parameter renaming - done.
Log4j - done.
Label adjustment - pending. 

Regards
Vivek


> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> SOLR-10317.patch, SOLR-10317.patch, solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



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

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

[jira] [Updated] (SOLR-11046) Add residuals Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11046:
--
Attachment: SOLR-11046.patch

> Add residuals Stream Evaluator
> --
>
> Key: SOLR-11046
> URL: https://issues.apache.org/jira/browse/SOLR-11046
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-11046.patch, SOLR-11046.patch
>
>
> The residuals stream evaluator returns an array of the residuals (difference 
> between predicted and actual values) from applying a simple regression model 
> to a sample set.
> {code}
> a = regress(b, c)
> d = residuals(a, b, c)
> {code}



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

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

[jira] [Updated] (SOLR-10962) replicationHandler's reserveCommitDuration configurable in SolrCloud mode

[Ramsey Haddad (JIRA)]

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

Ramsey Haddad updated SOLR-10962:
-
Attachment: SOLR-10962.patch

Here is what this looks like using the Config API.

We initially tried to convert all the controls for ReplicationHandler, but it 
became too much of a mess.
* partly messy because the args passed onto IndexFetcher can come from two 
places
* partly because of the work to put in backward compatibility warnings
So we only changed what we need at the moment.

We ended up partitioning the Info structure work between SolrConfig and 
*Handler in a different way than UpdateHandler, because:
* we wanted to still allow the legacy default "00:00:10" behavior
* we wanted to keep various ReplicationHandler details local to that class

Also, since the internals work in MilliSeconds, we thought it simpler to expose 
that to the user.


> replicationHandler's reserveCommitDuration configurable in SolrCloud mode
> -
>
> Key: SOLR-10962
> URL: https://issues.apache.org/jira/browse/SOLR-10962
> Project: Solr
>  Issue Type: New Feature
>  Components: replication (java)
>Reporter: Ramsey Haddad
>Priority: Minor
> Attachments: SOLR-10962.patch, SOLR-10962.patch, SOLR-10962.patch, 
> SOLR-10962.patch, SOLR-10962.patch
>
>
> With SolrCloud mode, when doing replication via IndexFetcher, we occasionally 
> see the Fetch fail and then get restarted from scratch in cases where an 
> Index file is deleted after fetch manifest is computed and before the fetch 
> actually transfers the file. The risk of this happening can be reduced with a 
> higher value of reserveCommitDuration. However, the current configuration 
> only allows this value to be adjusted for "master" mode. This change allows 
> the value to also be changed when using "SolrCloud" mode.
> https://lucene.apache.org/solr/guide/6_6/index-replication.html



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

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