[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-9) - Build # 6964 - Unstable!

2017-10-17 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6964/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

1 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication

Error Message:
Index 0 out-of-bounds for length 0

Stack Trace:
java.lang.IndexOutOfBoundsException: Index 0 out-of-bounds for length 0
at 
__randomizedtesting.SeedInfo.seed([8EDEF00CA3FD9744:9A96AB5980FA2A5A]:0)
at 
java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
at 
java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
at 
java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
at java.base/java.util.Objects.checkIndex(Objects.java:372)
at java.base/java.util.ArrayList.get(ArrayList.java:439)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication(TestReplicationHandler.java:561)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Updated] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false

2017-10-17 Thread Erick Erickson (JIRA)

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

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

And, of course looking "just one more time before going to sleep" surfaced a 
problem, fixed.

> Collections created with legacyCloud=true cannot be opened if 
> legacyCloud=false
> ---
>
> Key: SOLR-11503
> URL: https://issues.apache.org/jira/browse/SOLR-11503
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Critical
> Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch
>
>
> SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a 
> collection with legacyCloud=true then switch to legacyCloud=false, you get an 
> NPE because coreNodeName is not defined in core.properties.
> Since the default for legacyCloud changed from true to false between 6.6.1 
> and 7.x, this means that any attempt to upgrade Solr with existing 
> collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value 
> for legacyCloud is used in both. Collections created with 6.6.0 would work. 
> Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.
> This is not as egregious with any collections *created with 7.0* since if the 
> default legacyCloud=false is present when the core is created, properties are 
> persisted with coreNodeName. However, if someone switches legacyCloud to 
> true, then creates a collection, then changes legacyCloud back to false then 
> they'll hit this even in 7.0+
> This happened because bit of reordering switched the order of the calls 
> below. coreNodeName is added to the descriptor in 
> create/createFromDescriptor(this, cd) via zkContgroller.preRegister so 
> coresLocator.create(this, cd) persists core.properties without coreNodeName.
> _original order_
> SolrCore core = createFromDescriptor(cd, true, newCollection);
> coresLocator.create(this, cd);
> (NOTE: private calls to create were renamed to createFromDescriptor in 
> SOLR-11122).
> I've got a fix in the works for creating cores, I'll attach a preliminary 
> patch w/o tests in a bit for discussion, but the question is really what to 
> do about 6.6.1 and 6.6.2 and 7.1 for that matter. 
> This is compounded by the fact that with the CVE, there's strong incentive to 
> move to 6.6.2. sgh.
> There are two parts to fixing this completely:
> 1> create core.properties correctly
> 2> deal with coreNodeName not being in the core.properties file by going to 
> ZK and getting it (and persisting it). Haven't worked that part out yet 
> though, not in the first patch. Note one point here if it works as I hope it 
> will update the core.properties files first time they're opened.
> Options that I see, there are really two parts:
> *part1 create the core.properties correctly*
> > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> > Recommend people not install 7x over collections created with 6x until they 
> > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and 
> > creating collections is at your own risk.
> > Recommend that people change legacyCloud=true in 7.x until they start 
> > working with a fixed version, which one TBD.
> *part2 deal with coreNodeName not being in the core.properties*
> > Not backport and release with 7.2? set legacyCloud=true until then.
> > Backport to point releases like 7.1.1? 6.6.3?
> > and what about 7.0? I don't think many people will be affected by 7.0 since 
> > 7.1 came out so soon after. And setting legacyCloud=true will let people 
> > get by.
> Fixing the two parts is not a question, they both need to be fixed. The real 
> question is whether we need to create a point release that incorporates one 
> or both or whether saying "you must set legacyCloud=true prior to Solr 
> version 7.# in order to work with any collections created with Solr versions 
> 6.6.1 through 7.#".
> Let's hear opinions..



--
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 # 2675 - Failure

2017-10-17 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Solr-reference-guide-master/2675/

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 7e789b376c46936e6b7b813d4514b28f0a87bc2d 
(refs/remotes/origin/master)
Commit message: "SOLR-10798: and SOLR-11205 documentation"
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7e789b376c46936e6b7b813d4514b28f0a87bc2d
 > git rev-list 3eeeb9fa4d2cf1751b6cc60b2f1fb708417af8e8 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /usr/bin/env bash 
/tmp/jenkins9027463240242.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.3.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.3/1.29.3.tar.gz.asc
gpg: Signature made Sun 10 Sep 2017 08:59:21 PM UTC using RSA key ID BF04FF17
gpg: Good signature from "Michal Papis (RVM signing) "
gpg: aka "Michal Papis "
gpg: aka "[jpeg image of size 5015]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 409B 6B17 96C2 7546 2A17  0311 3804 BB82 D39D C0E3
 Subkey fingerprint: 62C9 E5F4 DA30 0D94 AC36  166B E206 C29F BF04 FF17
GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.3.tgz'

Upgrading the RVM installation in /home/jenkins/.rvm/
Upgrade of RVM in /home/jenkins/.rvm/ is complete.

Upgrade Notes:

  * No new notes to display.

+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm autolibs disable'
Running 'rvm install ruby-2.3.3'
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset wrappers
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
Parsing documentation for jekyll-3.5.0
Done installing documentation for jekyll after 2 seconds
1 gem installed
Running 'gem install --force --version 2.1.0 jekyll-asciidoc'
Successfully installed jekyll-asciidoc-2.1.0
Parsing documentation for jekyll-asciidoc-2.1.0
Done installing documentation for jekyll-asciidoc after 0 seconds
1 gem installed
Running 'gem install --force --version 1.1.2 pygments.rb'
Successfully installed pygments.rb-1.1.2
Parsing documentation for pygments.rb-1.1.2
Done installing documentation for pygments.rb after 0 seconds
1 gem installed
+ ant clean build-site build-pdf
Buildfile: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/solr-ref-guide/build.xml

clean:

build-init:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copying all non template files from src ...
 [copy] Copying 371 files to 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copy (w/prop replacement) any template files from src...
 [copy] Copying 1 file to 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: 
http://ant.apache.org/ivy/ ::
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/lucene/top-level-ivy-settings.xml

resolve:
[ivy:retrieve] 
[ivy:retrieve] :: problems summary ::
[ivy:retrieve]  ERRORS
[ivy:retrieve]  unknown resolver null
[ivy:retrieve]  unknown resolver null
[ivy:retrieve]  unknown resolver null
[ivy:retrieve]  unknown resolver 

[jira] [Updated] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false

2017-10-17 Thread Erick Erickson (JIRA)

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

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

Patch that has tests and implements both fixes.

Work in progress. It's kind of late and I'll need to look at it with fresh 
eyes, comments welcome.

Curiously, the test (without the fixes) succeeds on master, apparently that 
code has changed a bit. So I'm developing against 7x.

> Collections created with legacyCloud=true cannot be opened if 
> legacyCloud=false
> ---
>
> Key: SOLR-11503
> URL: https://issues.apache.org/jira/browse/SOLR-11503
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Critical
> Attachments: SOLR-11503.patch, SOLR-11503.patch
>
>
> SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a 
> collection with legacyCloud=true then switch to legacyCloud=false, you get an 
> NPE because coreNodeName is not defined in core.properties.
> Since the default for legacyCloud changed from true to false between 6.6.1 
> and 7.x, this means that any attempt to upgrade Solr with existing 
> collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value 
> for legacyCloud is used in both. Collections created with 6.6.0 would work. 
> Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.
> This is not as egregious with any collections *created with 7.0* since if the 
> default legacyCloud=false is present when the core is created, properties are 
> persisted with coreNodeName. However, if someone switches legacyCloud to 
> true, then creates a collection, then changes legacyCloud back to false then 
> they'll hit this even in 7.0+
> This happened because bit of reordering switched the order of the calls 
> below. coreNodeName is added to the descriptor in 
> create/createFromDescriptor(this, cd) via zkContgroller.preRegister so 
> coresLocator.create(this, cd) persists core.properties without coreNodeName.
> _original order_
> SolrCore core = createFromDescriptor(cd, true, newCollection);
> coresLocator.create(this, cd);
> (NOTE: private calls to create were renamed to createFromDescriptor in 
> SOLR-11122).
> I've got a fix in the works for creating cores, I'll attach a preliminary 
> patch w/o tests in a bit for discussion, but the question is really what to 
> do about 6.6.1 and 6.6.2 and 7.1 for that matter. 
> This is compounded by the fact that with the CVE, there's strong incentive to 
> move to 6.6.2. sgh.
> There are two parts to fixing this completely:
> 1> create core.properties correctly
> 2> deal with coreNodeName not being in the core.properties file by going to 
> ZK and getting it (and persisting it). Haven't worked that part out yet 
> though, not in the first patch. Note one point here if it works as I hope it 
> will update the core.properties files first time they're opened.
> Options that I see, there are really two parts:
> *part1 create the core.properties correctly*
> > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> > Recommend people not install 7x over collections created with 6x until they 
> > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and 
> > creating collections is at your own risk.
> > Recommend that people change legacyCloud=true in 7.x until they start 
> > working with a fixed version, which one TBD.
> *part2 deal with coreNodeName not being in the core.properties*
> > Not backport and release with 7.2? set legacyCloud=true until then.
> > Backport to point releases like 7.1.1? 6.6.3?
> > and what about 7.0? I don't think many people will be affected by 7.0 since 
> > 7.1 came out so soon after. And setting legacyCloud=true will let people 
> > get by.
> Fixing the two parts is not a question, they both need to be fixed. The real 
> question is whether we need to create a point release that incorporates one 
> or both or whether saying "you must set legacyCloud=true prior to Solr 
> version 7.# in order to work with any collections created with Solr versions 
> 6.6.1 through 7.#".
> Let's hear opinions..



--
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-Linux (64bit/jdk-9) - Build # 625 - Still Unstable!

2017-10-17 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/625/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseParallelGC 
--illegal-access=deny

2 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.ExecutePlanActionTest.testExecute

Error Message:
Error from server at https://127.0.0.1:41689/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:41689/solr: create the collection time out:180s
at 
__randomizedtesting.SeedInfo.seed([4C206161B40360A0:7D90736CA6F49F27]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
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.autoscaling.ExecutePlanActionTest.testExecute(ExecutePlanActionTest.java:93)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-Tests-5.5 - Build # 30 - Failure

2017-10-17 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.5/30/

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

Error Message:
KeeperErrorCode = Session expired for /clusterstate.json

Stack Trace:
org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = 
Session expired for /clusterstate.json
at 
__randomizedtesting.SeedInfo.seed([E8C14E5C07999641:60957186A965FBB9]:0)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:127)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155)
at 
org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:345)
at 
org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:342)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
at 
org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:342)
at 
org.apache.solr.common.cloud.ZkStateReader.refreshLegacyClusterState(ZkStateReader.java:433)
at 
org.apache.solr.common.cloud.ZkStateReader.updateClusterState(ZkStateReader.java:238)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:148)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:130)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:832)
at 
org.apache.solr.cloud.UnloadDistributedZkTest.testUnloadShardAndCollection(UnloadDistributedZkTest.java:140)
at 
org.apache.solr.cloud.UnloadDistributedZkTest.test(UnloadDistributedZkTest.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)

[jira] [Commented] (SOLR-10798) Add support for different replica types in the new policy framework

2017-10-17 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-10798:


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

SOLR-10798: and SOLR-11205 documentation


> Add support for different replica types in the new policy framework
> ---
>
> Key: SOLR-10798
> URL: https://issues.apache.org/jira/browse/SOLR-10798
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 7.1
>
>
> The current syntax is for 
> example 
> {code}
> //ensures that at least 2 replicas go to servers with port 8983
> {"replica":">1", "shard":"#ANY" ,"port":8983}
> {code}
> We should add an implicit attribute called {{type}} and the value of {{type}}
> can be {{NRT}} (default) , {{TLOG}} or {{PULL}}
> so a policy would look as follows
> {code}
> {"replica":"1", "shard":"#ANY" ,"port":8983, "type":"NRT"}
> {"replica":"1", "shard":"#ANY" ,"port":7574, "type":"PULL"}
> {"replica":"1", "shard":"#ANY" ,"port":7573, "type":"TLOG"}
> {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-11205) Make arbitrary metrics values available for policies

2017-10-17 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11205:


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

SOLR-10798: and SOLR-11205 documentation


> Make arbitrary metrics values available for policies
> 
>
> Key: SOLR-11205
> URL: https://issues.apache.org/jira/browse/SOLR-11205
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> Any metric available in the metrics API should be available for policy 
> configurations.
> Example;
> {code}
> {'replica': 0, 'metrics:solr.jvm/os.systemLoadAverage': '<0.5'}
> {code}
> So the syntax to use a metric is:
> {code}
> metrics:/
> {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-11205) Make arbitrary metrics values available for policies

2017-10-17 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11205:


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

SOLR-10798: and SOLR-11205 documentation


> Make arbitrary metrics values available for policies
> 
>
> Key: SOLR-11205
> URL: https://issues.apache.org/jira/browse/SOLR-11205
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> Any metric available in the metrics API should be available for policy 
> configurations.
> Example;
> {code}
> {'replica': 0, 'metrics:solr.jvm/os.systemLoadAverage': '<0.5'}
> {code}
> So the syntax to use a metric is:
> {code}
> metrics:/
> {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-10798) Add support for different replica types in the new policy framework

2017-10-17 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-10798:


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

SOLR-10798: and SOLR-11205 documentation


> Add support for different replica types in the new policy framework
> ---
>
> Key: SOLR-10798
> URL: https://issues.apache.org/jira/browse/SOLR-10798
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 7.1
>
>
> The current syntax is for 
> example 
> {code}
> //ensures that at least 2 replicas go to servers with port 8983
> {"replica":">1", "shard":"#ANY" ,"port":8983}
> {code}
> We should add an implicit attribute called {{type}} and the value of {{type}}
> can be {{NRT}} (default) , {{TLOG}} or {{PULL}}
> so a policy would look as follows
> {code}
> {"replica":"1", "shard":"#ANY" ,"port":8983, "type":"NRT"}
> {"replica":"1", "shard":"#ANY" ,"port":7574, "type":"PULL"}
> {"replica":"1", "shard":"#ANY" ,"port":7573, "type":"TLOG"}
> {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-11205) Make arbitrary metrics values available for policies

2017-10-17 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11205:


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

SOLR-10798: and SOLR-11205 documentation


> Make arbitrary metrics values available for policies
> 
>
> Key: SOLR-11205
> URL: https://issues.apache.org/jira/browse/SOLR-11205
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> Any metric available in the metrics API should be available for policy 
> configurations.
> Example;
> {code}
> {'replica': 0, 'metrics:solr.jvm/os.systemLoadAverage': '<0.5'}
> {code}
> So the syntax to use a metric is:
> {code}
> metrics:/
> {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-10798) Add support for different replica types in the new policy framework

2017-10-17 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-10798:


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

SOLR-10798: and SOLR-11205 documentation


> Add support for different replica types in the new policy framework
> ---
>
> Key: SOLR-10798
> URL: https://issues.apache.org/jira/browse/SOLR-10798
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 7.1
>
>
> The current syntax is for 
> example 
> {code}
> //ensures that at least 2 replicas go to servers with port 8983
> {"replica":">1", "shard":"#ANY" ,"port":8983}
> {code}
> We should add an implicit attribute called {{type}} and the value of {{type}}
> can be {{NRT}} (default) , {{TLOG}} or {{PULL}}
> so a policy would look as follows
> {code}
> {"replica":"1", "shard":"#ANY" ,"port":8983, "type":"NRT"}
> {"replica":"1", "shard":"#ANY" ,"port":7574, "type":"PULL"}
> {"replica":"1", "shard":"#ANY" ,"port":7573, "type":"TLOG"}
> {code}



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

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



[jira] [Resolved] (SOLR-11505) solr.cmd start of solr7.0.1 can't working in win7-64

2017-10-17 Thread cloverliu (JIRA)

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

cloverliu resolved SOLR-11505.
--
Resolution: Fixed

i debug the solr.cmd . i  use command : solr.cmd start -f -V , and i found the 
script will stop in line 1017[For /f "tokens=2,5" %%j in ('netstat -aon ... ].  
This code dose not work on my computer. I changed it to +{color:red}For /f 
"tokens=2,5" %%j in ('netstat -aon -p TCP ^| findstr ":0 " ^| findstr 
":%SOLR_PORT% "') do ({color}+ . then it runs successfully!!

> solr.cmd start of solr7.0.1 can't working in win7-64
> 
>
> Key: SOLR-11505
> URL: https://issues.apache.org/jira/browse/SOLR-11505
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCLI
>Affects Versions: 7.0.1
> Environment: windows 7
>Reporter: cloverliu
>Priority: Critical
>
> http://archive.apache.org/dist/lucene/solr/7.0.1/solr-7.0.1.zip   
>  solr.cmd start of this file can't working in my win7-64bit.



--
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-11490) Add @since javadoc tags to the interesting Solr/Lucene classes

2017-10-17 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11490:


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

SOLR-11490: Add missing @since tags
To all descendants of TokenFilterFactory

(cherry picked from commit 3eeeb9fa4d2cf1751b6cc60b2f1fb708417af8e8)


> Add @since javadoc tags to the interesting Solr/Lucene classes
> --
>
> Key: SOLR-11490
> URL: https://issues.apache.org/jira/browse/SOLR-11490
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
>
> As per the discussion on the dev list, it may be useful to add Javadoc since 
> tags to significant (or even all) Java files.
> For user-facing files (such as analyzers, URPs, stream evaluators, etc) it 
> would be useful when trying to identifying whether a particular class only 
> comes later than user's particular version.
> For other classes, it may be useful for historical reasons.



--
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-11505) solr.cmd start of solr7.0.1 can't working in win7-64

2017-10-17 Thread cloverliu (JIRA)

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

cloverliu updated SOLR-11505:
-
Summary: solr.cmd start of solr7.0.1 can't working in win7-64  (was: 
solr.cmd start of solr7.0.1 can't working)

> solr.cmd start of solr7.0.1 can't working in win7-64
> 
>
> Key: SOLR-11505
> URL: https://issues.apache.org/jira/browse/SOLR-11505
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCLI
>Affects Versions: 7.0.1
> Environment: windows 7
>Reporter: cloverliu
>Priority: Critical
>
> http://archive.apache.org/dist/lucene/solr/7.0.1/solr-7.0.1.zip   
>  solr.cmd start of this file can't working in my win7-64bit.



--
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-11490) Add @since javadoc tags to the interesting Solr/Lucene classes

2017-10-17 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11490:


Commit 3eeeb9fa4d2cf1751b6cc60b2f1fb708417af8e8 in lucene-solr's branch 
refs/heads/master from [~arafalov]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3eeeb9f ]

SOLR-11490: Add missing @since tags
To all descendants of TokenFilterFactory


> Add @since javadoc tags to the interesting Solr/Lucene classes
> --
>
> Key: SOLR-11490
> URL: https://issues.apache.org/jira/browse/SOLR-11490
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
>
> As per the discussion on the dev list, it may be useful to add Javadoc since 
> tags to significant (or even all) Java files.
> For user-facing files (such as analyzers, URPs, stream evaluators, etc) it 
> would be useful when trying to identifying whether a particular class only 
> comes later than user's particular version.
> For other classes, it may be useful for historical reasons.



--
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-11505) solr.cmd start of solr7.0.1 can't working

2017-10-17 Thread cloverliu (JIRA)

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

cloverliu updated SOLR-11505:
-
Description: 
http://archive.apache.org/dist/lucene/solr/7.0.1/solr-7.0.1.zip   
 solr.cmd start of this file can't working in my win7-64bit.

  was:
http://archive.apache.org/dist/lucene/solr/7.0.1/solr-7.0.1.zip   
 start.cmd of this file can't working in my win7-64bit.

Summary: solr.cmd start of solr7.0.1 can't working  (was: start.cmd  of 
solr7.0.1 can't working)

> solr.cmd start of solr7.0.1 can't working
> -
>
> Key: SOLR-11505
> URL: https://issues.apache.org/jira/browse/SOLR-11505
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCLI
>Affects Versions: 7.0.1
> Environment: windows 7
>Reporter: cloverliu
>Priority: Critical
>
> http://archive.apache.org/dist/lucene/solr/7.0.1/solr-7.0.1.zip   
>  solr.cmd start of this file can't working in my win7-64bit.



--
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-11505) start.cmd of solr7.0.1 can't working

2017-10-17 Thread cloverliu (JIRA)
cloverliu created SOLR-11505:


 Summary: start.cmd  of solr7.0.1 can't working
 Key: SOLR-11505
 URL: https://issues.apache.org/jira/browse/SOLR-11505
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCLI
Affects Versions: 7.0.1
 Environment: windows 7
Reporter: cloverliu
Priority: Critical


http://archive.apache.org/dist/lucene/solr/7.0.1/solr-7.0.1.zip   
 start.cmd of this file can't working in my win7-64bit.



--
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-11292) Querying against an alias can lead to incorrect routing

2017-10-17 Thread David Smiley (JIRA)

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

David Smiley commented on SOLR-11292:
-

I noticed that logic too [~varunthacker] while working on SOLR-11444.  
[~ichattopadhyaya] I recall you added the stateProvider stuff.  Would there be 
a performance problem if CloudSolrClient resolved aliases first, thereby doing 
an HTTP fetch for aliases that would otherwise have never occurred if you're 
not even using the aliases?  Probably not a big deal but the thought crossed my 
mind.

> Querying against an alias can lead to incorrect routing
> ---
>
> Key: SOLR-11292
> URL: https://issues.apache.org/jira/browse/SOLR-11292
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>
> collection1 has 2 shards and 1 replica
> collection2 has 8 shards and 1 replica
> I have 8 nodes so collection2 is spread across all 8 , while collection1 is 
> hosted by two nodes
> If we create an alias called "collection1" and point it to "collection2".
> Querying against the alias "collection1" works as expected but what I noticed 
> was the top level queries would only hit 2 out of the 8 JVMs when querying 
> using SolrJ
> It turns out that SolrJ is using the state.json of collection1 ( the actual 
> collection ) and routing queries to only those nodes.
> There are two negatives to this:
>  - If those two nodes are down all queries fail.
>  - Top level queries are only routed to those two nodes thus causing a skew 
> in the top level requests
> The obvious solution would be to use the state.json file of the underlying 
> collection that the alias is pointing to  . But if we have the alias pointing 
> to multiple collections then this might get tricky?



--
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] (PYLUCENE-38) JCC build error under recents versions of clang.

2017-10-17 Thread Andi Vajda (JIRA)

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

Andi Vajda resolved PYLUCENE-38.

Resolution: Fixed

This is fixed in rev 1812455

> JCC build error under recents versions of clang.
> 
>
> Key: PYLUCENE-38
> URL: https://issues.apache.org/jira/browse/PYLUCENE-38
> Project: PyLucene
>  Issue Type: Bug
> Environment: macOS
>Reporter: A. Coady
>
> {code:none}
> jcc3/sources/JArray.cpp:315:66: error: ordered comparison between pointer and 
> zero ('PyObject *' (aka '_object *') and 'int')
> PyList_Type.tp_as_sequence->sq_inplace_concat(list, arg) < 0)
>  ^ ~
> jcc3/sources/JArray.cpp:330:64: error: ordered comparison between pointer and 
> zero ('PyObject *' (aka '_object *') and 'int')
> PyList_Type.tp_as_sequence->sq_inplace_repeat(list, n) < 0)
> ~~ ^ ~
> {code}
> Comparisons between NULL and integers have been elevated from a warning to an 
> error in recent versions of clang.  And presumably the error handling wasn't 
> working anyway.



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


[jira] [Commented] (SOLR-11490) Add @since javadoc tags to the interesting Solr/Lucene classes

2017-10-17 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11490:


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

SOLR-11490: Add missing @since tags
To all descendants of UpdateRequestProcessorFactory

(cherry picked from commit 17d340055f7a799a0a686ea6d578fdd325625aaf)


> Add @since javadoc tags to the interesting Solr/Lucene classes
> --
>
> Key: SOLR-11490
> URL: https://issues.apache.org/jira/browse/SOLR-11490
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
>
> As per the discussion on the dev list, it may be useful to add Javadoc since 
> tags to significant (or even all) Java files.
> For user-facing files (such as analyzers, URPs, stream evaluators, etc) it 
> would be useful when trying to identifying whether a particular class only 
> comes later than user's particular version.
> For other classes, it may be useful for historical reasons.



--
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-11490) Add @since javadoc tags to the interesting Solr/Lucene classes

2017-10-17 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11490:


Commit 17d340055f7a799a0a686ea6d578fdd325625aaf in lucene-solr's branch 
refs/heads/master from [~arafalov]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=17d3400 ]

SOLR-11490: Add missing @since tags
To all descendants of UpdateRequestProcessorFactory


> Add @since javadoc tags to the interesting Solr/Lucene classes
> --
>
> Key: SOLR-11490
> URL: https://issues.apache.org/jira/browse/SOLR-11490
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
>
> As per the discussion on the dev list, it may be useful to add Javadoc since 
> tags to significant (or even all) Java files.
> For user-facing files (such as analyzers, URPs, stream evaluators, etc) it 
> would be useful when trying to identifying whether a particular class only 
> comes later than user's particular version.
> For other classes, it may be useful for historical reasons.



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

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



[JENKINS] Lucene-Solr-SmokeRelease-5.5 - Build # 15 - Failure

2017-10-17 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.5/15/

No tests ran.

Build Log:
[...truncated 39728 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.03 sec (7.3 MB/sec)
   [smoker]   check changes HTML...
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/dev-tools/scripts/smokeTestRelease.py",
 line 1487, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/dev-tools/scripts/smokeTestRelease.py",
 line 1431, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/dev-tools/scripts/smokeTestRelease.py",
 line 1466, in smokeTest
   [smoker] checkSigs('lucene', lucenePath, version, tmpDir, isSigned)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/dev-tools/scripts/smokeTestRelease.py",
 line 362, in checkSigs
   [smoker] testChanges(project, version, changesURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/dev-tools/scripts/smokeTestRelease.py",
 line 410, in testChanges
   [smoker] checkChangesContent(s, version, changesURL, project, True)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/dev-tools/scripts/smokeTestRelease.py",
 line 467, in checkChangesContent
   [smoker] raise RuntimeError('Future release %s is greater than %s in %s' 
% (release, version, name))
   [smoker] RuntimeError: Future release 5.5.5 is greater than 5.5.4 in 
file:///x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/lucene/changes/Changes.html

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/build.xml:545: 
exec returned: 1

Total time: 26 minutes 13 seconds
Build step 'Invoke Ant' marked build as failure
Setting JDK_1_8_LATEST__HOME=/home/jenkins/tools/java/latest1.8
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting JDK_1_8_LATEST__HOME=/home/jenkins/tools/java/latest1.8
Setting JDK_1_8_LATEST__HOME=/home/jenkins/tools/java/latest1.8

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

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 868 - Still Failing

2017-10-17 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/868/

No tests ran.

Build Log:
[...truncated 28007 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.03 sec (8.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 29.7 MB in 0.21 sec (140.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 69.5 MB in 0.18 sec (391.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 79.8 MB in 0.19 sec (414.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6184 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6184 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   6.6.2
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1484, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1428, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1466, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, gitRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 622, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
gitRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 774, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1404, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/build.xml:622:
 exec returned: 1

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

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

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

2017-10-17 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1479/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestPullReplica.testKillLeader

Error Message:
Replica state not updated in cluster state null Live Nodes: 
[127.0.0.1:43061_solr, 127.0.0.1:53029_solr] Last available state: 
DocCollection(pull_replica_test_kill_leader//collections/pull_replica_test_kill_leader/state.json/6)={
   "pullReplicas":"1",   "replicationFactor":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node3":{   
"core":"pull_replica_test_kill_leader_shard1_replica_n1",   
"base_url":"https://127.0.0.1:43061/solr;,   
"node_name":"127.0.0.1:43061_solr",   "state":"down",   
"type":"NRT",   "leader":"true"}, "core_node4":{   
"core":"pull_replica_test_kill_leader_shard1_replica_p2",   
"base_url":"https://127.0.0.1:53029/solr;,   
"node_name":"127.0.0.1:53029_solr",   "state":"active",   
"type":"PULL",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"100",   "autoAddReplicas":"false",   "nrtReplicas":"1",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Replica state not updated in cluster state
null
Live Nodes: [127.0.0.1:43061_solr, 127.0.0.1:53029_solr]
Last available state: 
DocCollection(pull_replica_test_kill_leader//collections/pull_replica_test_kill_leader/state.json/6)={
  "pullReplicas":"1",
  "replicationFactor":"1",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"pull_replica_test_kill_leader_shard1_replica_n1",
  "base_url":"https://127.0.0.1:43061/solr;,
  "node_name":"127.0.0.1:43061_solr",
  "state":"down",
  "type":"NRT",
  "leader":"true"},
"core_node4":{
  "core":"pull_replica_test_kill_leader_shard1_replica_p2",
  "base_url":"https://127.0.0.1:53029/solr;,
  "node_name":"127.0.0.1:53029_solr",
  "state":"active",
  "type":"PULL",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"100",
  "autoAddReplicas":"false",
  "nrtReplicas":"1",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([260DF38936F5233A:6F1B073D544EB76C]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.TestPullReplica.doTestNoLeader(TestPullReplica.java:401)
at 
org.apache.solr.cloud.TestPullReplica.testKillLeader(TestPullReplica.java:290)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 

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

2017-10-17 Thread Steve Rowe (JIRA)

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

Steve Rowe resolved SOLR-10335.
---
Fix Version/s: 5.5.5

branch_5_5 commit: 
http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/a83a3197

> 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
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: 5.5.5, 6.6.2, 7.1
>
>
> 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



[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_144) - Build # 20689 - Still Unstable!

2017-10-17 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20689/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseG1GC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 1) 
Thread[id=21836, name=jetty-launcher-3667-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)   
 2) Thread[id=21840, name=jetty-launcher-3667-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 
   1) Thread[id=21836, name=jetty-launcher-3667-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

[jira] [Commented] (SOLR-8981) Upgrade to Tika 1.13 when it is available

2017-10-17 Thread ASF subversion and git services (JIRA)

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

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

Commit 2e5f7d14f62aae94dc117b39d78a731344a016dc in lucene-solr's branch 
refs/heads/branch_5_5 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2e5f7d1 ]

SOLR-8981: branch_5_5: CHANGES.txt: Tika 1.7-1.13


> Upgrade to Tika 1.13 when it is available
> -
>
> Key: SOLR-8981
> URL: https://issues.apache.org/jira/browse/SOLR-8981
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: Tim Allison
>Assignee: Uwe Schindler
> Fix For: 5.5.5, 6.2, 7.0
>
>
> Tika 1.13 should be out within a month.  This includes PDFBox 2.0.0 and a 
> number of other upgrades and improvements.  
> If there are any showstoppers in 1.13 from Solr's side or requests before we 
> roll 1.13, let us know.



--
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-8981) Upgrade to Tika 1.13 when it is available

2017-10-17 Thread ASF subversion and git services (JIRA)

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

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

Commit 2e97142c9161962cb1ba3e6ad6fa8a6f4faf85cf in lucene-solr's branch 
refs/heads/branch_5_5 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2e97142 ]

SOLR-8981: branch_5_5: fix bad CHANGES.txt merge


> Upgrade to Tika 1.13 when it is available
> -
>
> Key: SOLR-8981
> URL: https://issues.apache.org/jira/browse/SOLR-8981
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: Tim Allison
>Assignee: Uwe Schindler
> Fix For: 5.5.5, 6.2, 7.0
>
>
> Tika 1.13 should be out within a month.  This includes PDFBox 2.0.0 and a 
> number of other upgrades and improvements.  
> If there are any showstoppers in 1.13 from Solr's side or requests before we 
> roll 1.13, let us know.



--
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.16 when available

2017-10-17 Thread Steve Rowe (JIRA)

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

Steve Rowe commented on SOLR-10335:
---

Reopening to backport to branch_5_5.

> 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
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: 7.1, 6.6.2
>
>
> 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] [Resolved] (SOLR-8981) Upgrade to Tika 1.13 when it is available

2017-10-17 Thread Steve Rowe (JIRA)

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

Steve Rowe resolved SOLR-8981.
--
Fix Version/s: 5.5.5

> Upgrade to Tika 1.13 when it is available
> -
>
> Key: SOLR-8981
> URL: https://issues.apache.org/jira/browse/SOLR-8981
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: Tim Allison
>Assignee: Uwe Schindler
> Fix For: 5.5.5, 7.0, 6.2
>
>
> Tika 1.13 should be out within a month.  This includes PDFBox 2.0.0 and a 
> number of other upgrades and improvements.  
> If there are any showstoppers in 1.13 from Solr's side or requests before we 
> roll 1.13, let us know.



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

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



[JENKINS] Lucene-Solr-SmokeRelease-6.6 - Build # 30 - Still Failing

2017-10-17 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.6/30/

No tests ran.

Build Log:
[...truncated 25891 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.02 sec (11.2 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.6.2-src.tgz...
   [smoker] 29.7 MB in 0.09 sec (315.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.6.2.tgz...
   [smoker] 67.7 MB in 0.28 sec (243.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.6.2.zip...
   [smoker] 78.1 MB in 0.27 sec (286.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.6.2.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6252 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.6.2.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6252 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.6.2-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 229 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker]   Backcompat testing not required for release 7.0.0 because 
it's not less than 6.6.2
   [smoker]   Backcompat testing not required for release 7.0.1 because 
it's not less than 6.6.2
   [smoker]   Backcompat testing not required for release 7.1.0 because 
it's not less than 6.6.2
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.02 sec (13.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.6.2-src.tgz...
   [smoker] 50.5 MB in 0.75 sec (67.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.6.2.tgz...
   [smoker] 140.5 MB in 1.93 sec (72.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.6.2.zip...
   [smoker] 141.6 MB in 2.00 sec (70.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.6.2.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.6.2.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.2/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.2/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.2-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.2-java8
   [smoker] Creating Solr home directory 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.2-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using 

[jira] [Commented] (SOLR-8981) Upgrade to Tika 1.13 when it is available

2017-10-17 Thread ASF subversion and git services (JIRA)

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

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

Commit 10fb52a64b4fa5ff999421912217d5c717fce12b in lucene-solr's branch 
refs/heads/branch_5_5 from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=10fb52a ]

SOLR-8981: Update TIKA to 1.13:
- This commit merges branch 'SOLR-8981' of 
https://github.com/tballison/lucene-solr
- Adds some modifications and reverts jackcess-encrypt addition (not yet 
working)
- Fixes order of ivy-versions.properties
- This closes #44


> Upgrade to Tika 1.13 when it is available
> -
>
> Key: SOLR-8981
> URL: https://issues.apache.org/jira/browse/SOLR-8981
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: Tim Allison
>Assignee: Uwe Schindler
> Fix For: 6.2, 7.0
>
>
> Tika 1.13 should be out within a month.  This includes PDFBox 2.0.0 and a 
> number of other upgrades and improvements.  
> If there are any showstoppers in 1.13 from Solr's side or requests before we 
> roll 1.13, let us know.



--
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-8981) Upgrade to Tika 1.13 when it is available

2017-10-17 Thread ASF subversion and git services (JIRA)

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

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

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

SOLR-8981: Add notice for jackcess


> Upgrade to Tika 1.13 when it is available
> -
>
> Key: SOLR-8981
> URL: https://issues.apache.org/jira/browse/SOLR-8981
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: Tim Allison
>Assignee: Uwe Schindler
> Fix For: 6.2, 7.0
>
>
> Tika 1.13 should be out within a month.  This includes PDFBox 2.0.0 and a 
> number of other upgrades and improvements.  
> If there are any showstoppers in 1.13 from Solr's side or requests before we 
> roll 1.13, let us know.



--
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-8981) Upgrade to Tika 1.13 when it is available

2017-10-17 Thread ASF subversion and git services (JIRA)

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

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

Commit 10fb52a64b4fa5ff999421912217d5c717fce12b in lucene-solr's branch 
refs/heads/branch_5_5 from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=10fb52a ]

SOLR-8981: Update TIKA to 1.13:
- This commit merges branch 'SOLR-8981' of 
https://github.com/tballison/lucene-solr
- Adds some modifications and reverts jackcess-encrypt addition (not yet 
working)
- Fixes order of ivy-versions.properties
- This closes #44


> Upgrade to Tika 1.13 when it is available
> -
>
> Key: SOLR-8981
> URL: https://issues.apache.org/jira/browse/SOLR-8981
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: Tim Allison
>Assignee: Uwe Schindler
> Fix For: 6.2, 7.0
>
>
> Tika 1.13 should be out within a month.  This includes PDFBox 2.0.0 and a 
> number of other upgrades and improvements.  
> If there are any showstoppers in 1.13 from Solr's side or requests before we 
> roll 1.13, let us know.



--
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-11504) Provide a config to restrict number of indexing threads

2017-10-17 Thread Nawab Zada Asad iqbal (JIRA)
Nawab Zada Asad iqbal created SOLR-11504:


 Summary: Provide a config to restrict number of indexing threads 
 Key: SOLR-11504
 URL: https://issues.apache.org/jira/browse/SOLR-11504
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.0, 6.0, 5.3
Reporter: Nawab Zada Asad iqbal


For heavy indexing load (through REST api), Solr does not have any way to 
restrict number of threads. There used to be a config in lucene to restrict 
number of threads but that has been removed since 
https://issues.apache.org/jira/browse/LUCENE-6659 . 

For example, in my bulk indexing scenario, within few minutes, my solr server 
had created 300 parallel threads each writing its own segment. The result was 
tons of small segments getting flushed to disk (as total RAM limit was reached 
quickly by sum of all segments), and solr has to spend time later to merge them 
into reasonable sizes. 




--
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-8981) Upgrade to Tika 1.13 when it is available

2017-10-17 Thread Steve Rowe (JIRA)

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

Steve Rowe commented on SOLR-8981:
--

Reopening to backport to branch_5_5.

> Upgrade to Tika 1.13 when it is available
> -
>
> Key: SOLR-8981
> URL: https://issues.apache.org/jira/browse/SOLR-8981
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: Tim Allison
>Assignee: Uwe Schindler
> Fix For: 6.2, 7.0
>
>
> Tika 1.13 should be out within a month.  This includes PDFBox 2.0.0 and a 
> number of other upgrades and improvements.  
> If there are any showstoppers in 1.13 from Solr's side or requests before we 
> roll 1.13, let us know.



--
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-5.5-Windows (64bit/jdk1.7.0_80) - Build # 142 - Still Unstable!

2017-10-17 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Windows/142/
Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:58652/solr/testschemaapi_shard1_replica2: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:58652/solr/testschemaapi_shard1_replica2: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([F11325FA37F072DD:79471A20990C1F25]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:653)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1002)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:891)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:827)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:101)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[JENKINS] Lucene-Solr-5.5-Linux (32bit/jdk1.8.0_144) - Build # 472 - Still Unstable!

2017-10-17 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/472/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs.testDMQ8

Error Message:
(+((field:yy field:w5^100.0) | field:xx^10.0)~0.5 -extra:extra) 
NEVER:MATCH: score(doc=889)=-1.9892984E-6 != explanationScore=-3.978597E-6 
Explanation: -3.978597E-6 = sum of:   -3.978597E-6 = weight(field:w5 in 889) 
[RandomSimilarity], result of: -3.978597E-6 = score(IBSimilarity, doc=889, 
freq=1.0), computed from:   100.0 = boost   9.7103113E-20 = 
NormalizationH1, computed from:  1.0 = tf 5.485661 = 
avgFieldLength 5.6493154E19 = len   0.25093386 = LambdaTTF, 
computed from:  2283.0 = totalTermFreq 9101.0 = 
numberOfDocuments   -3.978597E-8 = DistributionSPL  
expected:<-1.9892984E-6> but was:<-3.978597E-6>

Stack Trace:
junit.framework.AssertionFailedError: (+((field:yy field:w5^100.0) | 
field:xx^10.0)~0.5 -extra:extra) NEVER:MATCH: score(doc=889)=-1.9892984E-6 
!= explanationScore=-3.978597E-6 Explanation: -3.978597E-6 = sum of:
  -3.978597E-6 = weight(field:w5 in 889) [RandomSimilarity], result of:
-3.978597E-6 = score(IBSimilarity, doc=889, freq=1.0), computed from:
  100.0 = boost
  9.7103113E-20 = NormalizationH1, computed from: 
1.0 = tf
5.485661 = avgFieldLength
5.6493154E19 = len
  0.25093386 = LambdaTTF, computed from: 
2283.0 = totalTermFreq
9101.0 = numberOfDocuments
  -3.978597E-8 = DistributionSPL
 expected:<-1.9892984E-6> but was:<-3.978597E-6>
at 
__randomizedtesting.SeedInfo.seed([5019C8765FC8234B:C232223485C]:0)
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.failNotEquals(Assert.java:287)
at junit.framework.Assert.assertEquals(Assert.java:120)
at 
org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:338)
at 
org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:354)
at 
org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:354)
at 
org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:354)
at 
org.apache.lucene.search.CheckHits$ExplanationAsserter.collect(CheckHits.java:498)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
at 
org.apache.lucene.search.AssertingCollector$1.collect(AssertingCollector.java:56)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreRange(Weight.java:196)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:183)
at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:79)
at 
org.apache.lucene.search.ReqExclBulkScorer.score(ReqExclBulkScorer.java:48)
at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:79)
at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:63)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:821)
at 
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:91)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:535)
at 
org.apache.lucene.search.CheckHits.checkExplanations(CheckHits.java:310)
at 
org.apache.lucene.search.QueryUtils.checkExplanations(QueryUtils.java:120)
at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:148)
at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:144)
at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:134)
at 
org.apache.lucene.search.CheckHits.checkHitCollector(CheckHits.java:98)
at 
org.apache.lucene.search.BaseExplanationTestCase.qtest(BaseExplanationTestCase.java:114)
at 
org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs.qtest(TestSimpleExplanationsWithFillerDocs.java:113)
at 
org.apache.lucene.search.TestSimpleExplanations.testDMQ8(TestSimpleExplanations.java:212)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 

[jira] [Commented] (LUCENE-7997) More sanity testing of similarities

2017-10-17 Thread Robert Muir (JIRA)

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

Robert Muir commented on LUCENE-7997:
-

Exactly we need a picky base sim test for this (like how 
BaseTokenStreamTestCase checks various requirements for analyzers). Currently 
these properties are "scattered" across various parts of the code/tests/issues: 
such as scores not being inf/NaN for some collectors, not being negative, 
monotonic tf, etc that maxscore requires. Sims that use certain statistics 
should fallback to other things when term frequencies are omitted, etc. It 
would be better to ensure we test all sims for all these things with direct 
tests. We should also try to test all norm values explicitly so that there 
aren't problems with super large documents and so on.



> More sanity testing of similarities
> ---
>
> Key: LUCENE-7997
> URL: https://issues.apache.org/jira/browse/LUCENE-7997
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
>
> LUCENE-7993 is a potential optimization that we could only apply if the 
> similarity is an increasing functions of {{freq}} (all other things like DF 
> and length being equal). This sounds like a very reasonable requirement for a 
> similarity, so we should test it in the base similarity test case and maybe 
> move broken similarities to sandbox?



--
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-7996) Should we require positive scores?

2017-10-17 Thread Robert Muir (JIRA)

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

Robert Muir commented on LUCENE-7996:
-

+1 we try to fix similarities that produce negative scores because it hurts 
relevance, too. Classic example is an unmodified bm25 IDF, goes negative for 
stopword-like terms.

In some cases formulas can not so easily be "hacked" to avoid these problems, 
it results in a less robust ranking algorithm. For example in the case above, 
if someone's stopword list isn't perfect for their collection, then queries 
will suffer.

Currently the problematic algorithms just have big javadocs warnings. But I 
think its ok to look at putting them in the sandbox or deprecatinoulg or 
removing like that instead. 

At the end of the day, we should at least add better tests, so we know about 
the problems. Thats step 1 I think. I have some ideas.


> Should we require positive scores?
> --
>
> Key: LUCENE-7996
> URL: https://issues.apache.org/jira/browse/LUCENE-7996
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
>
> Having worked on MAXSCORE recently, things would be simpler if we required 
> that scores are positive. Practically, this would mean 
>  - forbidding/fixing similarities that may produce negative scores (we have 
> some of them)
>  - forbidding things like negative boosts
>  - fixing the scoring formula of some queries like {{BoostingQuery}} (which 
> subtracts a score to another score) so that the end result may never be 
> negative
> So I'd be curious to have opinions whether this would be a sane requirement 
> or whether we need to be able to cope with negative scores eg. because some 
> similarities that we want to support produce negative scores by design.



--
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-7993) Speed up phrase queries when total hit count is not needed

2017-10-17 Thread Adrien Grand (JIRA)

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

Adrien Grand commented on LUCENE-7993:
--

Thanks for looking! I opened LUCENE-7997.

> Speed up phrase queries when total hit count is not needed
> --
>
> Key: LUCENE-7993
> URL: https://issues.apache.org/jira/browse/LUCENE-7993
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7993.patch
>
>
> Follow-up of LUCENE-4100: When thinking about the API that we needed to 
> introduce to support MAXSCORE, I wondered whether the same API could support 
> other optimizations. The idea is that when running phrase queries, before we 
> start reading positions, we already have access to the term frequency of each 
> term. And the frequency of the phrase is bounded by the minimum term 
> frequency of the involved terms. So if the score for that minimum term 
> frequency is not competitive then it means that the score for the phrase is 
> not competitive either if we can assume that the score increases (or 
> stagnates) when the term freq increases, which sounds like an ok requirement 
> for a sane Similarity?



--
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-7997) More sanity testing of similarities

2017-10-17 Thread Adrien Grand (JIRA)
Adrien Grand created LUCENE-7997:


 Summary: More sanity testing of similarities
 Key: LUCENE-7997
 URL: https://issues.apache.org/jira/browse/LUCENE-7997
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Priority: Minor


LUCENE-7993 is a potential optimization that we could only apply if the 
similarity is an increasing functions of {{freq}} (all other things like DF and 
length being equal). This sounds like a very reasonable requirement for a 
similarity, so we should test it in the base similarity test case and maybe 
move broken similarities to sandbox?



--
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-7996) Should we require positive scores?

2017-10-17 Thread Adrien Grand (JIRA)
Adrien Grand created LUCENE-7996:


 Summary: Should we require positive scores?
 Key: LUCENE-7996
 URL: https://issues.apache.org/jira/browse/LUCENE-7996
 Project: Lucene - Core
  Issue Type: Wish
Reporter: Adrien Grand
Priority: Minor


Having worked on MAXSCORE recently, things would be simpler if we required that 
scores are positive. Practically, this would mean 
 - forbidding/fixing similarities that may produce negative scores (we have 
some of them)
 - forbidding things like negative boosts
 - fixing the scoring formula of some queries like {{BoostingQuery}} (which 
subtracts a score to another score) so that the end result may never be negative

So I'd be curious to have opinions whether this would be a sane requirement or 
whether we need to be able to cope with negative scores eg. because some 
similarities that we want to support produce negative scores by design.



--
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-6.6-Linux (64bit/jdk-9) - Build # 173 - Still Unstable!

2017-10-17 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Linux/173/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseG1GC --illegal-access=deny

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

Error Message:
Timed out waiting for Mini HDFS Cluster to start

Stack Trace:
java.io.IOException: Timed out waiting for Mini HDFS Cluster to start
at __randomizedtesting.SeedInfo.seed([51C79D8A387796F4]:0)
at 
org.apache.hadoop.hdfs.MiniDFSCluster.waitClusterUp(MiniDFSCluster.java:1207)
at 
org.apache.hadoop.hdfs.MiniDFSCluster.initMiniDFSCluster(MiniDFSCluster.java:840)
at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:746)
at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:616)
at 
org.apache.solr.cloud.hdfs.HdfsTestUtil.setupClass(HdfsTestUtil.java:104)
at 
org.apache.solr.cloud.hdfs.HdfsTestUtil.setupClass(HdfsTestUtil.java:63)
at 
org.apache.solr.cloud.TestHdfsCloudBackupRestore.setupClass(TestHdfsCloudBackupRestore.java:100)
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$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 
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.cloud.hdfs.HdfsRecoverLeaseTest

Error Message:
Timed out waiting for Mini HDFS Cluster to start

Stack Trace:
java.io.IOException: Timed out waiting for Mini HDFS Cluster to start
at __randomizedtesting.SeedInfo.seed([51C79D8A387796F4]:0)
at 
org.apache.hadoop.hdfs.MiniDFSCluster.waitClusterUp(MiniDFSCluster.java:1207)
at 
org.apache.hadoop.hdfs.MiniDFSCluster.initMiniDFSCluster(MiniDFSCluster.java:840)
at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:746)
at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:616)
at 
org.apache.solr.cloud.hdfs.HdfsTestUtil.setupClass(HdfsTestUtil.java:104)
at 
org.apache.solr.cloud.hdfs.HdfsTestUtil.setupClass(HdfsTestUtil.java:67)
at 
org.apache.solr.cloud.hdfs.HdfsRecoverLeaseTest.beforeClass(HdfsRecoverLeaseTest.java:50)
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 

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

2017-10-17 Thread Hoss Man (JIRA)

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

Hoss Man resolved SOLR-11053.
-
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.2

> 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
>Assignee: Hoss Man
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11053.patch
>
>
> 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] [Comment Edited] (SOLR-11267) Add support for "add-distinct" atomic update operation

2017-10-17 Thread Amrit Sarkar (JIRA)

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

Amrit Sarkar edited comment on SOLR-11267 at 10/17/17 9:42 PM:
---

[~ichattopadhyaya],

I cooked up a little patch to support "add-distinct". I also believe this will 
be a very wealthy addition in atomic requests as users have to parse the SET 
from the list on their application code today.

Design: if field not present, do conventional "add" atomic operation or else:
  if passed values are list, check each value present already and 
then add
  else if singular, check value present already and then add

Included small test to verify that. Looking forward to your review and feedback.


was (Author: sarkaramr...@gmail.com):
[~ichattopadhyaya],

I cooked up a little patch to support "add-distinct". I also believe this will 
be a very wealthy addition in atomic requests as users have to parse the SET 
from the list on their application code today.

Design: if field not present, do conventional "add" atomic operation or else:
  if passed values are list, check each value present already and 
then add
  else if singular, check each value present already and then add

Included small test to verify that. Looking forward to your review and feedback.

> Add support for "add-distinct" atomic update operation
> --
>
> Key: SOLR-11267
> URL: https://issues.apache.org/jira/browse/SOLR-11267
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-11267.patch, SOLR-11267.patch
>
>
> Often, a multivalued field is used as a set of values. Since multivalued 
> fields are more like lists than sets, users do two consecutive operations, 
> remove and add, to insert an element into the field and also maintain the 
> set's property of only having unique elements.
> Proposing a new single operation, called "add-distinct" (which essentially 
> means "add-if-doesn't exist") for this.



--
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-11292) Querying against an alias can lead to incorrect routing

2017-10-17 Thread Varun Thacker (JIRA)

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

Varun Thacker commented on SOLR-11292:
--

I think the logic *only* fails when we have a collection name and alias with 
the same name

{code}
  private LinkedHashSet resolveAliasesAndValidateExistence(List 
inputCollections) {
LinkedHashSet collectionNames = new LinkedHashSet<>(); // 
consistent ordering
// validate collections
for (String collectionName : inputCollections) {
  if (stateProvider.getState(collectionName) == null) {
// perhaps it's an alias
List aliasedCollections = 
stateProvider.getAlias(collectionName);
if (aliasedCollections.isEmpty()) {
  throw new SolrException(ErrorCode.BAD_REQUEST, "Collection not found: 
" + collectionName);
}
collectionNames.addAll(aliasedCollections);
  } else {
collectionNames.add(collectionName);
  }
}
return collectionNames;
  }
{code}

We are first checking if the collection exists. If the collection doesn't exist 
only then do we resolve it as an alias.

Maybe we should always resolve it as an alias first?

> Querying against an alias can lead to incorrect routing
> ---
>
> Key: SOLR-11292
> URL: https://issues.apache.org/jira/browse/SOLR-11292
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>
> collection1 has 2 shards and 1 replica
> collection2 has 8 shards and 1 replica
> I have 8 nodes so collection2 is spread across all 8 , while collection1 is 
> hosted by two nodes
> If we create an alias called "collection1" and point it to "collection2".
> Querying against the alias "collection1" works as expected but what I noticed 
> was the top level queries would only hit 2 out of the 8 JVMs when querying 
> using SolrJ
> It turns out that SolrJ is using the state.json of collection1 ( the actual 
> collection ) and routing queries to only those nodes.
> There are two negatives to this:
>  - If those two nodes are down all queries fail.
>  - Top level queries are only routed to those two nodes thus causing a skew 
> in the top level requests
> The obvious solution would be to use the state.json file of the underlying 
> collection that the alias is pointing to  . But if we have the alias pointing 
> to multiple collections then this might get tricky?



--
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] (PYLUCENE-38) JCC build error under recents versions of clang.

2017-10-17 Thread A. Coady (JIRA)
A. Coady created PYLUCENE-38:


 Summary: JCC build error under recents versions of clang.
 Key: PYLUCENE-38
 URL: https://issues.apache.org/jira/browse/PYLUCENE-38
 Project: PyLucene
  Issue Type: Bug
 Environment: macOS
Reporter: A. Coady


{code:none}
jcc3/sources/JArray.cpp:315:66: error: ordered comparison between pointer and 
zero ('PyObject *' (aka '_object *') and 'int')
PyList_Type.tp_as_sequence->sq_inplace_concat(list, arg) < 0)
 ^ ~
jcc3/sources/JArray.cpp:330:64: error: ordered comparison between pointer and 
zero ('PyObject *' (aka '_object *') and 'int')
PyList_Type.tp_as_sequence->sq_inplace_repeat(list, n) < 0)
~~ ^ ~
{code}

Comparisons between NULL and integers have been elevated from a warning to an 
error in recent versions of clang.  And presumably the error handling wasn't 
working anyway.



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


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

2017-10-17 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11053:


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

SOLR-11053: remove AutoCommitTest + HardAutoCommitTest now that 
SoftAutoCommitTest exercises all the same functionality with more robust 
assertions


> 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
>Assignee: Hoss Man
> Attachments: SOLR-11053.patch
>
>
> 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-11053) Improve SoftAutoCommitTest to the point that we can delete AutoCommitTest and HardAutoCommitTest

2017-10-17 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11053:


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

SOLR-11053: remove AutoCommitTest + HardAutoCommitTest now that 
SoftAutoCommitTest exercises all the same functionality with more robust 
assertions

(cherry picked from commit 2da777cdb89c45a69081452ec4efb3e6b61108b6)


> 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
>Assignee: Hoss Man
> Attachments: SOLR-11053.patch
>
>
> 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-6312) CloudSolrServer doesn't honor updatesToLeaders constructor argument

2017-10-17 Thread Jeff Wartes (JIRA)

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

Jeff Wartes commented on SOLR-6312:
---

As of 7.0.1, three years later, yes, I think it is still an open issue.
CloudSolrServer.Builder has two functions that have no effect: 
sendUpdatesOnlyToShardLeaders and sendUpdatesToAllReplicasInShard. They are not 
marked depreciated, and the javadoc implies functionality.


> CloudSolrServer doesn't honor updatesToLeaders constructor argument
> ---
>
> Key: SOLR-6312
> URL: https://issues.apache.org/jira/browse/SOLR-6312
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.9
>Reporter: Steve Davids
> Fix For: 4.10
>
> Attachments: SOLR-6312.patch
>
>
> The CloudSolrServer doesn't use the updatesToLeaders property - all SolrJ 
> requests are being sent to the shard leaders.



--
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-11444) Improve Aliases.java and comma delimited collection list handling

2017-10-17 Thread David Smiley (JIRA)

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

David Smiley updated SOLR-11444:

Attachment: SOLR-11444.patch

Updated patch.  I think it's ready.

* double-resolve of an alias.  This used to not be supported by JoinQParser nor 
streaming expressions but now it works since I put this logic in Aliases.java 
where it can be shared.  I added some TODOs about this feature being dubious.
* ClusterStateProvider: getAlias -> resolveAlias and changed semantics to 
return input if not an alias.  The extra alias indirection happens here (new).
* Aliases.java: decided to remove a convenience method I added in the last 
patch.  And changed one of the newer methods I added to be resolveAlias with 
same semantics as the one in ClusterStateProvider.
* SolrTestCaseJ4: new getCloudSolrClient(MiniSolrCloudCluster cluster) to 
randomly pick a cluster state provider based on either ZK or HTTP.  FYI 
[~ichattopadhyaya].  Perhaps MSCC.getClient's impl should random().usually() do 
what it does now (it's probably fastest) and otherwise use the HTTP provider 
one (perhaps slower?)?

note: some streaming expressions code here and CloudSolrClient's http cluster 
state provider are coded in such a way that will probably be wrong or break if 
aliases and collections have the same name.  This is an observation I see, not 
a change induced by this patch. 

> Improve Aliases.java and comma delimited collection list handling
> -
>
> Key: SOLR-11444
> URL: https://issues.apache.org/jira/browse/SOLR-11444
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR-11444.patch, SOLR-11444.patch, 
> SOLR_11444_Aliases.patch, SOLR_11444_Aliases.patch
>
>
> While starting to look at SOLR-11299 I noticed some brittleness in 
> assumptions about Strings that refer to a collection.  Sometimes they are in 
> fact references to comma separated lists, which appears was added with the 
> introduction of collection aliases (an alias can refer to a comma delimited 
> list).  So Java's type system kind of goes out the window when we do this.  
> In one case this leads to a bug -- CloudSolrClient will throw an NPE if you 
> try to write to such an alias.  Sending an update via HTTP will allow it and 
> send it to the first in the list.
> So this issue is about refactoring and some little improvements pertaining to 
> Aliases.java plus certain key spots that deal with collection references.  I 
> don't think I want to go as far as changing the public SolrJ API except to 
> adding documentation on what's possible.



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



[GitHub] lucene-solr pull request #263: Backporting of SOLR-11477 on branch_5_5

2017-10-17 Thread Sanne
Github user Sanne closed the pull request at:

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


---

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



[GitHub] lucene-solr issue #263: Backporting of SOLR-11477 on branch_5_5

2017-10-17 Thread Sanne
Github user Sanne commented on the issue:

https://github.com/apache/lucene-solr/pull/263
  
Thanks @sarowe ! closing


---

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



[jira] [Commented] (SOLR-3419) XSS vulnerability in the json.wrf parameter

2017-10-17 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on SOLR-3419:
-

This version of Solr is out of maintenance. So there won't be any update. Later 
versions have a totally different Web UI.

> XSS vulnerability in the json.wrf parameter
> ---
>
> Key: SOLR-3419
> URL: https://issues.apache.org/jira/browse/SOLR-3419
> Project: Solr
>  Issue Type: Bug
>  Components: Response Writers
>Affects Versions: 3.5
>Reporter: Prafulla Kiran
>Priority: Minor
> Attachments: SOLR-3419-escape.patch, Screen Shot 2017-10-17 at 
> 3.14.43 PM.png
>
>
> There's no filtering of the wrapper function name passed to the solr search 
> service
> If the name of the wrapper function passed to the solr query service is the 
> following string - 
> %3C!doctype%20html%3E%3Chtml%3E%3Cbody%3E%3Cimg%20src=%22x%22%20onerror=%22alert%281%29%22%3E%3C/body%3E%3C/html%3E
> solr passes the string back as-is which results in an XSS attack in browsers 
> like IE-7 which perform mime-sniffing. In any case, the callback function in 
> a jsonp response should always be sanitized - 
> http://stackoverflow.com/questions/2777021/do-i-need-to-sanitize-the-callback-parameter-from-a-jsonp-call



--
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-11292) Querying against an alias can lead to incorrect routing

2017-10-17 Thread Varun Thacker (JIRA)

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

Varun Thacker commented on SOLR-11292:
--

Hi David,

I applied SOLR-1144 and I still don't think it's working

Here is how I tested:

Built solr from master after applying the patch.
Started solr with {{bin/solr start -e cloud -noprompt}}
Created c1 on node 8983
Created c2 on node 7574
Created an alias called c1 - 
{{admin/collections?action=createalias=c1=c2}}

>From my IDE which had the patch applied I tried these two snippets and the 
>results were the same

{code}
CloudSolrClient cloudSolrClient = new 
CloudSolrClient.Builder().withZkHost("localhost:9983").build();

for (int i=0; i<10; i++) {
  ModifiableSolrParams params = new ModifiableSolrParams();
  params.add("q", "*:*");
  cloudSolrClient.query("c1", params);
}
cloudSolrClient.close();
{code}

{code}
CloudSolrClient cloudSolrClient = new 
CloudSolrClient.Builder().withZkHost("localhost:9983").build();
cloudSolrClient.setDefaultCollection("c1");

for (int i=0; i<10; i++) {
  ModifiableSolrParams params = new ModifiableSolrParams();
  params.add("q", "*:*");
  cloudSolrClient.query(params);
}
cloudSolrClient.close();
{code}

I only see log entries on node1 8983 which was hosting c1 but the top level 
query should have gone only to node2 in my setup

{code}
INFO  - 2017-10-17 21:10:28.964; [c:c2 s:shard1 r:core_node2 
x:c2_shard1_replica_n1] org.apache.solr.core.SolrCore; [c2_shard1_replica_n1]  
webapp=/solr path=/select params={q=*:*&_stateVer_=c1:4=javabin=2} 
hits=0 status=0 QTime=28
INFO  - 2017-10-17 21:10:28.994; [c:c2 s:shard1 r:core_node2 
x:c2_shard1_replica_n1] org.apache.solr.core.SolrCore; [c2_shard1_replica_n1]  
webapp=/solr path=/select params={q=*:*&_stateVer_=c1:4=javabin=2} 
hits=0 status=0 QTime=0
INFO  - 2017-10-17 21:10:28.996; [c:c2 s:shard1 r:core_node2 
x:c2_shard1_replica_n1] org.apache.solr.core.SolrCore; [c2_shard1_replica_n1]  
webapp=/solr path=/select params={q=*:*&_stateVer_=c1:4=javabin=2} 
hits=0 status=0 QTime=0
INFO  - 2017-10-17 21:10:28.999; [c:c2 s:shard1 r:core_node2 
x:c2_shard1_replica_n1] org.apache.solr.core.SolrCore; [c2_shard1_replica_n1]  
webapp=/solr path=/select params={q=*:*&_stateVer_=c1:4=javabin=2} 
hits=0 status=0 QTime=0
INFO  - 2017-10-17 21:10:29.001; [c:c2 s:shard1 r:core_node2 
x:c2_shard1_replica_n1] org.apache.solr.core.SolrCore; [c2_shard1_replica_n1]  
webapp=/solr path=/select params={q=*:*&_stateVer_=c1:4=javabin=2} 
hits=0 status=0 QTime=0
INFO  - 2017-10-17 21:10:29.005; [c:c2 s:shard1 r:core_node2 
x:c2_shard1_replica_n1] org.apache.solr.core.SolrCore; [c2_shard1_replica_n1]  
webapp=/solr path=/select params={q=*:*&_stateVer_=c1:4=javabin=2} 
hits=0 status=0 QTime=0
INFO  - 2017-10-17 21:10:29.008; [c:c2 s:shard1 r:core_node2 
x:c2_shard1_replica_n1] org.apache.solr.core.SolrCore; [c2_shard1_replica_n1]  
webapp=/solr path=/select params={q=*:*&_stateVer_=c1:4=javabin=2} 
hits=0 status=0 QTime=0
INFO  - 2017-10-17 21:10:29.011; [c:c2 s:shard1 r:core_node2 
x:c2_shard1_replica_n1] org.apache.solr.core.SolrCore; [c2_shard1_replica_n1]  
webapp=/solr path=/select params={q=*:*&_stateVer_=c1:4=javabin=2} 
hits=0 status=0 QTime=0
INFO  - 2017-10-17 21:10:29.013; [c:c2 s:shard1 r:core_node2 
x:c2_shard1_replica_n1] org.apache.solr.core.SolrCore; [c2_shard1_replica_n1]  
webapp=/solr path=/select params={q=*:*&_stateVer_=c1:4=javabin=2} 
hits=0 status=0 QTime=0
INFO  - 2017-10-17 21:10:29.015; [c:c2 s:shard1 r:core_node2 
x:c2_shard1_replica_n1] org.apache.solr.core.SolrCore; [c2_shard1_replica_n1]  
webapp=/solr path=/select params={q=*:*&_stateVer_=c1:4=javabin=2} 
hits=0 status=0 QTime=0
{code}

Looking at {{_stateVer_=c1}} in the request params , it looks like we are still 
passing the state of c1 only from the client ?

> Querying against an alias can lead to incorrect routing
> ---
>
> Key: SOLR-11292
> URL: https://issues.apache.org/jira/browse/SOLR-11292
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>
> collection1 has 2 shards and 1 replica
> collection2 has 8 shards and 1 replica
> I have 8 nodes so collection2 is spread across all 8 , while collection1 is 
> hosted by two nodes
> If we create an alias called "collection1" and point it to "collection2".
> Querying against the alias "collection1" works as expected but what I noticed 
> was the top level queries would only hit 2 out of the 8 JVMs when querying 
> using SolrJ
> It turns out that SolrJ is using the state.json of collection1 ( the actual 
> collection ) and routing queries to only those nodes.
> There are two negatives to this:

[jira] [Commented] (SOLR-3419) XSS vulnerability in the json.wrf parameter

2017-10-17 Thread Chris Brockmeier (JIRA)

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

Chris Brockmeier commented on SOLR-3419:


There is a code fragment above (Attached) that possibly identifies a solution 
for this.   Are you going to update the product for this?
I also attached an Accunetix Web Scan to display the issue.  



> XSS vulnerability in the json.wrf parameter
> ---
>
> Key: SOLR-3419
> URL: https://issues.apache.org/jira/browse/SOLR-3419
> Project: Solr
>  Issue Type: Bug
>  Components: Response Writers
>Affects Versions: 3.5
>Reporter: Prafulla Kiran
>Priority: Minor
> Attachments: SOLR-3419-escape.patch, Screen Shot 2017-10-17 at 
> 3.14.43 PM.png
>
>
> There's no filtering of the wrapper function name passed to the solr search 
> service
> If the name of the wrapper function passed to the solr query service is the 
> following string - 
> %3C!doctype%20html%3E%3Chtml%3E%3Cbody%3E%3Cimg%20src=%22x%22%20onerror=%22alert%281%29%22%3E%3C/body%3E%3C/html%3E
> solr passes the string back as-is which results in an XSS attack in browsers 
> like IE-7 which perform mime-sniffing. In any case, the callback function in 
> a jsonp response should always be sanitized - 
> http://stackoverflow.com/questions/2777021/do-i-need-to-sanitize-the-callback-parameter-from-a-jsonp-call



--
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-3419) XSS vulnerability in the json.wrf parameter

2017-10-17 Thread Chris Brockmeier (JIRA)

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

Chris Brockmeier updated SOLR-3419:
---
Attachment: Screen Shot 2017-10-17 at 3.14.43 PM.png

> XSS vulnerability in the json.wrf parameter
> ---
>
> Key: SOLR-3419
> URL: https://issues.apache.org/jira/browse/SOLR-3419
> Project: Solr
>  Issue Type: Bug
>  Components: Response Writers
>Affects Versions: 3.5
>Reporter: Prafulla Kiran
>Priority: Minor
> Attachments: SOLR-3419-escape.patch, Screen Shot 2017-10-17 at 
> 3.14.43 PM.png
>
>
> There's no filtering of the wrapper function name passed to the solr search 
> service
> If the name of the wrapper function passed to the solr query service is the 
> following string - 
> %3C!doctype%20html%3E%3Chtml%3E%3Cbody%3E%3Cimg%20src=%22x%22%20onerror=%22alert%281%29%22%3E%3C/body%3E%3C/html%3E
> solr passes the string back as-is which results in an XSS attack in browsers 
> like IE-7 which perform mime-sniffing. In any case, the callback function in 
> a jsonp response should always be sanitized - 
> http://stackoverflow.com/questions/2777021/do-i-need-to-sanitize-the-callback-parameter-from-a-jsonp-call



--
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: [GitHub] lucene-solr issue #263: Backporting of SOLR-11477 on branch_5_5

2017-10-17 Thread Uwe Schindler
Tganks Steve,

What should we do with the RunExecutableListener? If you like you can backport 
the 6.6 commit which disables it by default. Warning: The 7.x one removed it, 
so not applicable for a bugfix release. See also the corresponding issue.

Uwe

Am 17. Oktober 2017 22:37:18 MESZ schrieb sarowe :
>Github user sarowe commented on the issue:
>
>https://github.com/apache/lucene-solr/pull/263
>  
>Thanks Sanne!  I committed your patch with these changes: 
>
>* The release will be 5.5.5, so I moved the CHANGES.txt entries under
>that release.
>* One of the .java files had some unused imports that I removed.
>
>I tried to close the pull request ("This closes #263" in the commit log
>message), but it didn't seem to work - would you please close this? 
>Thanks.
>
>
>---
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>For additional commands, e-mail: dev-h...@lucene.apache.org

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

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

2017-10-17 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20688/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  
org.apache.solr.cloud.TestCloudSearcherWarming.testRepFactor1LeaderStartup

Error Message:
 null Live Nodes: [127.0.0.1:37591_solr] Last available state: 
DocCollection(testRepFactor1LeaderStartup//collections/testRepFactor1LeaderStartup/state.json/4)={
   "pullReplicas":"0",   "replicationFactor":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   
"replicas":{"core_node2":{   
"core":"testRepFactor1LeaderStartup_shard1_replica_n1",   
"base_url":"http://127.0.0.1:37591/solr;,   
"node_name":"127.0.0.1:37591_solr",   "state":"active",   
"type":"NRT",   "leader":"true",   "router":{"name":"compositeId"}, 
  "maxShardsPerNode":"1",   "autoAddReplicas":"false",   "nrtReplicas":"1",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: 
null
Live Nodes: [127.0.0.1:37591_solr]
Last available state: 
DocCollection(testRepFactor1LeaderStartup//collections/testRepFactor1LeaderStartup/state.json/4)={
  "pullReplicas":"0",
  "replicationFactor":"1",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{"core_node2":{
  "core":"testRepFactor1LeaderStartup_shard1_replica_n1",
  "base_url":"http://127.0.0.1:37591/solr;,
  "node_name":"127.0.0.1:37591_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"1",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([9D1F07242A8C7757:4A374AFC3B6C3EB9]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.TestCloudSearcherWarming.testRepFactor1LeaderStartup(TestCloudSearcherWarming.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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)

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1403 - Failure

2017-10-17 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1403/

13 tests failed.
FAILED:  org.apache.lucene.index.TestIndexSorting.testRandom3

Error Message:
Test abandoned because suite timeout was reached.

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


FAILED:  junit.framework.TestSuite.org.apache.lucene.index.TestIndexSorting

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

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


FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit

Error Message:
Shard split did not succeed after a previous failed split attempt left 
sub-shards in construction state

Stack Trace:
java.lang.AssertionError: Shard split did not succeed after a previous failed 
split attempt left sub-shards in construction state
at 
__randomizedtesting.SeedInfo.seed([F02C81D8640D9F8F:96112775878D205]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:294)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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] [Commented] (SOLR-11502) Query Elevate Component lazy evaluation of queries

2017-10-17 Thread Erick Erickson (JIRA)

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

Erick Erickson commented on SOLR-11502:
---

Hmmm, what about another cache in solrconfig.xml? Seems like a fine thing for a 
cache as it could be limited by the number of entries. QEC was never envisioned 
as having 10,000 entries in the first place so how much memory used wasn't 
really part of the thinking at the time.

All the plumbing is in place, including a regeneration option to autowarm the N 
most recent QEC queries..

> Query Elevate Component lazy evaluation of queries
> --
>
> Key: SOLR-11502
> URL: https://issues.apache.org/jira/browse/SOLR-11502
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers, SearchComponents - other
>Affects Versions: 6.6.1, 7.1
>Reporter: Robert Lucarini
>
> Whenever a new searcher is opened, _all_ of the Query Elevate queries are run 
> through the query parser and the results stored. So say you have 10,000 
> entries. The autowarming takes however long it takes to process 10,000 
> queries. It would help if there was an option to run the elevate query at 
> query time instead of during autowarming. 



--
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-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false

2017-10-17 Thread Erick Erickson (JIRA)

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

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

This isn't ideal in that it writes the core.properties file twice. That said, 
it's only when creating the core which is only done when you have a CREATE_OP 
core command so it's only done once over the lifetime of the replica.

I'm a little afraid to call ZkController().preRegister differently than it is 
now, or extract the guts of it, I'll look some more though. This seems like the 
minimally-risky change.

I suppose we could call ZkController.preRegister core before calling 
createFromDescriptor everywhere (including before calling coresLocator.create), 
but then next time somebody needed to rearrange things they could forget to 
call preRegister.

Still to come:
1> tests
2> dealing with coreNodeName not being in the properties file and 
legacyCloud=false.

> Collections created with legacyCloud=true cannot be opened if 
> legacyCloud=false
> ---
>
> Key: SOLR-11503
> URL: https://issues.apache.org/jira/browse/SOLR-11503
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Critical
> Attachments: SOLR-11503.patch
>
>
> SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a 
> collection with legacyCloud=true then switch to legacyCloud=false, you get an 
> NPE because coreNodeName is not defined in core.properties.
> Since the default for legacyCloud changed from true to false between 6.6.1 
> and 7.x, this means that any attempt to upgrade Solr with existing 
> collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value 
> for legacyCloud is used in both. Collections created with 6.6.0 would work. 
> Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.
> This is not as egregious with any collections *created with 7.0* since if the 
> default legacyCloud=false is present when the core is created, properties are 
> persisted with coreNodeName. However, if someone switches legacyCloud to 
> true, then creates a collection, then changes legacyCloud back to false then 
> they'll hit this even in 7.0+
> This happened because bit of reordering switched the order of the calls 
> below. coreNodeName is added to the descriptor in 
> create/createFromDescriptor(this, cd) via zkContgroller.preRegister so 
> coresLocator.create(this, cd) persists core.properties without coreNodeName.
> _original order_
> SolrCore core = createFromDescriptor(cd, true, newCollection);
> coresLocator.create(this, cd);
> (NOTE: private calls to create were renamed to createFromDescriptor in 
> SOLR-11122).
> I've got a fix in the works for creating cores, I'll attach a preliminary 
> patch w/o tests in a bit for discussion, but the question is really what to 
> do about 6.6.1 and 6.6.2 and 7.1 for that matter. 
> This is compounded by the fact that with the CVE, there's strong incentive to 
> move to 6.6.2. sgh.
> There are two parts to fixing this completely:
> 1> create core.properties correctly
> 2> deal with coreNodeName not being in the core.properties file by going to 
> ZK and getting it (and persisting it). Haven't worked that part out yet 
> though, not in the first patch. Note one point here if it works as I hope it 
> will update the core.properties files first time they're opened.
> Options that I see, there are really two parts:
> *part1 create the core.properties correctly*
> > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> > Recommend people not install 7x over collections created with 6x until they 
> > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and 
> > creating collections is at your own risk.
> > Recommend that people change legacyCloud=true in 7.x until they start 
> > working with a fixed version, which one TBD.
> *part2 deal with coreNodeName not being in the core.properties*
> > Not backport and release with 7.2? set legacyCloud=true until then.
> > Backport to point releases like 7.1.1? 6.6.3?
> > and what about 7.0? I don't think many people will be affected by 7.0 since 
> > 7.1 came out so soon after. And setting legacyCloud=true will let people 
> > get by.
> Fixing the two parts is not a question, they both need to be fixed. The real 
> question is whether we need to create a point release that incorporates one 
> or both or whether saying "you must set legacyCloud=true prior to Solr 
> version 7.# in order to work with any collections created with Solr versions 
> 6.6.1 through 7.#".
> Let's hear opinions..



--
This message was sent by 

[jira] [Closed] (SOLR-10099) Clicking on the query url in the admin UI is a no-op

2017-10-17 Thread Varun Thacker (JIRA)

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

Varun Thacker closed SOLR-10099.

Assignee: Varun Thacker

> Clicking on the query url in the admin UI is a no-op
> 
>
> Key: SOLR-10099
> URL: https://issues.apache.org/jira/browse/SOLR-10099
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
>
> Steps to reproduce:
> Select a collection , go to the query tab and make a query.
> On the top of the UI the query which the UI used to fetch the results from 
> Solr is displayed. Clicking on this takes you to an empty page.



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

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



[jira] [Assigned] (SOLR-11326) CDCR bootstrap should not download tlog's from source

2017-10-17 Thread Varun Thacker (JIRA)

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

Varun Thacker reassigned SOLR-11326:


Assignee: Varun Thacker

> CDCR bootstrap should not download tlog's from source
> -
>
> Key: SOLR-11326
> URL: https://issues.apache.org/jira/browse/SOLR-11326
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-11326.patch, SOLR-11326.patch
>
>
> While analyzing two separate fails on SOLR-11278 I see that during bootstrap 
> the tlog's from the source is getting download
> snippet1:
> {code}
>[junit4]   2> 42931 INFO  (qtp1525032019-69) [n:127.0.0.1:53178_solr 
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1] 
> o.a.s.h.CdcrReplicatorManager Submitting bootstrap task to executor
>[junit4]   2> 42934 INFO  
> (cdcr-bootstrap-status-32-thread-1-processing-n:127.0.0.1:53178_solr 
> x:cdcr-source_shard1_replica1 s:shard1 c:cdcr-source r:core_node1) 
> [n:127.0.0.1:53178_solr c:cdcr-source s:shard1 r:core_node1 
> x:cdcr-source_shard1_replica1] o.a.s.h.CdcrReplicatorManager Attempting to 
> bootstrap target collection: cdcr-target shard: shard1 leader: 
> http://127.0.0.1:53170/solr/cdcr-target_shard1_replica1/
>[junit4]   2> 43003 INFO  (qtp1525032019-69) [n:127.0.0.1:53178_solr 
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1] 
> o.a.s.c.S.Request [cdcr-source_shard1_replica1]  webapp=/solr 
> path=/replication 
> params={qt=/replication=javabin=2=indexversion} status=0 
> QTime=0
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Master's generation: 12
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Master's version: 
> 1503514968639
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Slave's generation: 1
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Slave's version: 0
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Starting replication 
> process
>[junit4]   2> 43041 INFO  (qtp1525032019-71) [n:127.0.0.1:53178_solr 
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1] 
> o.a.s.h.ReplicationHandler Adding tlog files to list: [{size=4649, 
> name=tlog.000.1576549701811961856}, {size=4770, 
> name=tlog.001.1576549702515556352}, {size=4770, 
> name=tlog.002.1576549702628802560}, {size=4770, 
> name=tlog.003.1576549702720028672}, {size=4770, 
> name=tlog.004.1576549702799720448}, {size=4770, 
> name=tlog.005.1576549702894092288}, {size=4770, 
> name=tlog.006.1576549703029358592}, {size=4770, 
> name=tlog.007.1576549703126876160}, {size=4770, 
> name=tlog.008.1576549703208665088}, {size=4770, 
> name=tlog.009.1576549703295696896}
> {code}
> snippet2:
> {code}
>  17070[junit4]   2> 677606 INFO  (qtp22544544-5725) [] 
> o.a.s.h.CdcrReplicatorManager Attempting to bootstrap target collection: 
> cdcr-target, shard: shard1^M
>  17071[junit4]   2> 677608 INFO  (qtp22544544-5725) [] 
> o.a.s.h.CdcrReplicatorManager Submitting bootstrap task to executor^M
> 17091[junit4]   2> 677627 INFO  (qtp22544544-5724) [] 
> o.a.s.c.S.Request [cdcr-source_shard1_replica_n1]  webapp=/solr 
> path=/replication 
> params={qt=/replication=javabin=2=indexversion} status=0 
> QTime=0^M
>  17092[junit4]   2> 677628 INFO  (recoveryExecutor-1024-thread-1) [] 
> o.a.s.h.IndexFetcher Master's generation: 12^M
>  17093[junit4]   2> 677628 INFO  

[GitHub] lucene-solr issue #263: Backporting of SOLR-11477 on branch_5_5

2017-10-17 Thread sarowe
Github user sarowe commented on the issue:

https://github.com/apache/lucene-solr/pull/263
  
Thanks Sanne!  I committed your patch with these changes: 

* The release will be 5.5.5, so I moved the CHANGES.txt entries under that 
release.
* One of the .java files had some unused imports that I removed.

I tried to close the pull request ("This closes #263" in the commit log 
message), but it didn't seem to work - would you please close this?  Thanks.


---

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



[jira] [Commented] (SOLR-11326) CDCR bootstrap should not download tlog's from source

2017-10-17 Thread Varun Thacker (JIRA)

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

Varun Thacker commented on SOLR-11326:
--

bq.  So why even have the option?

Looking at {{CdcrReplicationHandlerTest}} I see when this is used. When the 
source replica comes up , it needs all the transaction logs from the leader in 
case of leader failure. This also explains why this code exists with default as 
"true"

{code}
// fetch list of tlog files only if cdcr is activated
if (solrParams.getBool(TLOG_FILES, true) && 
core.getUpdateHandler().getUpdateLog() != null
&& core.getUpdateHandler().getUpdateLog() instanceof CdcrUpdateLog) {
{code}

So I think the patch is valid. 


[~sarkaramr...@gmail.com] can we add a test to make sure this functionality 
doesn't break in the future? Maybe we could use a similar mechanism as 
{{CdcrReplicationHandlerTest#assertUpdateLogsEquals}} to make sure that a 
bootstrap doesn't download any tlogs in the target. 

Let's add a test and then we can wrap up this Jira

> CDCR bootstrap should not download tlog's from source
> -
>
> Key: SOLR-11326
> URL: https://issues.apache.org/jira/browse/SOLR-11326
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
> Attachments: SOLR-11326.patch, SOLR-11326.patch
>
>
> While analyzing two separate fails on SOLR-11278 I see that during bootstrap 
> the tlog's from the source is getting download
> snippet1:
> {code}
>[junit4]   2> 42931 INFO  (qtp1525032019-69) [n:127.0.0.1:53178_solr 
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1] 
> o.a.s.h.CdcrReplicatorManager Submitting bootstrap task to executor
>[junit4]   2> 42934 INFO  
> (cdcr-bootstrap-status-32-thread-1-processing-n:127.0.0.1:53178_solr 
> x:cdcr-source_shard1_replica1 s:shard1 c:cdcr-source r:core_node1) 
> [n:127.0.0.1:53178_solr c:cdcr-source s:shard1 r:core_node1 
> x:cdcr-source_shard1_replica1] o.a.s.h.CdcrReplicatorManager Attempting to 
> bootstrap target collection: cdcr-target shard: shard1 leader: 
> http://127.0.0.1:53170/solr/cdcr-target_shard1_replica1/
>[junit4]   2> 43003 INFO  (qtp1525032019-69) [n:127.0.0.1:53178_solr 
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1] 
> o.a.s.c.S.Request [cdcr-source_shard1_replica1]  webapp=/solr 
> path=/replication 
> params={qt=/replication=javabin=2=indexversion} status=0 
> QTime=0
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Master's generation: 12
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Master's version: 
> 1503514968639
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Slave's generation: 1
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Slave's version: 0
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Starting replication 
> process
>[junit4]   2> 43041 INFO  (qtp1525032019-71) [n:127.0.0.1:53178_solr 
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1] 
> o.a.s.h.ReplicationHandler Adding tlog files to list: [{size=4649, 
> name=tlog.000.1576549701811961856}, {size=4770, 
> name=tlog.001.1576549702515556352}, {size=4770, 
> name=tlog.002.1576549702628802560}, {size=4770, 
> name=tlog.003.1576549702720028672}, {size=4770, 
> name=tlog.004.1576549702799720448}, {size=4770, 
> name=tlog.005.1576549702894092288}, {size=4770, 
> name=tlog.006.1576549703029358592}, {size=4770, 
> name=tlog.007.1576549703126876160}, {size=4770, 
> 

[jira] [Created] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false

2017-10-17 Thread Erick Erickson (JIRA)
Erick Erickson created SOLR-11503:
-

 Summary: Collections created with legacyCloud=true cannot be 
opened if legacyCloud=false
 Key: SOLR-11503
 URL: https://issues.apache.org/jira/browse/SOLR-11503
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6.1
Reporter: Erick Erickson
Priority: Critical


SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a 
collection with legacyCloud=true then switch to legacyCloud=false, you get an 
NPE because coreNodeName is not defined in core.properties.

Since the default for legacyCloud changed from true to false between 6.6.1 and 
7.x, this means that any attempt to upgrade Solr with existing collections 
*created with Solr 6.6.1 or 6.6.2 will fail* if the default value for 
legacyCloud is used in both. Collections created with 6.6.0 would work. 
Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.

This is not as egregious with any collections *created with 7.0* since if the 
default legacyCloud=false is present when the core is created, properties are 
persisted with coreNodeName. However, if someone switches legacyCloud to true, 
then creates a collection, then changes legacyCloud back to false then they'll 
hit this even in 7.0+

This happened because bit of reordering switched the order of the calls below. 
coreNodeName is added to the descriptor in create/createFromDescriptor(this, 
cd) via zkContgroller.preRegister so coresLocator.create(this, cd) persists 
core.properties without coreNodeName.

_original order_
SolrCore core = createFromDescriptor(cd, true, newCollection);
coresLocator.create(this, cd);

(NOTE: private calls to create were renamed to createFromDescriptor in 
SOLR-11122).

I've got a fix in the works for creating cores, I'll attach a preliminary patch 
w/o tests in a bit for discussion, but the question is really what to do about 
6.6.1 and 6.6.2 and 7.1 for that matter. 

This is compounded by the fact that with the CVE, there's strong incentive to 
move to 6.6.2. sgh.

There are two parts to fixing this completely:
1> create core.properties correctly
2> deal with coreNodeName not being in the core.properties file by going to ZK 
and getting it (and persisting it). Haven't worked that part out yet though, 
not in the first patch. Note one point here if it works as I hope it will 
update the core.properties files first time they're opened.


Options that I see, there are really two parts:

*part1 create the core.properties correctly*
> Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> Recommend people not install 7x over collections created with 6x until they 
> have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and 
> creating collections is at your own risk.
> Recommend that people change legacyCloud=true in 7.x until they start working 
> with a fixed version, which one TBD.

*part2 deal with coreNodeName not being in the core.properties*

> Not backport and release with 7.2? set legacyCloud=true until then.
> Backport to point releases like 7.1.1? 6.6.3?
> and what about 7.0? I don't think many people will be affected by 7.0 since 
> 7.1 came out so soon after. And setting legacyCloud=true will let people get 
> by.

Fixing the two parts is not a question, they both need to be fixed. The real 
question is whether we need to create a point release that incorporates one or 
both or whether saying "you must set legacyCloud=true prior to Solr version 7.# 
in order to work with any collections created with Solr versions 6.6.1 through 
7.#".

Let's hear opinions..




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

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



[jira] [Assigned] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false

2017-10-17 Thread Erick Erickson (JIRA)

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

Erick Erickson reassigned SOLR-11503:
-

Assignee: Erick Erickson

> Collections created with legacyCloud=true cannot be opened if 
> legacyCloud=false
> ---
>
> Key: SOLR-11503
> URL: https://issues.apache.org/jira/browse/SOLR-11503
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Critical
>
> SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a 
> collection with legacyCloud=true then switch to legacyCloud=false, you get an 
> NPE because coreNodeName is not defined in core.properties.
> Since the default for legacyCloud changed from true to false between 6.6.1 
> and 7.x, this means that any attempt to upgrade Solr with existing 
> collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value 
> for legacyCloud is used in both. Collections created with 6.6.0 would work. 
> Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.
> This is not as egregious with any collections *created with 7.0* since if the 
> default legacyCloud=false is present when the core is created, properties are 
> persisted with coreNodeName. However, if someone switches legacyCloud to 
> true, then creates a collection, then changes legacyCloud back to false then 
> they'll hit this even in 7.0+
> This happened because bit of reordering switched the order of the calls 
> below. coreNodeName is added to the descriptor in 
> create/createFromDescriptor(this, cd) via zkContgroller.preRegister so 
> coresLocator.create(this, cd) persists core.properties without coreNodeName.
> _original order_
> SolrCore core = createFromDescriptor(cd, true, newCollection);
> coresLocator.create(this, cd);
> (NOTE: private calls to create were renamed to createFromDescriptor in 
> SOLR-11122).
> I've got a fix in the works for creating cores, I'll attach a preliminary 
> patch w/o tests in a bit for discussion, but the question is really what to 
> do about 6.6.1 and 6.6.2 and 7.1 for that matter. 
> This is compounded by the fact that with the CVE, there's strong incentive to 
> move to 6.6.2. sgh.
> There are two parts to fixing this completely:
> 1> create core.properties correctly
> 2> deal with coreNodeName not being in the core.properties file by going to 
> ZK and getting it (and persisting it). Haven't worked that part out yet 
> though, not in the first patch. Note one point here if it works as I hope it 
> will update the core.properties files first time they're opened.
> Options that I see, there are really two parts:
> *part1 create the core.properties correctly*
> > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> > Recommend people not install 7x over collections created with 6x until they 
> > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and 
> > creating collections is at your own risk.
> > Recommend that people change legacyCloud=true in 7.x until they start 
> > working with a fixed version, which one TBD.
> *part2 deal with coreNodeName not being in the core.properties*
> > Not backport and release with 7.2? set legacyCloud=true until then.
> > Backport to point releases like 7.1.1? 6.6.3?
> > and what about 7.0? I don't think many people will be affected by 7.0 since 
> > 7.1 came out so soon after. And setting legacyCloud=true will let people 
> > get by.
> Fixing the two parts is not a question, they both need to be fixed. The real 
> question is whether we need to create a point release that incorporates one 
> or both or whether saying "you must set legacyCloud=true prior to Solr 
> version 7.# in order to work with any collections created with Solr versions 
> 6.6.1 through 7.#".
> Let's hear opinions..



--
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-master-MacOSX (64bit/jdk1.8.0) - Build # 4234 - Unstable!

2017-10-17 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4234/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.SystemLogListenerTest.test

Error Message:
Timed out waiting for replicas of new collection to be active null Live Nodes: 
[127.0.0.1:57996_solr, 127.0.0.1:57997_solr, 127.0.0.1:57998_solr] Last 
available state: null

Stack Trace:
java.lang.AssertionError: Timed out waiting for replicas of new collection to 
be active
null
Live Nodes: [127.0.0.1:57996_solr, 127.0.0.1:57997_solr, 127.0.0.1:57998_solr]
Last available state: null
at 
__randomizedtesting.SeedInfo.seed([EBA17D90DB9697D5:63F5424A756AFA2D]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.autoscaling.SystemLogListenerTest.test(SystemLogListenerTest.java:120)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Commented] (SOLR-11326) CDCR bootstrap should not download tlog's from source

2017-10-17 Thread Varun Thacker (JIRA)

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

Varun Thacker commented on SOLR-11326:
--

Is there any scenario where we need to download the tlogs? I don't see any 
use-case in master-slave / solrcloud or in cdcr . So why even have the option? 

Today in CDCR we explicitly ask the replication handler not to download the 
tlogs by doing this

{[solrParams.set(ReplicationHandler.TLOG_FILES, false);}}

But the param is not respected. The patch actually fixes the issue. But why 
even keep such an option when we don't need it?

Does someone know the motivation of this in {{ReplicationHander::getFileList}}

{code}
// fetch list of tlog files only if cdcr is activated
if (solrParams.getBool(TLOG_FILES, true) && 
core.getUpdateHandler().getUpdateLog() != null
&& core.getUpdateHandler().getUpdateLog() instanceof CdcrUpdateLog) {
{code}

> CDCR bootstrap should not download tlog's from source
> -
>
> Key: SOLR-11326
> URL: https://issues.apache.org/jira/browse/SOLR-11326
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
> Attachments: SOLR-11326.patch, SOLR-11326.patch
>
>
> While analyzing two separate fails on SOLR-11278 I see that during bootstrap 
> the tlog's from the source is getting download
> snippet1:
> {code}
>[junit4]   2> 42931 INFO  (qtp1525032019-69) [n:127.0.0.1:53178_solr 
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1] 
> o.a.s.h.CdcrReplicatorManager Submitting bootstrap task to executor
>[junit4]   2> 42934 INFO  
> (cdcr-bootstrap-status-32-thread-1-processing-n:127.0.0.1:53178_solr 
> x:cdcr-source_shard1_replica1 s:shard1 c:cdcr-source r:core_node1) 
> [n:127.0.0.1:53178_solr c:cdcr-source s:shard1 r:core_node1 
> x:cdcr-source_shard1_replica1] o.a.s.h.CdcrReplicatorManager Attempting to 
> bootstrap target collection: cdcr-target shard: shard1 leader: 
> http://127.0.0.1:53170/solr/cdcr-target_shard1_replica1/
>[junit4]   2> 43003 INFO  (qtp1525032019-69) [n:127.0.0.1:53178_solr 
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1] 
> o.a.s.c.S.Request [cdcr-source_shard1_replica1]  webapp=/solr 
> path=/replication 
> params={qt=/replication=javabin=2=indexversion} status=0 
> QTime=0
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Master's generation: 12
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Master's version: 
> 1503514968639
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Slave's generation: 1
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Slave's version: 0
>[junit4]   2> 43004 INFO  
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr 
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Starting replication 
> process
>[junit4]   2> 43041 INFO  (qtp1525032019-71) [n:127.0.0.1:53178_solr 
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1] 
> o.a.s.h.ReplicationHandler Adding tlog files to list: [{size=4649, 
> name=tlog.000.1576549701811961856}, {size=4770, 
> name=tlog.001.1576549702515556352}, {size=4770, 
> name=tlog.002.1576549702628802560}, {size=4770, 
> name=tlog.003.1576549702720028672}, {size=4770, 
> name=tlog.004.1576549702799720448}, {size=4770, 
> name=tlog.005.1576549702894092288}, {size=4770, 
> name=tlog.006.1576549703029358592}, {size=4770, 
> name=tlog.007.1576549703126876160}, {size=4770, 
> name=tlog.008.1576549703208665088}, {size=4770, 
> name=tlog.009.1576549703295696896}
> {code}
> 

[jira] [Commented] (LUCENE-7538) Uploading large text file to a field causes "this IndexWriter is closed" error

2017-10-17 Thread nkeet shah (JIRA)

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

nkeet shah commented on LUCENE-7538:


Erick, we are not using SOLR purely as a search engine. we are using it 
slightly in a non-traditional manner, and our user case of 1GB file are very 
valid. Thanks Michael for the pointer.

> Uploading large text file to a field causes "this IndexWriter is closed" error
> --
>
> Key: LUCENE-7538
> URL: https://issues.apache.org/jira/browse/LUCENE-7538
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.5.1
>Reporter: Steve Chen
> Fix For: 6.4, 7.0
>
> Attachments: LUCENE-7538.patch, LUCENE-7538.patch
>
>
> We have seen "this IndexWriter is closed" error after we tried to upload a 
> large text file to a single Solr text field. The field definition in the 
> schema.xml is:
> {noformat}
>  termVectors="true" termPositions="true" termOffsets="true"/>
> {noformat}
> After that, the IndexWriter remained closed and couldn't be recovered until 
> we reloaded the Solr core.  The text file had size of 800MB, containing only 
> numbers and English characters.
> Stack trace is shown below:
> {noformat}
> 2016-11-02 23:00:17,913 [http-nio-19082-exec-3] ERROR 
> org.apache.solr.handler.RequestHandlerBase - 
> org.apache.solr.common.SolrException: Exception writing document id 1487_0_1 
> to the index; possible analysis error.
> at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:180)
> at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:68)
> at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:934)
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1089)
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:712)
> at 
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
> at 
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.doAdd(ExtractingDocumentLoader.java:126)
> at 
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.addDoc(ExtractingDocumentLoader.java:131)
> at 
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:237)
> at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:69)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:651)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:458)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at 
> veeva.ecm.common.interfaces.web.SolrDispatchOverride.doFilter(SolrDispatchOverride.java:43)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> at 
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:521)
> at 
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1096)
> at 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:674)
> at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500)
> at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456)
> at 
> 

[jira] [Commented] (SOLR-9090) solrj CloudSolrClient: add directUpdatesToLeadersOnly support

2017-10-17 Thread David Smiley (JIRA)

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

David Smiley commented on SOLR-9090:


Furthermore, shouldn't {{shardLeadersOnly}} be randomized as well?

> solrj CloudSolrClient: add directUpdatesToLeadersOnly support
> -
>
> Key: SOLR-9090
> URL: https://issues.apache.org/jira/browse/SOLR-9090
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.2, 7.0
>
> Attachments: SOLR-9090.patch, SOLR-9090.patch
>
>
> solrj CloudSolrClient: add directUpdatesToLeadersOnly support
> (Marvin Justice, Christine Poerschke)
> Proposed change:
> * Addition of a {{directUpdatesToLeadersOnly}} flag to allow clients to 
> request that direct updates be sent to the shard leaders and only to the 
> shard leaders.
> Motivation:
> * In a scenario where there is temporarily no shard leader the update request 
> will 'fail fast' allowing the client to handle retry logic.
> Related tickets:
> * SOLR-6312 concerns the ((currently) no longer used) {{updatesToLeaders}} 
> flag. The updatesToLeaders logic however appears to be slightly different 
> from the proposed directUpdatesToLeadersOnly logic: {{updatesToLeaders}} 
> indicates that sending to leaders is preferred but not mandatory whereas 
> {{directUpdatesToLeadersOnly}} mandates sending to leaders only.



--
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-9090) solrj CloudSolrClient: add directUpdatesToLeadersOnly support

2017-10-17 Thread David Smiley (JIRA)

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

David Smiley commented on SOLR-9090:


[~cpoerschke] I'm looking at {{SolrTestCaseJ4.CloudSolrClientBuilder}}.  
Instead of the somewhat complicated tracking using configuredDUTflag, couldn't 
you simply remove all that stuff and just modify the builder's constructor to 
randomize the settings?

> solrj CloudSolrClient: add directUpdatesToLeadersOnly support
> -
>
> Key: SOLR-9090
> URL: https://issues.apache.org/jira/browse/SOLR-9090
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.2, 7.0
>
> Attachments: SOLR-9090.patch, SOLR-9090.patch
>
>
> solrj CloudSolrClient: add directUpdatesToLeadersOnly support
> (Marvin Justice, Christine Poerschke)
> Proposed change:
> * Addition of a {{directUpdatesToLeadersOnly}} flag to allow clients to 
> request that direct updates be sent to the shard leaders and only to the 
> shard leaders.
> Motivation:
> * In a scenario where there is temporarily no shard leader the update request 
> will 'fail fast' allowing the client to handle retry logic.
> Related tickets:
> * SOLR-6312 concerns the ((currently) no longer used) {{updatesToLeaders}} 
> flag. The updatesToLeaders logic however appears to be slightly different 
> from the proposed directUpdatesToLeadersOnly logic: {{updatesToLeaders}} 
> indicates that sending to leaders is preferred but not mandatory whereas 
> {{directUpdatesToLeadersOnly}} mandates sending to leaders only.



--
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-11160) Add normalDistribution, uniformDistribution, sample and kolmogorovSmirnov Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11160.
---
Resolution: Resolved

> Add normalDistribution, uniformDistribution, sample and kolmogorovSmirnov 
> Stream Evaluators
> ---
>
> Key: SOLR-11160
> URL: https://issues.apache.org/jira/browse/SOLR-11160
> 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-11160.patch, SOLR-11160.patch, SOLR-11160.patch
>
>
> This ticket digs deeper into *probability distributions*, which are a key 
> foundation of statistics.
> Three new functions are introduced:
> 1) *normalDistribution*: This is a distribution function which returns a 
> normal distribution generator. It is designed to be used with both the 
> *sample* and the *kolmogorovSmirnov* functions. Eventually a function will be 
> added for every distribution supported by *Apache Commons Math*.
> 2) *sample*: Returns array of numbers that conforms to a given distribution. 
> You pass it a distribution function and size  and it returns the array that 
> conforms to the distribution.
> 3) *kolmogorovSmirnov*: Performs a goodness of fit test for distributions. 
> This function can will do both a one and two side test. The one sided test 
> compares a sample to a distribution function. The two sided test compares two 
> samples to see if that were pulled from the same distribution.



--
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-11160) Add normalDistribution, uniformDistribution, sample and kolmogorovSmirnov Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein updated SOLR-11160:
--
Fix Version/s: (was: 7.2)
   7.1

> Add normalDistribution, uniformDistribution, sample and kolmogorovSmirnov 
> Stream Evaluators
> ---
>
> Key: SOLR-11160
> URL: https://issues.apache.org/jira/browse/SOLR-11160
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-11160.patch, SOLR-11160.patch, SOLR-11160.patch
>
>
> This ticket digs deeper into *probability distributions*, which are a key 
> foundation of statistics.
> Three new functions are introduced:
> 1) *normalDistribution*: This is a distribution function which returns a 
> normal distribution generator. It is designed to be used with both the 
> *sample* and the *kolmogorovSmirnov* functions. Eventually a function will be 
> added for every distribution supported by *Apache Commons Math*.
> 2) *sample*: Returns array of numbers that conforms to a given distribution. 
> You pass it a distribution function and size  and it returns the array that 
> conforms to the distribution.
> 3) *kolmogorovSmirnov*: Performs a goodness of fit test for distributions. 
> This function can will do both a one and two side test. The one sided test 
> compares a sample to a distribution function. The two sided test compares two 
> samples to see if that were pulled from the same distribution.



--
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-11225) Add cumulativeProbability Stream Evaluator

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein updated SOLR-11225:
--
Fix Version/s: (was: 7.2)
   7.1

> Add cumulativeProbability Stream Evaluator
> --
>
> Key: SOLR-11225
> URL: https://issues.apache.org/jira/browse/SOLR-11225
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-11225.patch
>
>
> This ticket will add the cumulative probability evaluator:
> http://stattrek.com/statistics/dictionary.aspx?definition=Cumulative_probability
> Syntax:
> {code}
> cumulativeProbability(normalDistribution(500, 40), 500)
> {code}



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

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



[jira] [Resolved] (SOLR-11241) Add discrete counting and probability Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11241.
---
Resolution: Resolved

> Add discrete counting and probability Stream Evaluators
> ---
>
> Key: SOLR-11241
> URL: https://issues.apache.org/jira/browse/SOLR-11241
> 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-11241.path, SOLR-11241.path, SOLR-11241.path
>
>
> This ticket will add a number of statistical functions that deal with 
> discrete counting and probability distributions:
> freqTable
> enumeratedDistribution
> poissonDistribution
> uniformIntegerDistribution
> binomialDistribution
> probability
> All functions backed by *Apache Commons Math*



--
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-11225) Add cumulativeProbability Stream Evaluator

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11225.
---
Resolution: Resolved

> Add cumulativeProbability Stream Evaluator
> --
>
> Key: SOLR-11225
> URL: https://issues.apache.org/jira/browse/SOLR-11225
> 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-11225.patch
>
>
> This ticket will add the cumulative probability evaluator:
> http://stattrek.com/statistics/dictionary.aspx?definition=Cumulative_probability
> Syntax:
> {code}
> cumulativeProbability(normalDistribution(500, 40), 500)
> {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-11321) Add ebeAdd, ebeSubtract, ebeDivide, ebeMultiply, dotProduct and cosineSimilarity Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein updated SOLR-11321:
--
Fix Version/s: (was: 7.2)
   7.1

> Add ebeAdd, ebeSubtract, ebeDivide, ebeMultiply, dotProduct and 
> cosineSimilarity Stream Evaluators 
> ---
>
> Key: SOLR-11321
> URL: https://issues.apache.org/jira/browse/SOLR-11321
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-11321.patch, SOLR-11321.patch
>
>
> This ticket adds some important vector math evaluators to the statistical 
> programming library.
> *ebeAdd*: Element by element addition of two vectors
> *ebeSubtract*: Element by element subtraction of two vectors
> *ebeMultiply*: Element by element multiplication of two vectors
> *ebeDivide*: Element by element division of two vectors
> *dotProduct*: The dot product of two vectors
> *consineSimilartiy*: The cosine similarity of two vectors



--
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-11241) Add discrete counting and probability Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein updated SOLR-11241:
--
Fix Version/s: (was: 7.2)
   7.1

> Add discrete counting and probability Stream Evaluators
> ---
>
> Key: SOLR-11241
> URL: https://issues.apache.org/jira/browse/SOLR-11241
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-11241.path, SOLR-11241.path, SOLR-11241.path
>
>
> This ticket will add a number of statistical functions that deal with 
> discrete counting and probability distributions:
> freqTable
> enumeratedDistribution
> poissonDistribution
> uniformIntegerDistribution
> binomialDistribution
> probability
> All functions backed by *Apache Commons Math*



--
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-11338) Add Kendall's Tau-b rank and Spearmans rank correlation Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11338.
---
Resolution: Resolved

> Add Kendall's Tau-b rank and Spearmans rank correlation Stream Evaluators
> -
>
> Key: SOLR-11338
> URL: https://issues.apache.org/jira/browse/SOLR-11338
> 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-11338.patch
>
>
> Streaming Expressions already supports Pearson's product moment correlation.
> This ticket adds *Kendall's Tau-b rank correlation* and *Spearmans rank 
> correlation* Stream Evaluators.
> Functions are backed by Apache Commons Math



--
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-11321) Add ebeAdd, ebeSubtract, ebeDivide, ebeMultiply, dotProduct and cosineSimilarity Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11321.
---
Resolution: Resolved

> Add ebeAdd, ebeSubtract, ebeDivide, ebeMultiply, dotProduct and 
> cosineSimilarity Stream Evaluators 
> ---
>
> Key: SOLR-11321
> URL: https://issues.apache.org/jira/browse/SOLR-11321
> 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-11321.patch, SOLR-11321.patch
>
>
> This ticket adds some important vector math evaluators to the statistical 
> programming library.
> *ebeAdd*: Element by element addition of two vectors
> *ebeSubtract*: Element by element subtraction of two vectors
> *ebeMultiply*: Element by element multiplication of two vectors
> *ebeDivide*: Element by element division of two vectors
> *dotProduct*: The dot product of two vectors
> *consineSimilartiy*: The cosine similarity of two vectors



--
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-11342) Add sumDifference and meanDifference Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein updated SOLR-11342:
--
Fix Version/s: (was: 7.2)
   7.1

> Add sumDifference and meanDifference Stream Evaluators
> --
>
> Key: SOLR-11342
> URL: https://issues.apache.org/jira/browse/SOLR-11342
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-11342.patch
>
>
> This ticket adds the sumDifference and meanDifference Stream evaluators.



--
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-11339) Add Canberra, Chebyshev, Earth Movers and Manhattan Distance Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein updated SOLR-11339:
--
Fix Version/s: (was: 7.2)
   7.1

> Add Canberra, Chebyshev, Earth Movers and Manhattan Distance Stream Evaluators
> --
>
> Key: SOLR-11339
> URL: https://issues.apache.org/jira/browse/SOLR-11339
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-11339.patch
>
>
> Streaming Expressions already supports Euclidean distance. This ticket will 
> add Canberra, Chebyshev, Earth Movers and Manhattan Distance Stream Evaluators



--
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-11338) Add Kendall's Tau-b rank and Spearmans rank correlation Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein updated SOLR-11338:
--
Fix Version/s: (was: 7.2)
   7.1

> Add Kendall's Tau-b rank and Spearmans rank correlation Stream Evaluators
> -
>
> Key: SOLR-11338
> URL: https://issues.apache.org/jira/browse/SOLR-11338
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-11338.patch
>
>
> Streaming Expressions already supports Pearson's product moment correlation.
> This ticket adds *Kendall's Tau-b rank correlation* and *Spearmans rank 
> correlation* Stream Evaluators.
> Functions are backed by Apache Commons Math



--
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-11339) Add Canberra, Chebyshev, Earth Movers and Manhattan Distance Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11339.
---
Resolution: Resolved

> Add Canberra, Chebyshev, Earth Movers and Manhattan Distance Stream Evaluators
> --
>
> Key: SOLR-11339
> URL: https://issues.apache.org/jira/browse/SOLR-11339
> 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-11339.patch
>
>
> Streaming Expressions already supports Euclidean distance. This ticket will 
> add Canberra, Chebyshev, Earth Movers and Manhattan Distance Stream Evaluators



--
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-11350) Add primes Stream Evaluator

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein updated SOLR-11350:
--
Fix Version/s: (was: 7.2)
   7.1

> Add primes Stream Evaluator
> ---
>
> Key: SOLR-11350
> URL: https://issues.apache.org/jira/browse/SOLR-11350
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-11350.patch
>
>
> The primes Stream Evaluator will return an array of N prime numbers starting 
> from S.
> Syntax:
> {code}
> primes(N, S)
> {code}



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

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



[jira] [Resolved] (SOLR-11342) Add sumDifference and meanDifference Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11342.
---
Resolution: Resolved

> Add sumDifference and meanDifference Stream Evaluators
> --
>
> Key: SOLR-11342
> URL: https://issues.apache.org/jira/browse/SOLR-11342
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11342.patch
>
>
> This ticket adds the sumDifference and meanDifference Stream evaluators.



--
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-11350) Add primes Stream Evaluator

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11350.
---
Resolution: Resolved

> Add primes Stream Evaluator
> ---
>
> Key: SOLR-11350
> URL: https://issues.apache.org/jira/browse/SOLR-11350
> 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-11350.patch
>
>
> The primes Stream Evaluator will return an array of N prime numbers starting 
> from S.
> Syntax:
> {code}
> primes(N, S)
> {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-11377) Add expMovingAverage (exponential moving average) and binomialCoefficient Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein updated SOLR-11377:
--
Fix Version/s: (was: 7.2)
   7.1

> Add expMovingAverage (exponential moving average) and binomialCoefficient 
> Stream Evaluators
> ---
>
> Key: SOLR-11377
> URL: https://issues.apache.org/jira/browse/SOLR-11377
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-11377.patch, SOLR-11377.patch
>
>
> This ticket will add the exponential moving average Stream Evaluator.
> Syntax:
> {code}
> expMovingAvg(colA)
> {code}



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

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



[jira] [Resolved] (SOLR-11354) Add factorial and movingMedian Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11354.
---
Resolution: Resolved

> Add factorial and movingMedian Stream Evaluators
> 
>
> Key: SOLR-11354
> URL: https://issues.apache.org/jira/browse/SOLR-11354
> 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
>
>
> This ticket will add the factorial and movingMedian Stream Evaluators:
> Syntax:
> {code}
> factorial(N)
> movingMedian(colA)
> {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-11354) Add factorial and movingMedian Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein updated SOLR-11354:
--
Fix Version/s: (was: 7.0)
   7.1

> Add factorial and movingMedian Stream Evaluators
> 
>
> Key: SOLR-11354
> URL: https://issues.apache.org/jira/browse/SOLR-11354
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.1, master (8.0)
>
>
> This ticket will add the factorial and movingMedian Stream Evaluators:
> Syntax:
> {code}
> factorial(N)
> movingMedian(colA)
> {code}



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

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



[jira] [Resolved] (SOLR-11377) Add expMovingAverage (exponential moving average) and binomialCoefficient Stream Evaluators

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11377.
---
Resolution: Resolved

> Add expMovingAverage (exponential moving average) and binomialCoefficient 
> Stream Evaluators
> ---
>
> Key: SOLR-11377
> URL: https://issues.apache.org/jira/browse/SOLR-11377
> 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-11377.patch, SOLR-11377.patch
>
>
> This ticket will add the exponential moving average Stream Evaluator.
> Syntax:
> {code}
> expMovingAvg(colA)
> {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-11388) Add monteCarlo Stream Evaluator to support Monte Carlo simulations

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein updated SOLR-11388:
--
Fix Version/s: (was: 7.2)
   7.1

> Add monteCarlo Stream Evaluator to support Monte Carlo simulations
> --
>
> Key: SOLR-11388
> URL: https://issues.apache.org/jira/browse/SOLR-11388
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-11388.patch, SOLR-11388.patch, Screen Shot 
> 2017-09-22 at 9.12.48 PM.png
>
>
> The monteCarlo Stream Evaluator will run Monte Carlo simulations using the 
> new probability distribution framework in Solr 7.
> More details on this to follow...



--
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-11398) Add weibullDistribution Stream Evaluator

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11398.
---
Resolution: Resolved

> Add weibullDistribution Stream Evaluator
> 
>
> Key: SOLR-11398
> URL: https://issues.apache.org/jira/browse/SOLR-11398
> 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-11398.patch
>
>
> This ticket adds support for the Weibull probability distribution to the 
> Streaming Expression probability distribution framework.



--
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-11388) Add monteCarlo Stream Evaluator to support Monte Carlo simulations

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11388.
---
Resolution: Resolved

> Add monteCarlo Stream Evaluator to support Monte Carlo simulations
> --
>
> Key: SOLR-11388
> URL: https://issues.apache.org/jira/browse/SOLR-11388
> 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-11388.patch, SOLR-11388.patch, Screen Shot 
> 2017-09-22 at 9.12.48 PM.png
>
>
> The monteCarlo Stream Evaluator will run Monte Carlo simulations using the 
> new probability distribution framework in Solr 7.
> More details on this to follow...



--
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-11401) Add zipFDistribution Stream Evaluator

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein resolved SOLR-11401.
---
Resolution: Resolved

> Add zipFDistribution Stream Evaluator
> -
>
> Key: SOLR-11401
> URL: https://issues.apache.org/jira/browse/SOLR-11401
> 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-11401.patch
>
>
> This ticket adds support for the ZipF probability distribution to the 
> Streaming Expression statistical library.



--
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-11400) Add logNormalDistribution Stream Evaluator

2017-10-17 Thread Joel Bernstein (JIRA)

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

Joel Bernstein updated SOLR-11400:
--
Fix Version/s: (was: 7.2)
   7.1

> Add logNormalDistribution Stream Evaluator
> --
>
> Key: SOLR-11400
> URL: https://issues.apache.org/jira/browse/SOLR-11400
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-11400.patch
>
>
> This ticket adds the Log Normal probability distribution to the Streaming 
> Expression statistical library.



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



  1   2   3   >