[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_121) - Build # 18884 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18884/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 13004 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/temp/junit4-J1-20170201_070525_8482400775360232365855.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: Java heap space
   [junit4] Dumping heap to 
/home/jenkins/workspace/Lucene-Solr-master-Linux/heapdumps/java_pid22757.hprof 
...
   [junit4] Heap dump file created [69622212 bytes in 0.636 secs]
   [junit4] <<< JVM J1: EOF 

[...truncated 11675 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:727: Some of the 
tests produced a heap dump, but did not fail. Maybe a suppressed 
OutOfMemoryError? Dumps created:
* java_pid22757.hprof

Total time: 82 minutes 1 second
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
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-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+153) - Build # 2776 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2776/
Java: 32bit/jdk-9-ea+153 -server -XX:+UseConcMarkSweepGC

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

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node2:{"core":"c8n_1x3_lf_shard1_replica3","base_url":"http://127.0.0.1:35492/_cqy/n","node_name":"127.0.0.1:35492__cqy%2Fn","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/32)={   
"replicationFactor":"3",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "state":"down",   
"base_url":"http://127.0.0.1:45922/_cqy/n;,   
"core":"c8n_1x3_lf_shard1_replica2",   
"node_name":"127.0.0.1:45922__cqy%2Fn"}, "core_node2":{   
"core":"c8n_1x3_lf_shard1_replica3",   
"base_url":"http://127.0.0.1:35492/_cqy/n;,   
"node_name":"127.0.0.1:35492__cqy%2Fn",   "state":"active",   
"leader":"true"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:36166/_cqy/n;,   
"node_name":"127.0.0.1:36166__cqy%2Fn",   "state":"down",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node2:{"core":"c8n_1x3_lf_shard1_replica3","base_url":"http://127.0.0.1:35492/_cqy/n","node_name":"127.0.0.1:35492__cqy%2Fn","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/32)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "state":"down",
  "base_url":"http://127.0.0.1:45922/_cqy/n;,
  "core":"c8n_1x3_lf_shard1_replica2",
  "node_name":"127.0.0.1:45922__cqy%2Fn"},
"core_node2":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "base_url":"http://127.0.0.1:35492/_cqy/n;,
  "node_name":"127.0.0.1:35492__cqy%2Fn",
  "state":"active",
  "leader":"true"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:36166/_cqy/n;,
  "node_name":"127.0.0.1:36166__cqy%2Fn",
  "state":"down",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([98BE79BB34C0BBD:81DFD8411DB06645]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:168)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
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:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

Re: VOTE: Apache Solr Ref Guide for 6.4

[David Smiley]

+1 from me.  I reviewed the Highlighting section specifically and found a
small error (fixed in Confluence just now) but not enough to warrant a
respin IMO.

On Tue, Jan 31, 2017 at 10:44 AM Cassandra Targett 
wrote:

> Please vote to release the Apache Solr Ref Guide for Solr 6.4.
>
> Artifacts can be found at:
>
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.4-RC0/
>
> $ cat apache-solr-ref-guide-6.4-RC0/apache-solr-ref-guide-6.4.pdf.sha1
> 2e5f27c1aae36fde5717dd01a4495c5e299c9407  apache-solr-ref-guide-6.4.pdf
>
> I'm not a huge fan of releasing with issues found at the last minute
> such as the one Erick E filed last night (SOLR-10061, about issues
> with the CoreAdmin API docs), but in this case I have a bunch of other
> stuff to do this week & next at the day job, I don't know the
> CoreAdmin API that well, and when SOLR-8029 (v2 API) is backported to
> 6.x, we will likely revamp ALL of the API pages, including that one.
>
> So, that said, here's +1 from me.
>
> Cassandra
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 646 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/646/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

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

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([1B4C218B8F6E85C8:73F314A15FF49724]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:141)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:295)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Assigned] (SOLR-10065) The Nightly test ConcurrentDeleteAndCreateCollectionTest appears to be too fragile.

[Mark Miller (JIRA)]

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

Mark Miller reassigned SOLR-10065:
--

Assignee: Mark Miller

> The Nightly test ConcurrentDeleteAndCreateCollectionTest appears to be too 
> fragile.
> ---
>
> Key: SOLR-10065
> URL: https://issues.apache.org/jira/browse/SOLR-10065
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>
> ConcurrentDeleteAndCreateCollectionTest 100.00% mission-failed 30.00 134.34 
> @Nightly



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 1109 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1109/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

4 tests failed.
FAILED:  org.apache.solr.cloud.PeerSyncReplicationTest.test

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([C9E5AF64279550E3:41B190BE89693D1B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Commented] (SOLR-10082) Add Variance and Standard Deviation aggregators

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-10082:
---

GitHub user rustamhsmv opened a pull request:

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

SOLR-10082 : Add Variance and Standard Deviation aggregators



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rustamhsmv/lucene-solr VarianceStddev

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/155.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #155


commit 6e1e1ac0296400bd87def4fa62ebab9541c1f9a4
Author: rustamhsmv 
Date:   2017-01-31T22:34:05Z

Add Variance and Stddev Aggregators

commit 672138bf34bb7eee43add03e5d04aaff25955d17
Author: rustamhsmv 
Date:   2017-01-31T22:40:20Z

Merge branch 'master' of https://github.com/rustamhsmv/lucene-solr into 
VarianceStddev




> Add Variance and  Standard Deviation aggregators
> 
>
> Key: SOLR-10082
> URL: https://issues.apache.org/jira/browse/SOLR-10082
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Affects Versions: master (7.0)
>Reporter: Rustam Hashimov
>Priority: Minor
>
> This is a ticket to add variance and  standard deviation aggregators to json 
> facet.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10082) Add Variance and Standard Deviation aggregators

[Rustam Hashimov (JIRA)]

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

Rustam Hashimov updated SOLR-10082:
---
External issue URL: https://github.com/apache/lucene-solr/pull/155
Issue Type: Improvement  (was: Bug)

> Add Variance and  Standard Deviation aggregators
> 
>
> Key: SOLR-10082
> URL: https://issues.apache.org/jira/browse/SOLR-10082
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Affects Versions: master (7.0)
>Reporter: Rustam Hashimov
>Priority: Minor
>
> This is a ticket to add variance and  standard deviation aggregators to json 
> facet.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10082) Add Variance and Standard Deviation aggregators

[Rustam Hashimov (JIRA)]

Rustam Hashimov created SOLR-10082:
--

 Summary: Add Variance and  Standard Deviation aggregators
 Key: SOLR-10082
 URL: https://issues.apache.org/jira/browse/SOLR-10082
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: faceting
Affects Versions: master (7.0)
Reporter: Rustam Hashimov
Priority: Minor


This is a ticket to add variance and  standard deviation aggregators to json 
facet.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] lucene-solr pull request #155: SOLR-10082 : Add Variance and Standard Deviat...

[rustamhsmv]

GitHub user rustamhsmv opened a pull request:

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

SOLR-10082 : Add Variance and Standard Deviation aggregators



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rustamhsmv/lucene-solr VarianceStddev

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/155.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #155


commit 6e1e1ac0296400bd87def4fa62ebab9541c1f9a4
Author: rustamhsmv 
Date:   2017-01-31T22:34:05Z

Add Variance and Stddev Aggregators

commit 672138bf34bb7eee43add03e5d04aaff25955d17
Author: rustamhsmv 
Date:   2017-01-31T22:40:20Z

Merge branch 'master' of https://github.com/rustamhsmv/lucene-solr into 
VarianceStddev




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3809 - Still Unstable!

[Steve Rowe]

Uwe,

Too many open files - you maybe need to configure the macOS VM?:

> On Jan 31, 2017, at 4:53 PM, Policeman Jenkins Server  
> wrote:
> 
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3809/
[…]
> FAILED:  org.apache.solr.cloud.SimpleCollectionCreateDeleteTest.test
> 
> Error Message:
> java.io.IOException: Couldn't instantiate 
> org.apache.zookeeper.ClientCnxnSocketNIO
> 
> Stack Trace:
> org.apache.solr.common.SolrException: java.io.IOException: Couldn't 
> instantiate org.apache.zookeeper.ClientCnxnSocketNIO
>   at 
> __randomizedtesting.SeedInfo.seed([321AC469C3E8746B:BA4EFBB36D141993]:0)
>   at 
> org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:170)
[…]
> Caused by: java.io.IOException: Too many open files
>   at sun.nio.ch.IOUtil.makePipe(Native Method)
>   at sun.nio.ch.KQueueSelectorImpl.(KQueueSelectorImpl.java:84)
>   at 
> sun.nio.ch.KQueueSelectorProvider.openSelector(KQueueSelectorProvider.java:42)
>   at java.nio.channels.Selector.open(Selector.java:227)
>   at 
> org.apache.zookeeper.ClientCnxnSocketNIO.(ClientCnxnSocketNIO.java:43)
>   at sun.reflect.GeneratedConstructorAccessor218.newInstance(Unknown 
> Source)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at java.lang.Class.newInstance(Class.java:442)
>   at 
> org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:1779)
>   ... 43 more

--
Steve
www.lucidworks.com


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

[jira] [Commented] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-10053:
-

[~markrmil...@gmail.com] [~ichattopadhyaya] It turned out to be an issue in 
Hadoop authentication layer (Ref: HADOOP-14044). I have updated the patch to 
ignore this test until the underlying issue is resolved.


> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
> Attachments: fail.log, stdout, stdout, stdout
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10072) The test TestSelectiveWeightCreation appears to be unreliable.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10072:


Yeah, looks like that makes sense.

> The test TestSelectiveWeightCreation appears to be unreliable.
> --
>
> Key: SOLR-10072
> URL: https://issues.apache.org/jira/browse/SOLR-10072
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
> Attachments: stdout, stdout
>
>
> TestSelectiveWeightCreation 17.00% unreliable 30.00 24.66



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-9997) Enable configuring SolrHttpClientBuilder via java system property

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9997:


[~janhoy] Thanks for the review. I have already tested it on MacOS and Windows. 
Please let me know if anything required from my side to move this forward.

> Enable configuring SolrHttpClientBuilder via java system property
> -
>
> Key: SOLR-9997
> URL: https://issues.apache.org/jira/browse/SOLR-9997
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Hrishikesh Gadre
>
> Currently SolrHttpClientBuilder needs to be configured via invoking 
> HttpClientUtil#setHttpClientBuilder(...) API. On the other hand SolrCLI 
> attempts to support configuring SolrHttpClientBuilder via Java system 
> property.  
> https://github.com/apache/lucene-solr/blob/9f58b6cd177f72b226c83adbb965cfe08d61d2fb/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L265
> But after changes for SOLR-4509, this is no longer working. This is because 
> we need to configure HttpClientBuilderFactory which can provide appropriate 
> SolrHttpClientBuilder instance (e.g. Krb5HttpClientBuilder). I verified that 
> SolrCLI does not work in a kerberos enabled cluster. During the testing I 
> also found that SolrCLI is hardcoded to use basic authentication,
> https://github.com/apache/lucene-solr/blob/9f58b6cd177f72b226c83adbb965cfe08d61d2fb/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L156
> This jira is to add support for configuring HttpClientBuilderFactory as a 
> java system property so that SolrCLI as well as other Solr clients can also 
> benefit this. Also we should provide a HttpClientBuilderFactory which support 
> configuring preemptive basic authentication so that we can remove the 
> hardcoded basic auth usage in SolrCLI (and enable it work with kerberos). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10080) Fix some issues reported by findbugs

[Michael Braun (JIRA)]

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

Michael Braun commented on SOLR-10080:
--

In BlobRepository the only use of that synchronized call I can see on first 
glance would be to prevent blobCreator.call from executing twice, but the same 
thing can be accomplished by using .computeIfAbsent. 

> Fix some issues reported by findbugs 
> -
>
> Key: SOLR-10080
> URL: https://issues.apache.org/jira/browse/SOLR-10080
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Priority: Minor
> Attachments: SOLR-10080.patch
>
>
> I ran a findbugs analysis on code and found a lot of issues. I found issues 
> in both lucene and solr, however, I am not sure whether Solr developers 
> should fix issues like this in the lucene code or not.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 3809 - Still Unstable!

[Policeman Jenkins Server]

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

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

Error Message:


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


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

Error Message:
java.io.IOException: Couldn't instantiate 
org.apache.zookeeper.ClientCnxnSocketNIO

Stack Trace:
org.apache.solr.common.SolrException: java.io.IOException: Couldn't instantiate 
org.apache.zookeeper.ClientCnxnSocketNIO
at 

[jira] (SOLR-10072) The test TestSelectiveWeightCreation appears to be unreliable.

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-10072:


Thanks. From delving into 
[lucene/common-build.xml|https://github.com/apache/lucene-solr/blob/master/lucene/common-build.xml#L1281-L1288]
 I think the ant equivalent then would be
{code}
ant beast -Dbeast.iters=30 -Dtests.dups=10 
-Dtestcase=TestSelectiveWeightCreation
{code}

> The test TestSelectiveWeightCreation appears to be unreliable.
> --
>
> Key: SOLR-10072
> URL: https://issues.apache.org/jira/browse/SOLR-10072
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
> Attachments: stdout, stdout
>
>
> TestSelectiveWeightCreation 17.00% unreliable 30.00 24.66



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10023) Improve single unit test run time with ant.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10023:
---

Hmmm, it's embarrassing how long I do things the hard way sometimes. Mark just 
commented that "changing to the module is faster". So I decided to try it. 
Running "ant -Dtestcase=TestLazyCores test" takes about 2.5 minutes when run 
from the root or root/solr. It takes 47 seconds when run from root/solr/core. 
You can't go any farther down than root/solr/core.
Sgh.


> Improve single unit test run time with ant.
> ---
>
> Key: SOLR-10023
> URL: https://issues.apache.org/jira/browse/SOLR-10023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
> Attachments: SOLR-10023-add-test-only-target.patch, 
> SOLR-10023-add-test-only-target.patch, stdout.tar.gz
>
>
> It seems to take 2 minutes and 45 seconds to run a single test with the 
> latest build design and the test itself is only 4 seconds. I've noticed this 
> for a long time, and it seems because ant is running through a billion 
> targets first. 
> I haven't checked yet, so maybe it's a Solr specific issue? I'll check with 
> Lucene and move this issue if necessary.
> There is hopefully something we can do to improve this though. At least we 
> should try and get some sharp minds to take first / second look. If I did not 
> use an IDE so much to run tests, this would drive me nuts.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10081) Web UI (Generate Training Data ) for LTR plugin

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-10081:
---

GitHub user qfdk opened a pull request:

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

SOLR-10081: Web UI (GenerateTrainingData ) for LTR plugin

Hello ,

This is a New Feature for LTR plugin. It will help you to generate the 
training data (HUMAN_JUDGEMENT) by using score between 0-4. Live demo 
http://ltr.qfdk.me

Thank you.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/qfdk/lucene-solr webui

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/154.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #154


commit c45bb40a8cca844540f2863202ac44aa147862d2
Author: qfdk 
Date:   2017-01-31T21:26:39Z

[Update] add GenTraingDataSolr webUI




> Web UI (Generate Training Data ) for LTR plugin
> ---
>
> Key: SOLR-10081
> URL: https://issues.apache.org/jira/browse/SOLR-10081
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: qfdk
>
> This is a New Feature for LTR plugin. It will help you to generate the 
> training data (HUMAN_JUDGEMENT) by using score between 0-4. Live demo 
> http://ltr.qfdk.me



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] lucene-solr pull request #154: SOLR-10081: Web UI (GenerateTrainingData ) fo...

[qfdk]

GitHub user qfdk opened a pull request:

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

SOLR-10081: Web UI (GenerateTrainingData ) for LTR plugin

Hello ,

This is a New Feature for LTR plugin. It will help you to generate the 
training data (HUMAN_JUDGEMENT) by using score between 0-4. Live demo 
http://ltr.qfdk.me

Thank you.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/qfdk/lucene-solr webui

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/154.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #154


commit c45bb40a8cca844540f2863202ac44aa147862d2
Author: qfdk 
Date:   2017-01-31T21:26:39Z

[Update] add GenTraingDataSolr webUI




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] (SOLR-10081) Web UI (Generate Training Data ) for LTR plugin

[qfdk (JIRA)]

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

qfdk updated SOLR-10081:

Description: This is a New Feature for LTR plugin. It will help you to 
generate the training data (HUMAN_JUDGEMENT) by using score between 0-4. Live 
demo http://ltr.qfdk.me  (was: This is a New Feature for LTR plugin. It will 
help you to generate the training data (HUMAN_JUDGEMENT) by using score between 
0-4. Try for live http://ltr.qfdk.me)

> Web UI (Generate Training Data ) for LTR plugin
> ---
>
> Key: SOLR-10081
> URL: https://issues.apache.org/jira/browse/SOLR-10081
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: qfdk
>
> This is a New Feature for LTR plugin. It will help you to generate the 
> training data (HUMAN_JUDGEMENT) by using score between 0-4. Live demo 
> http://ltr.qfdk.me



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10081) Web UI (Generate Training Data ) for LTR plugin

[qfdk (JIRA)]

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

qfdk updated SOLR-10081:

Description: This is a New Feature for LTR plugin. It will help you to 
generate the training data (HUMAN_JUDGEMENT) by using score between 0-4. Try 
for live http://ltr.qfdk.me  (was: This is a New Feature for LTR plugin. It 
will help you to generate the training data (HUMAN_JUDGEMENT) by using score 
between 0-4. )

> Web UI (Generate Training Data ) for LTR plugin
> ---
>
> Key: SOLR-10081
> URL: https://issues.apache.org/jira/browse/SOLR-10081
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: qfdk
>
> This is a New Feature for LTR plugin. It will help you to generate the 
> training data (HUMAN_JUDGEMENT) by using score between 0-4. Try for live 
> http://ltr.qfdk.me



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-5344) SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to time

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-5344:
--

There's a new reproducing failure on ASF Jenkins: 
[https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1227] - the 
expected hit count range is [3,13] while the actual is 14:

{noformat}
Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=SpellCheckCollatorTest -Dtests.method=testEstimatedHitCounts 
-Dtests.seed=F75C4ADA09152961 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=lt-LT -Dtests.timezone=CNT -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.33s J2 | SpellCheckCollatorTest.testEstimatedHitCounts <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
query
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([F75C4ADA09152961:C6E7F4EFAC2A39B1]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:857)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:824)
   [junit4]>at 
org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts(SpellCheckCollatorTest.java:569)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//lst[@name='spellcheck']/lst[@name='collations']/lst[@name='collation']/int[@name='hits'
 and 3 <= . and . <= 13]
   [junit4]>xml response was: 
   [junit4]> 
   [junit4]> 021918everyotherteststop:everyother14everyother
   [junit4]> 
   [junit4]>request 
was:spellcheck=true=direct=1=true=1=1=true=spellCheckCompRH=teststop:everother=5
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:850)
   [junit4]>... 41 more
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{start1=Lucene50(blocksize=128), 
range_facet_l_dv=PostingsFormat(name=MockRandom), 
lowerfilt1=Lucene50(blocksize=128), 
multiDefault=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
 
teststop=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
 intDefault=PostingsFormat(name=Memory), 
range_facet_l=PostingsFormat(name=Memory), 
lowerfilt1and2=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
 end4=Lucene50(blocksize=128), 
end3=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
 end2=PostingsFormat(name=MockRandom), end1=PostingsFormat(name=Memory), 
lowerfilt=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
 gram1=PostingsFormat(name=Memory), id=PostingsFormat(name=MockRandom), 
range_facet_i_dv=PostingsFormat(name=Memory), 
gram2=PostingsFormat(name=MockRandom), 
gram3=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
 start3=PostingsFormat(name=MockRandom), gram4=Lucene50(blocksize=128), 
start2=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
 word=PostingsFormat(name=Memory), timestamp=PostingsFormat(name=Memory), 
start4=PostingsFormat(name=Memory)}, 
docValues:{range_facet_l_dv=DocValuesFormat(name=Asserting), 
range_facet_i_dv=DocValuesFormat(name=Lucene70), 
intDvoDefault=DocValuesFormat(name=Direct), 
timestamp=DocValuesFormat(name=Lucene70)}, maxPointsInLeafNode=549, 
maxMBSortInHeap=6.553211483764787, sim=RandomSimilarity(queryNorm=false): {}, 
locale=lt-LT, timezone=CNT
   [junit4]   2> NOTE: Linux 3.13.0-85-generic amd64/Oracle Corporation 
1.8.0_102 (64-bit)/cpus=4,threads=1,free=254106768,total=532152320
{noformat}

> SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to 
> time
> 
>
> Key: SOLR-5344
> URL: https://issues.apache.org/jira/browse/SOLR-5344
> Project: Solr
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: James Dyer
> Attachments: SOLR-5344.patch
>
>
> Doesn't happen very often, but maybe one I can fix. I'll look into it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-9861) Support Cross Data Center Replication under HDFS

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-9861:


I looked into this some and just sharing what I found in case it helps:
* CDCR has CdcrUpdateLog and CdcrTransactionLog which do a bulk of the CDCR work
* HDFS has HdfsUpdateLog and HdfsTransactionLog which do a bulk of the HDFS work
* CdcrUpdateLog and HdfsUpdateLog both extend the UpdateLog class
* CdcrTransactionLog and CdcrUpdateLog both extend the TransactionLog class
* CdcrUpdateLog and CdcrTransactionLog both deal with Linux files

The items above make it hard for the existing CDCR implementation classes to 
reuse the HDFS implementation classes. It would probably be useful to refactor 
some first to allow for more reuse between classes. The UpdateLog class is 
pretty big and its not clear what all the pieces are for. There are inner 
classes and enums within the UpdateLog class used elsewhere.

> Support Cross Data Center Replication under HDFS
> 
>
> Key: SOLR-9861
> URL: https://issues.apache.org/jira/browse/SOLR-9861
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 6.3
>Reporter: Gero Willmes
>
> Currently Solr Cloud does not support CDCR under HDFS (according to 
> http://search-lucene.com/m/Solr/eHNlLSriaVCpuU1?subj=Re+Using+Solr+CDCR+with+HdfsDirectoryFactory).
>  
> If the CDCR configuration is performed according to
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=62687462
> and at the same time the HdfsDirectoryFactory is configured on both Source 
> cluster and Target cluster according to
> https://cwiki.apache.org/confluence/display/solr/Running+Solr+on+HDFS
> it leads to the following error message during reload of the collection 
> “collection_source” of the source cluster:
> {code}
> 2016-11-23 12:05:35.604 ERROR (qtp1134712904-8045) [c:collection_source 
> s:shard1 r:core_node1 x:collection_source_shard1_replica1] 
> o.a.s.s.HttpSolrCall null:org.apache.solr.common.SolrException: Error 
> handling 'reload' action
> at 
> org.apache.solr.handler.admin.CoreAdminOperation$3.call(CoreAdminOperation.java:150)
> at 
> org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:367)
> at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:158)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
> at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:663)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:445)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at 
> 

[jira] (SOLR-10081) Web UI (Generate Training Data ) for LTR plugin

[qfdk (JIRA)]

qfdk created SOLR-10081:
---

 Summary: Web UI (Generate Training Data ) for LTR plugin
 Key: SOLR-10081
 URL: https://issues.apache.org/jira/browse/SOLR-10081
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: qfdk


This is a New Feature for LTR plugin. It will help you to generate the training 
data (HUMAN_JUDGEMENT) by using score between 0-4. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-9861) Support Cross Data Center Replication under HDFS

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-9861:
---
Description: 
Currently Solr Cloud does not support CDCR under HDFS (according to 
http://search-lucene.com/m/Solr/eHNlLSriaVCpuU1?subj=Re+Using+Solr+CDCR+with+HdfsDirectoryFactory).
 
If the CDCR configuration is performed according to

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=62687462

and at the same time the HdfsDirectoryFactory is configured on both Source 
cluster and Target cluster according to

https://cwiki.apache.org/confluence/display/solr/Running+Solr+on+HDFS

it leads to the following error message during reload of the collection 
“collection_source” of the source cluster:
{code}
2016-11-23 12:05:35.604 ERROR (qtp1134712904-8045) [c:collection_source 
s:shard1 r:core_node1 x:collection_source_shard1_replica1] o.a.s.s.HttpSolrCall 
null:org.apache.solr.common.SolrException: Error handling 'reload' action
at 
org.apache.solr.handler.admin.CoreAdminOperation$3.call(CoreAdminOperation.java:150)
at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:367)
at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:158)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:663)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:445)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:518)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.solr.common.SolrException: Unable to reload core 
[collection_source_shard1_replica1]
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:920)
at 
org.apache.solr.handler.admin.CoreAdminOperation$3.call(CoreAdminOperation.java:148)
... 31 more
Caused by: org.apache.solr.common.SolrException: Solr instance is not 
configured with the cdcr update log.
{code}
However, the solr instance was configured correctly. CDCR should work in the 
same way with HdfsDirectoryFactory as it works with StandardDirectoryFactory or 
NRTCachingDirectoryFactory.


  was:
Currently Solr Cloud does not support CDCR under HDFS (according to 
http://search-lucene.com/m/Solr/eHNlLSriaVCpuU1?subj=Re+Using+Solr+CDCR+with+HdfsDirectoryFactory).
 
If the CDCR configuration is performed according to

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=62687462

and at the same time the HdfsDirectoryFactory is configured on both Source 
cluster and Target cluster 

[jira] (SOLR-10072) The test TestSelectiveWeightCreation appears to be unreliable.

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-10072 at 1/31/17 9:36 PM:
-

I use this beasting script: 
https://gist.githubusercontent.com/markrmiller/dbdb792216dc98b018ad/raw/78d1f5c97021455ddb0eb2b3ba93b44589089244/gistfile1.sh

I end up basically doing:

cd lucene-solr/solr
bash beast.sh -i 30 -p 10 TestSelectiveWeightCreation

Each JVM can use 512MB of RAM though, so 10 can be RAM hungry. It can also be 
overkill if you don't have enough processors. I use those numbers for a machine 
with 16 cores.

I believe the built in ant based beast target will also allow you to specify 
how many times to run in parallel, but I'm not familiar with it currently.


was (Author: markrmil...@gmail.com):
I use this beasting script: 
https://gist.githubusercontent.com/markrmiller/dbdb792216dc98b018ad/raw/78d1f5c97021455ddb0eb2b3ba93b44589089244/gistfile1.sh

I end up basically doing:

cd lucene-solr/solr
bash beast.sh -i 30 -p 10 TestSelectiveWeightCreation

Each JVM can use 512MB of RAM though, so 10 can be RAM hungry. It can also be 
overkill if you don't have enough processors. I use those numbers for a machine 
with 16 processors.

I believe the built in ant based beast target will also allow you to specify 
how many times to run in parallel, but I'm not familiar with it currently.

> The test TestSelectiveWeightCreation appears to be unreliable.
> --
>
> Key: SOLR-10072
> URL: https://issues.apache.org/jira/browse/SOLR-10072
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
> Attachments: stdout, stdout
>
>
> TestSelectiveWeightCreation 17.00% unreliable 30.00 24.66



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10080) Fix some issues reported by findbugs

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10080:
---

Pushkar:

One technique people use for marking code that needs to be cleaned up is to add 
a //nocommit comment to it. The precommit step will flag all //nocommit entries 
and fail the build so it's a sure-fire way to make sure any lingering questions 
are cleaned up.

Of course then when you're all ready to add it you have to run the 'ant 
precommit' step, but even if you don't the next Jenkins build will so...

No big deal, just FYI...



> Fix some issues reported by findbugs 
> -
>
> Key: SOLR-10080
> URL: https://issues.apache.org/jira/browse/SOLR-10080
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Priority: Minor
> Attachments: SOLR-10080.patch
>
>
> I ran a findbugs analysis on code and found a lot of issues. I found issues 
> in both lucene and solr, however, I am not sure whether Solr developers 
> should fix issues like this in the lucene code or not.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10072) The test TestSelectiveWeightCreation appears to be unreliable.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10072:


Though, actually, I've recently learned it is much more efficient to move into 
the module with the test:

cd lucene-solr/solr/contrib/ltr
bash beast.sh -i 30 -p 10 TestSelectiveWeightCreation

> The test TestSelectiveWeightCreation appears to be unreliable.
> --
>
> Key: SOLR-10072
> URL: https://issues.apache.org/jira/browse/SOLR-10072
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
> Attachments: stdout, stdout
>
>
> TestSelectiveWeightCreation 17.00% unreliable 30.00 24.66



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10072) The test TestSelectiveWeightCreation appears to be unreliable.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10072:


I use this beasting script: 
https://gist.githubusercontent.com/markrmiller/dbdb792216dc98b018ad/raw/78d1f5c97021455ddb0eb2b3ba93b44589089244/gistfile1.sh

I end up basically doing:

cd lucene-solr/solr
bash beast.sh -i 30 -p 10 TestSelectiveWeightCreation

Each JVM can use 512MB of RAM though, so 10 can be RAM hungry. It can also be 
overkill if you don't have enough processors. I use those numbers for a machine 
with 16 processors.

I believe the built in ant based beast target will also allow you to specify 
how many times to run in parallel, but I'm not familiar with it currently.

> The test TestSelectiveWeightCreation appears to be unreliable.
> --
>
> Key: SOLR-10072
> URL: https://issues.apache.org/jira/browse/SOLR-10072
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
> Attachments: stdout, stdout
>
>
> TestSelectiveWeightCreation 17.00% unreliable 30.00 24.66



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10080) Fix some issues reported by findbugs

[Pushkar Raste (JIRA)]

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

Pushkar Raste updated SOLR-10080:
-
Attachment: SOLR-10080.patch

I have fixed some of the issues reported by findbugs (and added some 
descriptive comments in some cases).

In some cases when, I wasn't sure if code findbugs reported as issue was 
intentionally written like that or not.

Once, I get feedback, I will polish the patch to remove unwanted comments (or 
remove code that I have just commented for now)

> Fix some issues reported by findbugs 
> -
>
> Key: SOLR-10080
> URL: https://issues.apache.org/jira/browse/SOLR-10080
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Priority: Minor
> Attachments: SOLR-10080.patch
>
>
> I ran a findbugs analysis on code and found a lot of issues. I found issues 
> in both lucene and solr, however, I am not sure whether Solr developers 
> should fix issues like this in the lucene code or not.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10080) Fix some issues reported by findbugs

[Pushkar Raste (JIRA)]

Pushkar Raste created SOLR-10080:


 Summary: Fix some issues reported by findbugs 
 Key: SOLR-10080
 URL: https://issues.apache.org/jira/browse/SOLR-10080
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Pushkar Raste
Priority: Minor


I ran a findbugs analysis on code and found a lot of issues. I found issues in 
both lucene and solr, however, I am not sure whether Solr developers should fix 
issues like this in the lucene code or not.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10072) The test TestSelectiveWeightCreation appears to be unreliable.

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-10072:


Thanks Mark. When you say "12 at a time" or "10 at a time", how can I specify 
the same, to try and reproduce locally, before and after any changes?

> The test TestSelectiveWeightCreation appears to be unreliable.
> --
>
> Key: SOLR-10072
> URL: https://issues.apache.org/jira/browse/SOLR-10072
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
> Attachments: stdout, stdout
>
>
> TestSelectiveWeightCreation 17.00% unreliable 30.00 24.66



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] lucene-solr pull request #153: Fix issues reported by findbugs

[praste]

GitHub user praste opened a pull request:

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

Fix issues reported by findbugs



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/praste/lucene-solr findbugs-ananlysis

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/153.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #153


commit a9475063a19f8a16f87b01c05c9daa08af444a0b
Author: Pushkar Raste 
Date:   2017-01-31T21:01:20Z

Findbugs analysis




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] (SOLR-10072) The test TestSelectiveWeightCreation appears to be unreliable.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10072:


I got 2 fails out of the 30, both are attached.

> The test TestSelectiveWeightCreation appears to be unreliable.
> --
>
> Key: SOLR-10072
> URL: https://issues.apache.org/jira/browse/SOLR-10072
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
> Attachments: stdout, stdout
>
>
> TestSelectiveWeightCreation 17.00% unreliable 30.00 24.66



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10072) The test TestSelectiveWeightCreation appears to be unreliable.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-10072:
---
Attachment: stdout
stdout

> The test TestSelectiveWeightCreation appears to be unreliable.
> --
>
> Key: SOLR-10072
> URL: https://issues.apache.org/jira/browse/SOLR-10072
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
> Attachments: stdout, stdout
>
>
> TestSelectiveWeightCreation 17.00% unreliable 30.00 24.66



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Apache Jenkins Server]

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

6 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ConcurrentDeleteAndCreateCollectionTest

Error Message:
ObjectTracker found 10 object(s) that were not released!!! [InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:268)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:277)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:215)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:202)
  at 
org.apache.solr.client.solrj.impl.HttpSolrClient.(HttpSolrClient.java:211)
  at 
org.apache.solr.client.solrj.impl.HttpSolrClient.(HttpSolrClient.java:228)
  at 
org.apache.solr.client.solrj.impl.HttpSolrClient$Builder.build(HttpSolrClient.java:864)
  at org.apache.solr.SolrTestCaseJ4.getHttpSolrClient(SolrTestCaseJ4.java:2329) 
 at 
org.apache.solr.cloud.ConcurrentDeleteAndCreateCollectionTest.testConcurrentCreateAndDeleteDoesNotFail(ConcurrentDeleteAndCreateCollectionTest.java:62)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)  
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)  at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
  at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
  at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
  at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
  at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
  at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
  at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
  at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
  at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
  at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
  at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
  at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
  at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
  at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
  at 

[jira] (SOLR-10072) The test TestSelectiveWeightCreation appears to be unreliable.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10072:


I beasted tests at 12 at a time, but 10 may be a more reasonable number as 12 
seems to really start pushing RAM exhaustion. I'll rerun this test at 10 at a 
time and post fail logs.

> The test TestSelectiveWeightCreation appears to be unreliable.
> --
>
> Key: SOLR-10072
> URL: https://issues.apache.org/jira/browse/SOLR-10072
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
>
> TestSelectiveWeightCreation 17.00% unreliable 30.00 24.66



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10077) TestManagedFeatureStore extends LuceneTestCase, but has no tests and just hosts a static method.

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-10077:


https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr/src/test/org/apache/solr/ltr/store/rest/TestManagedFeatureStore.java

> TestManagedFeatureStore extends LuceneTestCase, but has no tests and just 
> hosts a static method.
> 
>
> Key: SOLR-10077
> URL: https://issues.apache.org/jira/browse/SOLR-10077
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
>Priority: Minor
>
> We should probably just put this static method somewhere else?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10077) TestManagedFeatureStore extends LuceneTestCase, but has no tests and just hosts a static method.

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-10077:
--

Assignee: Christine Poerschke

> TestManagedFeatureStore extends LuceneTestCase, but has no tests and just 
> hosts a static method.
> 
>
> Key: SOLR-10077
> URL: https://issues.apache.org/jira/browse/SOLR-10077
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
>Priority: Minor
>
> We should probably just put this static method somewhere else?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10072) The test TestSelectiveWeightCreation appears to be unreliable.

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-10072:
--

Assignee: Christine Poerschke

> The test TestSelectiveWeightCreation appears to be unreliable.
> --
>
> Key: SOLR-10072
> URL: https://issues.apache.org/jira/browse/SOLR-10072
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
>
> TestSelectiveWeightCreation 17.00% unreliable 30.00 24.66



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10063) TestShardHandlerFactory appears to hang when I attempt to beast it.

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-10063:


Hi Mark, could you share the exact beast command(s) you used for the SOLR-10032 
report? I just ran
{code}
ant beast -Dbeast.iters=100 -Dtestcase=TestShardHandlerFactory
{code}
here for 
[TestShardHandlerFactory|https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/core/TestShardHandlerFactory.java]
 and it was fine and the test itself seems very uninteresting and hence am 
wondering about interaction between tests or how to more aggressively beast? 
Thanks.

> TestShardHandlerFactory appears to hang when I attempt to beast it.
> ---
>
> Key: SOLR-10063
> URL: https://issues.apache.org/jira/browse/SOLR-10063
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2774/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseSerialGC

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

Error Message:
document count mismatch.  control=1004 sum(shards)=1003 cloudClient=1003

Stack Trace:
java.lang.AssertionError: document count mismatch.  control=1004 
sum(shards)=1003 cloudClient=1003
at 
__randomizedtesting.SeedInfo.seed([8BB1CF91255D0B52:3E5F04B8BA166AA]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1323)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:228)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] (SOLR-9933) support span queries in SolrCoreParser

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9933: SolrCoreParser now supports configuration of custom SpanQueryBuilder 
classes. (Daniel Collins, Christine Poerschke)


> support span queries in SolrCoreParser
> --
>
> Key: SOLR-9933
> URL: https://issues.apache.org/jira/browse/SOLR-9933
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9933.patch
>
>
> starting point: [~dancollins]'s [pull 
> request|https://github.com/bloomberg/lucene-solr/pull/188]
> next step: test case(s) to demonstrate what is currently not supported



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10054) Core swapping doesn't work with new metrics changes in place

[Andrzej Bialecki (JIRA)]

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

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

Patch relative to branch_6x.

> Core swapping doesn't work with new metrics changes in place
> 
>
> Key: SOLR-10054
> URL: https://issues.apache.org/jira/browse/SOLR-10054
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0), 6.4.0
>Reporter: Shawn Heisey
>Assignee: Andrzej Bialecki 
> Attachments: SOLR-10054.patch, solr64coreswap1.png, 
> solr64coreswap2.png, solr64coreswap3.png
>
>
> The new 6.4.0 version includes some significant changes having to do with 
> metrics.  These changes have broken core swapping.  Will attach some 
> screenshots.
> For the screenshots that I will attach, I started Solr directly from the 
> 6.4.0 download on Windows 7 (bin\solr start).  Then I created a "foo" core 
> and a "bar" core, each from a different configset, using the bin\solr command.
>  * Screenshot 1: you can see the two cores in CoreAdmin.
>  * Screenshot 2: Attempting to swap the cores, an error message appears about 
> a metric already existing for the ping handler.
>  * Screenshot 3: Clicking somewhere else and then back to CoreAdmin shows 
> that both cores have the same name -- bar.
>  * If Solr is stopped and then started back up, the admin UI looks like 
> screenshot 1 again -- the change that caused two cores with the same name 
> only took place within the running Solr and did not update core.properties 
> files.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10054) Core swapping doesn't work with new metrics changes in place

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-10054:
--

Yeah, we definitely need more test coverage of such fundamental 
functionality... :(

The issue turned out to be less trivial than I thought. When rename or swap 
core is requested the metrics subsystem needs to preserve metrics that are 
already accumulated under the old core name (we use separate registries per 
core). Since metrics' initialization occurs when core is constructed we can't 
easily re-register all {{SolrMetricProducer}}-s in the new registry, so the 
existing code tried to move actual {{Metric}} instances from the old to the new 
repository. The problem was that more or less the same metric names already 
existed in the target repository, because they were registered there by the 
other core's producers - and vice versa.

The solution was to implement a dedicated operation 
{{SolrMetricManager.swap(name1, name2)}} that knows how to atomically (or 
rather under proper locking) swap these two registries, without moving metric 
instances between registries.

I also added {{TestCoreAdmin.testCoreSwap}} and {{testValidCoreRename}}, and 
extended {{CoreAdminRequest}} to support the swap operation.

> Core swapping doesn't work with new metrics changes in place
> 
>
> Key: SOLR-10054
> URL: https://issues.apache.org/jira/browse/SOLR-10054
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0), 6.4.0
>Reporter: Shawn Heisey
>Assignee: Andrzej Bialecki 
> Attachments: solr64coreswap1.png, solr64coreswap2.png, 
> solr64coreswap3.png
>
>
> The new 6.4.0 version includes some significant changes having to do with 
> metrics.  These changes have broken core swapping.  Will attach some 
> screenshots.
> For the screenshots that I will attach, I started Solr directly from the 
> 6.4.0 download on Windows 7 (bin\solr start).  Then I created a "foo" core 
> and a "bar" core, each from a different configset, using the bin\solr command.
>  * Screenshot 1: you can see the two cores in CoreAdmin.
>  * Screenshot 2: Attempting to swap the cores, an error message appears about 
> a metric already existing for the ping handler.
>  * Screenshot 3: Clicking somewhere else and then back to CoreAdmin shows 
> that both cores have the same name -- bar.
>  * If Solr is stopped and then started back up, the admin UI looks like 
> screenshot 1 again -- the change that caused two cores with the same name 
> only took place within the running Solr and did not update core.properties 
> files.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-10053:
---

Github user hgadre commented on the issue:

https://github.com/apache/lucene-solr/pull/150
  
@romseygeek Thanks for the pointer. Will keep in mind for future. BTW I 
don't think we are going to commit these logging changes. 


> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
> Attachments: fail.log, stdout, stdout, stdout
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] lucene-solr issue #150: [SOLR-10053] Logging improvements for troubleshootin...

[hgadre]

Github user hgadre commented on the issue:

https://github.com/apache/lucene-solr/pull/150
  
@romseygeek Thanks for the pointer. Will keep in mind for future. BTW I 
don't think we are going to commit these logging changes. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] (SOLR-10079) TestInPlaceUpdatesDistrib failure

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya reassigned SOLR-10079:
---

Assignee: Ishan Chattopadhyaya

> TestInPlaceUpdatesDistrib failure
> -
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
> reproduces for me:
> {noformat}
> Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
> -Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 
> 79], now: [78, 78, 78]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:543)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
> id=PostingsFormat(name=Asserting), 
> id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
> docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
> id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
> title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
> id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
>  inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
> inplace_updatable_int=DocValuesFormat(name=Direct), 
> inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=sr-Latn-RS, 
> timezone=America/Grand_Turk
>[junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=12,threads=1,free=107734480,total=518979584
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10079) TestInPlaceUpdatesDistrib failure

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10079:
-

Thanks Steve. I'm able to reproduce it and looking into it.

> TestInPlaceUpdatesDistrib failure
> -
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
> reproduces for me:
> {noformat}
> Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
> -Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 
> 79], now: [78, 78, 78]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:543)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
> id=PostingsFormat(name=Asserting), 
> id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
> docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
> id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
> title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
> id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
>  inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
> inplace_updatable_int=DocValuesFormat(name=Direct), 
> inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=sr-Latn-RS, 
> timezone=America/Grand_Turk
>[junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=12,threads=1,free=107734480,total=518979584
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] lucene-solr pull request #149: Cleanup snapshot metadata during collection d...

[hgadre]

Github user hgadre closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] (SOLR-9933) support span queries in SolrCoreParser

[ASF subversion and git services (JIRA)]

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

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

Commit 746786636404cdb8ce505ed0ed02b8d9144ab6c4 in lucene-solr's branch 
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7467866 ]

SOLR-9933: SolrCoreParser now supports configuration of custom SpanQueryBuilder 
classes. (Daniel Collins, Christine Poerschke)


> support span queries in SolrCoreParser
> --
>
> Key: SOLR-9933
> URL: https://issues.apache.org/jira/browse/SOLR-9933
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9933.patch
>
>
> starting point: [~dancollins]'s [pull 
> request|https://github.com/bloomberg/lucene-solr/pull/188]
> next step: test case(s) to demonstrate what is currently not supported



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (LUCENE-7672) CachingNaiveBayesClassifier doesn't compute log prior.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7672:


GitHub user QuasiChameleon opened a pull request:

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

Added log prior calculations in CachingNaiveBayesClassifier.

Jira issue : 
[LUCENE-7672](https://issues.apache.org/jira/browse/LUCENE-7672)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/QuasiChameleon/lucene-solr master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/152.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #152


commit 4d2d6c91fcd1eb8214ac3c9e5ec8a2c07d0d0374
Author: Kevin Crosby 
Date:   2017-01-31T18:05:20Z

Added log prior calculations in CachingNaiveBayesClassifier.




> CachingNaiveBayesClassifier doesn't compute log prior.
> --
>
> Key: LUCENE-7672
> URL: https://issues.apache.org/jira/browse/LUCENE-7672
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/classification
>Affects Versions: master (7.0), 6.3, 6.4, 6.5, 6.4.1, 6.5.0
>Reporter: Kevin Crosby
>  Labels: newbie, patch
> Fix For: master (7.0)
>
> Attachments: LUCENE-7672.patch
>
>
> The CachingNaiveBayesClassifier gives different results than the 
> SimpleNaiveBayesClassifier.  This is due to the fact that the 
> CachineNaiveBayesClassifier does not calculate the log prior on the class 
> (category) names, as it should.
> This bug has been fixed, and a patch has been attached to this issue.
> This affects master, as well as previous releases up to version 6.4.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] lucene-solr pull request #152: Added log prior calculations in CachingNaiveB...

[QuasiChameleon]

GitHub user QuasiChameleon opened a pull request:

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

Added log prior calculations in CachingNaiveBayesClassifier.

Jira issue : 
[LUCENE-7672](https://issues.apache.org/jira/browse/LUCENE-7672)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/QuasiChameleon/lucene-solr master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/152.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #152


commit 4d2d6c91fcd1eb8214ac3c9e5ec8a2c07d0d0374
Author: Kevin Crosby 
Date:   2017-01-31T18:05:20Z

Added log prior calculations in CachingNaiveBayesClassifier.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] (SOLR-9248) HttpSolrClient not compatible with compression option

[Michael Braun (JIRA)]

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

Michael Braun commented on SOLR-9248:
-

Is this still affecting current 6.x versions of Solr? 

> HttpSolrClient not compatible with compression option
> -
>
> Key: SOLR-9248
> URL: https://issues.apache.org/jira/browse/SOLR-9248
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 5.5, 5.5.1
>Reporter: Gary Lee
> Attachments: CompressedConnectionTest.java
>
>
> Since Solr 5.5, using the compression option 
> (solrClient.setAllowCompression(true)) causes the HTTP client to quickly run 
> out of connections in the connection pool. After debugging through this, we 
> found that the GZIPInputStream is incompatible with changes to how the 
> response input stream is closed in 5.5. It is at this point when the 
> GZIPInputStream throws an EOFException, and while this is silently eaten up, 
> the net effect is that the stream is never closed, leaving the connection 
> open. After a number of requests, the pool is exhausted and no further 
> requests can be served.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (LUCENE-7672) CachingNaiveBayesClassifier doesn't compute log prior.

[Kevin Crosby (JIRA)]

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

Kevin Crosby updated LUCENE-7672:
-
Description: 
The CachingNaiveBayesClassifier gives different results than the 
SimpleNaiveBayesClassifier.  This is due to the fact that the 
CachineNaiveBayesClassifier does not calculate the log prior on the class 
(category) names, as it should.

This bug has been fixed, and a patch has been attached to this issue.

This affects master, as well as previous releases up to version 6.4.

  was:
The CachingNaiveBayesClassifier gives different results than the 
SimpleNaiveBayesClassifier.  This is due to the fact that the 
CachineNaiveBayesClassifier does not calculate the log prior on the class 
(category) names, as it should.

This bug has been fixed, and a patch will be attached to this issue.


> CachingNaiveBayesClassifier doesn't compute log prior.
> --
>
> Key: LUCENE-7672
> URL: https://issues.apache.org/jira/browse/LUCENE-7672
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/classification
>Affects Versions: master (7.0), 6.3, 6.4, 6.5, 6.4.1, 6.5.0
>Reporter: Kevin Crosby
>  Labels: newbie, patch
> Fix For: master (7.0)
>
> Attachments: LUCENE-7672.patch
>
>
> The CachingNaiveBayesClassifier gives different results than the 
> SimpleNaiveBayesClassifier.  This is due to the fact that the 
> CachineNaiveBayesClassifier does not calculate the log prior on the class 
> (category) names, as it should.
> This bug has been fixed, and a patch has been attached to this issue.
> This affects master, as well as previous releases up to version 6.4.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-10053:
---
Attachment: stdout

> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
> Attachments: fail.log, stdout, stdout, stdout
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (LUCENE-7672) CachingNaiveBayesClassifier doesn't compute log prior.

[Kevin Crosby (JIRA)]

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

Kevin Crosby updated LUCENE-7672:
-
Attachment: LUCENE-7672.patch

> CachingNaiveBayesClassifier doesn't compute log prior.
> --
>
> Key: LUCENE-7672
> URL: https://issues.apache.org/jira/browse/LUCENE-7672
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/classification
>Affects Versions: master (7.0), 6.3, 6.4, 6.5, 6.4.1, 6.5.0
>Reporter: Kevin Crosby
>  Labels: newbie, patch
> Fix For: master (7.0)
>
> Attachments: LUCENE-7672.patch
>
>
> The CachingNaiveBayesClassifier gives different results than the 
> SimpleNaiveBayesClassifier.  This is due to the fact that the 
> CachineNaiveBayesClassifier does not calculate the log prior on the class 
> (category) names, as it should.
> This bug has been fixed, and a patch will be attached to this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10053:


another fail log attached after the patch.

> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
> Attachments: fail.log, stdout, stdout, stdout
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10079) TestInPlaceUpdatesDistrib failure

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-10079:
-

 Summary: TestInPlaceUpdatesDistrib failure
 Key: SOLR-10079
 URL: https://issues.apache.org/jira/browse/SOLR-10079
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Steve Rowe


>From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
>reproduces for me:

{noformat}
Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
-Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
   [junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 79], 
now: [78, 78, 78]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
   [junit4]>at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
   [junit4]>at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
   [junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   [junit4]>at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]>at 
java.base/java.lang.reflect.Method.invoke(Method.java:543)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
   [junit4]>at java.base/java.lang.Thread.run(Thread.java:844)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
id=PostingsFormat(name=Asserting), 
id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
 inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
inplace_updatable_int=DocValuesFormat(name=Direct), 
inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
sim=RandomSimilarity(queryNorm=true): {}, locale=sr-Latn-RS, 
timezone=America/Grand_Turk
   [junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
(32-bit)/cpus=12,threads=1,free=107734480,total=518979584
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (LUCENE-7672) CachingNaiveBayesClassifier doesn't compute log prior.

[Kevin Crosby (JIRA)]

Kevin Crosby created LUCENE-7672:


 Summary: CachingNaiveBayesClassifier doesn't compute log prior.
 Key: LUCENE-7672
 URL: https://issues.apache.org/jira/browse/LUCENE-7672
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/classification
Affects Versions: 6.3, master (7.0), 6.4, 6.5, 6.4.1, 6.5.0
Reporter: Kevin Crosby
 Fix For: master (7.0)


The CachingNaiveBayesClassifier gives different results than the 
SimpleNaiveBayesClassifier.  This is due to the fact that the 
CachineNaiveBayesClassifier does not calculate the log prior on the class 
(category) names, as it should.

This bug has been fixed, and a patch will be attached to this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre edited comment on SOLR-10053 at 1/31/17 5:52 PM:
--

[~markrmil...@gmail.com]

bq. I still seem to see fails even with the patch. Two fail logs attached.

Yes the patch does not provide the fix yet. It just enables debug logging for 
troubleshooting. Let me take a look at the logs and get back to you.


was (Author: hgadre):
[~markmil...@gmail.com]

bq. I still seem to see fails even with the patch. Two fail logs attached.

Yes the patch does not provide the fix yet. It just enables debug logging for 
troubleshooting. Let me take a look at the logs and get back to you.

> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
> Attachments: fail.log, stdout, stdout
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-10053:
-

[~markmil...@gmail.com]

bq. I still seem to see fails even with the patch. Two fail logs attached.

Yes the patch does not provide the fix yet. It just enables debug logging for 
troubleshooting. Let me take a look at the logs and get back to you.

> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
> Attachments: fail.log, stdout, stdout
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+153) - Build # 18881 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/
Java: 32bit/jdk-9-ea+153 -client -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  'X val changed' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"", "path":"/test1", "httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":null},  from 
server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val changed' for 
path 'x' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":null},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:39F67B716C5FB010]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:249)
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:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10053:


One of those fails looks like a RAM resource issue.

The more interesting one is:
{noformat}
   [junit4] FAILURE 0.20s | 
TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<200> but 
was:<404>
{noformat}

> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
> Attachments: fail.log, stdout, stdout
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-10053:
---
Attachment: stdout

> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
> Attachments: fail.log, stdout, stdout
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-10053:
---
Attachment: stdout

> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
> Attachments: fail.log, stdout, stdout
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10053:


I still seem to see fails even with the patch. Two fail logs attached.

> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
> Attachments: fail.log
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (LUCENE-7671) Enhance UpgradeIndexMergePolicy with additional options

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7671:


GitHub user kelaban opened a pull request:

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

LUCENE-7671 - Enhance UpgradeIndexMergePolicy with additional options

Also updates Backwards compatibility tests

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kelaban/lucene-solr 
jira/master/LUCENE-7671/upgrading-merge-policy

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/151.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #151


commit c0120745617cbd50a920338cb83e751b9a26963e
Author: Keith Laban 
Date:   2017-01-25T17:08:22Z

LUCENE-7671 - Enhance UpgradeIndexMergePolicy with additional options




> Enhance UpgradeIndexMergePolicy with additional options
> ---
>
> Key: LUCENE-7671
> URL: https://issues.apache.org/jira/browse/LUCENE-7671
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Keith Laban
>
> Enhance UpgradeIndexMergePolicy to be a MergePolicy that can be used outside 
> the scope the IndexUpgrader.
> The enhancement aims to allow the UpgradeIndexMergePolicy to:
> 1) Delegate normal force merges to the underlying merge policy
> 2) Enable a flag that will explicitly tell UpgradeIndexMergePolicy when it 
> should start looking for upgrades.
> 3) Allow new segments to be considered to be merged with old segments, 
> depending on underlying MergePolicy.
> 4) Be configurable for backwards compatibility such that only segments 
> needing an upgrade would be considered when merging, no explicit upgrades.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] lucene-solr pull request #151: LUCENE-7671 - Enhance UpgradeIndexMergePolicy...

[kelaban]

GitHub user kelaban opened a pull request:

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

LUCENE-7671 - Enhance UpgradeIndexMergePolicy with additional options

Also updates Backwards compatibility tests

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kelaban/lucene-solr 
jira/master/LUCENE-7671/upgrading-merge-policy

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/151.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #151


commit c0120745617cbd50a920338cb83e751b9a26963e
Author: Keith Laban 
Date:   2017-01-25T17:08:22Z

LUCENE-7671 - Enhance UpgradeIndexMergePolicy with additional options




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] (LUCENE-7671) Enhance UpgradeIndexMergePolicy with additional options

[Keith Laban (JIRA)]

Keith Laban created LUCENE-7671:
---

 Summary: Enhance UpgradeIndexMergePolicy with additional options
 Key: LUCENE-7671
 URL: https://issues.apache.org/jira/browse/LUCENE-7671
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Keith Laban


Enhance UpgradeIndexMergePolicy to be a MergePolicy that can be used outside 
the scope the IndexUpgrader.

The enhancement aims to allow the UpgradeIndexMergePolicy to:

1) Delegate normal force merges to the underlying merge policy
2) Enable a flag that will explicitly tell UpgradeIndexMergePolicy when it 
should start looking for upgrades.
3) Allow new segments to be considered to be merged with old segments, 
depending on underlying MergePolicy.
4) Be configurable for backwards compatibility such that only segments needing 
an upgrade would be considered when merging, no explicit upgrades.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-9764) Design a memory efficient DocSet if a query returns all docs

[Yonik Seeley (JIRA)]

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

Yonik Seeley resolved SOLR-9764.

   Resolution: Fixed
 Assignee: Yonik Seeley
Fix Version/s: master (7.0)
   6.5

Committed, thanks!

> Design a memory efficient DocSet if a query returns all docs
> 
>
> Key: SOLR-9764
> URL: https://issues.apache.org/jira/browse/SOLR-9764
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Michael Sun
>Assignee: Yonik Seeley
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR_9764_no_cloneMe.patch, SOLR-9764.patch, 
> SOLR-9764.patch, SOLR-9764.patch, SOLR-9764.patch, SOLR-9764.patch, 
> SOLR-9764.patch, SOLR-9764.patch, SOLR-9764.patch
>
>
> In some use cases, particularly use cases with time series data, using 
> collection alias and partitioning data into multiple small collections using 
> timestamp, a filter query can match all documents in a collection. Currently 
> BitDocSet is used which contains a large array of long integers with every 
> bits set to 1. After querying, the resulted DocSet saved in filter cache is 
> large and becomes one of the main memory consumers in these use cases.
> For example. suppose a Solr setup has 14 collections for data in last 14 
> days, each collection with one day of data. A filter query for last one week 
> data would result in at least six DocSet in filter cache which matches all 
> documents in six collections respectively.   
> This is to design a new DocSet that is memory efficient for such a use case.  
> The new DocSet removes the large array, reduces memory usage and GC pressure 
> without losing advantage of large filter cache.
> In particular, for use cases when using time series data, collection alias 
> and partition data into multiple small collections using timestamp, the gain 
> can be large.
> For further optimization, it may be helpful to design a DocSet with run 
> length encoding. Thanks [~mmokhtar] for suggestion. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10024) If you use ExternalPaths#determineSourceHome with a custom tests.workDir, tests may not find the path.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10024:


Commit 98a5a8137826c73a72fef1d198c775d72310176f in lucene-solr's branch 
refs/heads/master from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=98a5a81 ]

SOLR-10024: If you use ExternalPaths#determineSourceHome with a custom 
tests.workDir, tests may not find the path.


> If you use ExternalPaths#determineSourceHome with a custom tests.workDir, 
> tests may not find the path.
> --
>
> Key: SOLR-10024
> URL: https://issues.apache.org/jira/browse/SOLR-10024
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-10024.patch
>
>
> As the comments say, this is already kind of an ugly hack, and if you change 
> the test working dir it won't be able to find the source tree and a slew of 
> tests won't work. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-9764) Design a memory efficient DocSet if a query returns all docs

[ASF subversion and git services (JIRA)]

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

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

Commit 6a3d7bf37f1b0b6a6ec03ecc20367f8a121ddb81 in lucene-solr's branch 
refs/heads/branch_6x from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6a3d7bf ]

SOLR-9764: share liveDocs for any DocSet of size numDocs


> Design a memory efficient DocSet if a query returns all docs
> 
>
> Key: SOLR-9764
> URL: https://issues.apache.org/jira/browse/SOLR-9764
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Michael Sun
> Attachments: SOLR_9764_no_cloneMe.patch, SOLR-9764.patch, 
> SOLR-9764.patch, SOLR-9764.patch, SOLR-9764.patch, SOLR-9764.patch, 
> SOLR-9764.patch, SOLR-9764.patch, SOLR-9764.patch
>
>
> In some use cases, particularly use cases with time series data, using 
> collection alias and partitioning data into multiple small collections using 
> timestamp, a filter query can match all documents in a collection. Currently 
> BitDocSet is used which contains a large array of long integers with every 
> bits set to 1. After querying, the resulted DocSet saved in filter cache is 
> large and becomes one of the main memory consumers in these use cases.
> For example. suppose a Solr setup has 14 collections for data in last 14 
> days, each collection with one day of data. A filter query for last one week 
> data would result in at least six DocSet in filter cache which matches all 
> documents in six collections respectively.   
> This is to design a new DocSet that is memory efficient for such a use case.  
> The new DocSet removes the large array, reduces memory usage and GC pressure 
> without losing advantage of large filter cache.
> In particular, for use cases when using time series data, collection alias 
> and partition data into multiple small collections using timestamp, the gain 
> can be large.
> For further optimization, it may be helpful to design a DocSet with run 
> length encoding. Thanks [~mmokhtar] for suggestion. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Disable HTML mails

[Chris Hostetter]

: Regarding html vs text mails, Daniel Gruno from infra team informed me that:
: "This was a temporary glitch in JIRA. It's just been fixed, everything
: should be back to normal again."

FWIW: recent jira emails seem to be back to plain text, but the subject 
formatting to know what the action was still isn't consistent with what we 
had before for -- making it harder to tell at a glance when issues are 
resolved/closed...

Old Subjects...
Subject: [jira] [Created] (LUCENE-7664) Deprecate GeoPointField & queries


Current Subjects...
Subject: [jira] (LUCENE-7664) Deprecate GeoPointField & queries




: 
: On Tue, Jan 31, 2017 at 8:52 PM, Adrien Grand  wrote:
: 
: > +1 to Steve's point
: >
: > Le mar. 31 janv. 2017 à 16:19, Steve Rowe  a écrit :
: >
: >> My opinion is that majority vote is the wrong model here.  HTML looks
: >> prettier for some while making it painful for others to participate.  This
: >> is a no-brainer.  We should switch back to text immediately.  We should
: >> actively widen access, not the reverse.
: >>
: >> --
: >> Steve
: >> www.lucidworks.com
: >>
: >> On Tue, Jan 31, 2017 at 10:00 AM Christine Poerschke (BLOOMBERG/ LONDON) <
: >> cpoersc...@bloomberg.net> wrote:
: >>
: >> +1 for text.
: >>
: >> From: dev@lucene.apache.org At: 01/31/17 14:56:51
: >> To: dev@lucene.apache.org
: >> Subject: RE: Disable HTML mails
: >>
: >> Yes,
: >>
: >>
: >>
: >> that was meant as a majority vote, or not? Vetoing makes no sense here!
: >>
: >>
: >>
: >> Uwe
: >>
: >>
: >>
: >> -
: >>
: >> Uwe Schindler
: >>
: >> Achterdiek 19, D-28357 Bremen
: >>
: >> http://www.thetaphi.de
: >>
: >> eMail: u...@thetaphi.de
: >>
: >>
: >>
: >> *From:* David Smiley [mailto:david.w.smi...@gmail.com]
: >> *Sent:* Tuesday, January 31, 2017 3:53 PM
: >> *To:* dev@lucene.apache.org
: >> *Subject:* Re: Disable HTML mails
: >>
: >>
: >>
: >> I was wondering the same thing.  I think this should be a majority
: >> preference thing.
: >>
: >>
: >>
: >> On Tue, Jan 31, 2017 at 8:37 AM Ishan Chattopadhyaya <
: >> ichattopadhy...@gmail.com> wrote:
: >>
: >> Hi Uwe,
: >>
: >>
: >>
: >> > It sends mails to the dev@lao mailing list in HTML
: >>
: >> Thanks for the explanation, it makes sense.
: >>
: >> > -1 for TEXT
: >>
: >> Is that a veto? If not, does a voting, to determine what works for most,
: >> make sense?
: >>
: >>
: >>
: >> Regards,
: >>
: >> Ishan
: >>
: >>
: >>
: >> On Mon, Jan 30, 2017 at 11:43 PM, Uwe Schindler  wrote:
: >>
: >> Hi,
: >>
: >> -1 for TEXT
: >> +1 for HTML
: >>
: >> I am very used to the fact of having HTML mails for all JIRA systems I
: >> work with, so I was happy that ASF suddenly sent them as HTML (funny: I did
: >> not even notice).
: >>
: >> Uwe
: >>
: >> -
: >> Uwe Schindler
: >> Achterdiek 19, D-28357 Bremen
: >> http://www.thetaphi.de
: >> eMail: u...@thetaphi.de
: >>
: >> > -Original Message-
: >> > From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
: >> > Sent: Monday, January 30, 2017 6:26 PM
: >> > To: dev@lucene.apache.org
: >> > Subject: RE: Disable HTML mails
: >> >
: >> >
: >> >
: >> > : It sends mails to the dev@lao mailing list in HTML (which I really
: >> > : like!), but you can still configure the ones sent to yourself as TXT
: >> > : only. Not sure how to change the mailing list ones to be text only!
: >> >
: >> > I agree with ishan -- the new HTML formatted mails to the list are
: >> pretty
: >> > much impossible for me to read in my mail client.
: >> >
: >> > They are also now about 5X larger then before for a single one line
: >> > comment, and the subject formatting is completely broken and no longer
: >> > includes the Created/Commented/Resolved/Closed action details.
: >> >
: >> > If it's at all possible to get infra to change this back, then i am
: >> > absolutely +1 to doing so for the jira emails to dev@
: >> >
: >> >
: >> > -Hoss
: >> > http://www.lucidworks.com/
: >> >
: >> > -
: >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: >> > For additional commands, e-mail: dev-h...@lucene.apache.org
: >>
: >>
: >> -
: >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: >> For additional commands, e-mail: dev-h...@lucene.apache.org
: >>
: >>
: >>
: >> --
: >>
: >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
: >>
: >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
: >> solrenterprisesearchserver.com
: >>
: >>
: 

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

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

[jira] (SOLR-10078) `Unknown query type:org.apache.lucene.search.MatchNoDocsQuery` error with Solr v6.3

[Andy Tran (JIRA)]

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

Andy Tran updated SOLR-10078:
-
Description: 
With Solr v6.3, when I issue this query:

http://localhost:8983/solr/BestBuy/select?wt=json=10={!complexphrase%20inOrder=false}_text_:%22maytag~%20(refri~%20OR%20refri*)%20%22=id=true=false=60=nameX,shortDescription,longDescription,artistName,type,manufacturer,department

I get this error in the JSON response:

*
{
  "responseHeader": {
"zkConnected": true,
"status": 500,
"QTime": 8,
"params": {
  "q": "{!complexphrase inOrder=false}_text_:\"maytag~ (refri~ OR refri*) 
\"",
  "hl": "true",
  "hl.preserveMulti": "false",
  "fl": "id",
  "hl.fragsize": "60",
  "hl.fl": 
"nameX,shortDescription,longDescription,artistName,type,manufacturer,department",
  "rows": "10",
  "wt": "json"
}
  },
  "response": {
"numFound": 2,
"start": 0,
"docs": [
  {
"id": "5411379"
  },
  {
"id": "5411404"
  }
]
  },
  "error": {
"msg": "Unknown query type:org.apache.lucene.search.MatchNoDocsQuery",
"trace": "java.lang.IllegalArgumentException: Unknown query 
type:org.apache.lucene.search.MatchNoDocsQuery\n\tat 
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser$ComplexPhraseQuery.addComplexPhraseClause(ComplexPhraseQueryParser.java:388)\n\tat
 
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser$ComplexPhraseQuery.rewrite(ComplexPhraseQueryParser.java:289)\n\tat
 
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.extract(WeightedSpanTermExtractor.java:230)\n\tat
 
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.getWeightedSpanTerms(WeightedSpanTermExtractor.java:522)\n\tat
 
org.apache.lucene.search.highlight.QueryScorer.initExtractor(QueryScorer.java:218)\n\tat
 
org.apache.lucene.search.highlight.QueryScorer.init(QueryScorer.java:186)\n\tat 
org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:195)\n\tat
 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:602)\n\tat
 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingOfField(DefaultSolrHighlighter.java:448)\n\tat
 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:410)\n\tat
 
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:141)\n\tat
 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)\n\tat
 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)\n\tat
 org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)\n\tat 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)\n\tat 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)\n\tat 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)\n\tat
 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
 org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\n\tat
 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat
 org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)\n\tat
 

[jira] (SOLR-10078) "Unknown query type:org.apache.lucene.search.MatchNoDocsQuery" error with Solr v6.3

[Andy Tran (JIRA)]

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

Andy Tran updated SOLR-10078:
-
Summary: "Unknown query type:org.apache.lucene.search.MatchNoDocsQuery" 
error with Solr v6.3  (was: `Unknown query 
type:org.apache.lucene.search.MatchNoDocsQuery` error with Solr v6.3)

> "Unknown query type:org.apache.lucene.search.MatchNoDocsQuery" error with 
> Solr v6.3
> ---
>
> Key: SOLR-10078
> URL: https://issues.apache.org/jira/browse/SOLR-10078
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Andy Tran
>Priority: Minor
>
> With Solr v6.3, when I issue this query:
> http://localhost:8983/solr/BestBuy/select?wt=json=10={!complexphrase%20inOrder=false}_text_:%22maytag~%20(refri~%20OR%20refri*)%20%22=id=true=false=60=nameX,shortDescription,longDescription,artistName,type,manufacturer,department
> I get this error in the JSON response:
> *
> {
>   "responseHeader": {
> "zkConnected": true,
> "status": 500,
> "QTime": 8,
> "params": {
>   "q": "{!complexphrase inOrder=false}_text_:\"maytag~ (refri~ OR refri*) 
> \"",
>   "hl": "true",
>   "hl.preserveMulti": "false",
>   "fl": "id",
>   "hl.fragsize": "60",
>   "hl.fl": 
> "nameX,shortDescription,longDescription,artistName,type,manufacturer,department",
>   "rows": "10",
>   "wt": "json"
> }
>   },
>   "response": {
> "numFound": 2,
> "start": 0,
> "docs": [
>   {
> "id": "5411379"
>   },
>   {
> "id": "5411404"
>   }
> ]
>   },
>   "error": {
> "msg": "Unknown query type:org.apache.lucene.search.MatchNoDocsQuery",
> "trace": "java.lang.IllegalArgumentException: Unknown query 
> type:org.apache.lucene.search.MatchNoDocsQuery\n\tat 
> org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser$ComplexPhraseQuery.addComplexPhraseClause(ComplexPhraseQueryParser.java:388)\n\tat
>  
> org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser$ComplexPhraseQuery.rewrite(ComplexPhraseQueryParser.java:289)\n\tat
>  
> org.apache.lucene.search.highlight.WeightedSpanTermExtractor.extract(WeightedSpanTermExtractor.java:230)\n\tat
>  
> org.apache.lucene.search.highlight.WeightedSpanTermExtractor.getWeightedSpanTerms(WeightedSpanTermExtractor.java:522)\n\tat
>  
> org.apache.lucene.search.highlight.QueryScorer.initExtractor(QueryScorer.java:218)\n\tat
>  
> org.apache.lucene.search.highlight.QueryScorer.init(QueryScorer.java:186)\n\tat
>  
> org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:195)\n\tat
>  
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:602)\n\tat
>  
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingOfField(DefaultSolrHighlighter.java:448)\n\tat
>  
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:410)\n\tat
>  
> org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:141)\n\tat
>  
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)\n\tat
>  org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>  
> 

[jira] (LUCENE-7668) WordDelimiterGraphFilter fails to preserve token type

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-7668.

Resolution: Fixed

Thank you [~thetaphi]!

> WordDelimiterGraphFilter fails to preserve token type
> -
>
> Key: LUCENE-7668
> URL: https://issues.apache.org/jira/browse/LUCENE-7668
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7668.patch, LUCENE-7668.patch, LUCENE-7668.patch
>
>
> It is supposed to preserve the incoming token type to all its output tokens 
> but now it's always setting to the default {{word}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-10078) `Unknown query type:org.apache.lucene.search.MatchNoDocsQuery` error with Solr v6.3

[Andy Tran (JIRA)]

Andy Tran created SOLR-10078:


 Summary: `Unknown query 
type:org.apache.lucene.search.MatchNoDocsQuery` error with Solr v6.3
 Key: SOLR-10078
 URL: https://issues.apache.org/jira/browse/SOLR-10078
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.3
Reporter: Andy Tran
Priority: Minor


With Solr v6.3, when I issue this query:

http://localhost:8983/solr/BestBuy/select?wt=json=10={!complexphrase%20inOrder=false}_text_:%22maytag~%20(refri~%20OR%20refri*)%20%22=id=true=false=60=nameX,shortDescription,longDescription,artistName,type,manufacturer,department

I get this error in the JSON response:

{
  "responseHeader": {
"zkConnected": true,
"status": 500,
"QTime": 8,
"params": {
  "q": "{!complexphrase inOrder=false}_text_:\"maytag~ (refri~ OR refri*) 
\"",
  "hl": "true",
  "hl.preserveMulti": "false",
  "fl": "id",
  "hl.fragsize": "60",
  "hl.fl": 
"nameX,shortDescription,longDescription,artistName,type,manufacturer,department",
  "rows": "10",
  "wt": "json"
}
  },
  "response": {
"numFound": 2,
"start": 0,
"docs": [
  {
"id": "5411379"
  },
  {
"id": "5411404"
  }
]
  },
  "error": {
"msg": "Unknown query type:org.apache.lucene.search.MatchNoDocsQuery",
"trace": "java.lang.IllegalArgumentException: Unknown query 
type:org.apache.lucene.search.MatchNoDocsQuery\n\tat 
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser$ComplexPhraseQuery.addComplexPhraseClause(ComplexPhraseQueryParser.java:388)\n\tat
 
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser$ComplexPhraseQuery.rewrite(ComplexPhraseQueryParser.java:289)\n\tat
 
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.extract(WeightedSpanTermExtractor.java:230)\n\tat
 
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.getWeightedSpanTerms(WeightedSpanTermExtractor.java:522)\n\tat
 
org.apache.lucene.search.highlight.QueryScorer.initExtractor(QueryScorer.java:218)\n\tat
 
org.apache.lucene.search.highlight.QueryScorer.init(QueryScorer.java:186)\n\tat 
org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:195)\n\tat
 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:602)\n\tat
 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingOfField(DefaultSolrHighlighter.java:448)\n\tat
 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:410)\n\tat
 
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:141)\n\tat
 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)\n\tat
 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)\n\tat
 org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)\n\tat 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)\n\tat 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)\n\tat 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)\n\tat
 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
 org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\n\tat
 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat
 org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat 

[jira] (LUCENE-7668) WordDelimiterGraphFilter fails to preserve token type

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7668: add new test case; remove dead code; improve CannedTokenStream to 
copy all Token attributes


> WordDelimiterGraphFilter fails to preserve token type
> -
>
> Key: LUCENE-7668
> URL: https://issues.apache.org/jira/browse/LUCENE-7668
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7668.patch, LUCENE-7668.patch, LUCENE-7668.patch
>
>
> It is supposed to preserve the incoming token type to all its output tokens 
> but now it's always setting to the default {{word}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (LUCENE-7668) WordDelimiterGraphFilter fails to preserve token type

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7668: add new test case; remove dead code; improve CannedTokenStream to 
copy all Token attributes


> WordDelimiterGraphFilter fails to preserve token type
> -
>
> Key: LUCENE-7668
> URL: https://issues.apache.org/jira/browse/LUCENE-7668
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7668.patch, LUCENE-7668.patch, LUCENE-7668.patch
>
>
> It is supposed to preserve the incoming token type to all its output tokens 
> but now it's always setting to the default {{word}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-9764) Design a memory efficient DocSet if a query returns all docs

[ASF subversion and git services (JIRA)]

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

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

Commit a43ef8f480c6a32dd77e43d02c2dca2299a05eb3 in lucene-solr's branch 
refs/heads/master from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a43ef8f ]

SOLR-9764: share liveDocs for any DocSet of size numDocs


> Design a memory efficient DocSet if a query returns all docs
> 
>
> Key: SOLR-9764
> URL: https://issues.apache.org/jira/browse/SOLR-9764
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Michael Sun
> Attachments: SOLR_9764_no_cloneMe.patch, SOLR-9764.patch, 
> SOLR-9764.patch, SOLR-9764.patch, SOLR-9764.patch, SOLR-9764.patch, 
> SOLR-9764.patch, SOLR-9764.patch, SOLR-9764.patch
>
>
> In some use cases, particularly use cases with time series data, using 
> collection alias and partitioning data into multiple small collections using 
> timestamp, a filter query can match all documents in a collection. Currently 
> BitDocSet is used which contains a large array of long integers with every 
> bits set to 1. After querying, the resulted DocSet saved in filter cache is 
> large and becomes one of the main memory consumers in these use cases.
> For example. suppose a Solr setup has 14 collections for data in last 14 
> days, each collection with one day of data. A filter query for last one week 
> data would result in at least six DocSet in filter cache which matches all 
> documents in six collections respectively.   
> This is to design a new DocSet that is memory efficient for such a use case.  
> The new DocSet removes the large array, reduces memory usage and GC pressure 
> without losing advantage of large filter cache.
> In particular, for use cases when using time series data, collection alias 
> and partition data into multiple small collections using timestamp, the gain 
> can be large.
> For further optimization, it may be helpful to design a DocSet with run 
> length encoding. Thanks [~mmokhtar] for suggestion. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Disable HTML mails

[Ishan Chattopadhyaya]

Regarding html vs text mails, Daniel Gruno from infra team informed me that:
"This was a temporary glitch in JIRA. It's just been fixed, everything
should be back to normal again."

On Tue, Jan 31, 2017 at 8:52 PM, Adrien Grand  wrote:

> +1 to Steve's point
>
> Le mar. 31 janv. 2017 à 16:19, Steve Rowe  a écrit :
>
>> My opinion is that majority vote is the wrong model here.  HTML looks
>> prettier for some while making it painful for others to participate.  This
>> is a no-brainer.  We should switch back to text immediately.  We should
>> actively widen access, not the reverse.
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>> On Tue, Jan 31, 2017 at 10:00 AM Christine Poerschke (BLOOMBERG/ LONDON) <
>> cpoersc...@bloomberg.net> wrote:
>>
>> +1 for text.
>>
>> From: dev@lucene.apache.org At: 01/31/17 14:56:51
>> To: dev@lucene.apache.org
>> Subject: RE: Disable HTML mails
>>
>> Yes,
>>
>>
>>
>> that was meant as a majority vote, or not? Vetoing makes no sense here!
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* David Smiley [mailto:david.w.smi...@gmail.com]
>> *Sent:* Tuesday, January 31, 2017 3:53 PM
>> *To:* dev@lucene.apache.org
>> *Subject:* Re: Disable HTML mails
>>
>>
>>
>> I was wondering the same thing.  I think this should be a majority
>> preference thing.
>>
>>
>>
>> On Tue, Jan 31, 2017 at 8:37 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>> Hi Uwe,
>>
>>
>>
>> > It sends mails to the dev@lao mailing list in HTML
>>
>> Thanks for the explanation, it makes sense.
>>
>> > -1 for TEXT
>>
>> Is that a veto? If not, does a voting, to determine what works for most,
>> make sense?
>>
>>
>>
>> Regards,
>>
>> Ishan
>>
>>
>>
>> On Mon, Jan 30, 2017 at 11:43 PM, Uwe Schindler  wrote:
>>
>> Hi,
>>
>> -1 for TEXT
>> +1 for HTML
>>
>> I am very used to the fact of having HTML mails for all JIRA systems I
>> work with, so I was happy that ASF suddenly sent them as HTML (funny: I did
>> not even notice).
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> > -Original Message-
>> > From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
>> > Sent: Monday, January 30, 2017 6:26 PM
>> > To: dev@lucene.apache.org
>> > Subject: RE: Disable HTML mails
>> >
>> >
>> >
>> > : It sends mails to the dev@lao mailing list in HTML (which I really
>> > : like!), but you can still configure the ones sent to yourself as TXT
>> > : only. Not sure how to change the mailing list ones to be text only!
>> >
>> > I agree with ishan -- the new HTML formatted mails to the list are
>> pretty
>> > much impossible for me to read in my mail client.
>> >
>> > They are also now about 5X larger then before for a single one line
>> > comment, and the subject formatting is completely broken and no longer
>> > includes the Created/Commented/Resolved/Closed action details.
>> >
>> > If it's at all possible to get infra to change this back, then i am
>> > absolutely +1 to doing so for the jira emails to dev@
>> >
>> >
>> > -Hoss
>> > http://www.lucidworks.com/
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>>
>> --
>>
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
>> solrenterprisesearchserver.com
>>
>>

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-10053 at 1/31/17 4:43 PM:
--

[~hgadre], I'll try to beast the test using your patch with Mark's "The best 
Lucene / Solr beasting script in the world. TM."


was (Author: ichattopadhyaya):
[~hgadre], I'll try to beast the test using your patch with Mark's "the most 
awesome beasting script ever TM" (or similarly named, forgot exactly).

> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
> Attachments: fail.log
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (SOLR-8581) Integration tests for rolling upgrades

[Kevin Risden (JIRA)]

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

Kevin Risden edited comment on SOLR-8581 at 1/31/17 4:43 PM:
-

I threw together an example of doing this with released versions of Solr.

https://github.com/risdenk/solr_upgrade_test

It avoids using Java for the automation just because it was easier to write in 
Python to start. It doesn't do replacing of jar and instead uses the release 
directly. There are generated configs for every version from 5.0.0 to 6.4.0 and 
every version in between. It is easy to add another version with a config file 
just need a URL to a release.


was (Author: risdenk):
I threw together an example of doing this with released versions of Solr.

https://github.com/risdenk/solr_upgrade_test

It avoids using Java just because it was easier to write in Python to start. It 
doesn't do replacing of jar and instead uses the release directly. There are 
generated configs for every version from 5.0.0 to 6.4.0 and every version in 
between. It is easy to add another version with a config file just need a URL 
to a release.

>  Integration tests for rolling upgrades
> ---
>
> Key: SOLR-8581
> URL: https://issues.apache.org/jira/browse/SOLR-8581
> Project: Solr
>  Issue Type: Test
>Reporter: Vivek Narang
>
> I intend to work on an integration test suite for Solr, to test for issues to 
> deal with back compat, rolling upgrades etc.
> The interface for the test suite, as I'm planning, would be to have it accept 
> two versions of Solr (either released versions or trunk/branch).
> I work on SolrCloud, and we need something like this to enable us to upgrade 
> more frequently. I had a conversation with @Ishan Chattopadhyaya, who 
> emphasised to me the need to have something like this.
> If there's already any ongoing effort in doing this, I can help out there. 
> Please let me know.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] (LUCENE-7650) Complexphrase queryparser stumbles on phrase query with trailing escaped colon

[Otmar Caduff (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Otmar Caduff commented on  LUCENE-7650 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Complexphrase queryparser stumbles on phrase query with trailing escaped colon  
 
 
 
 
 
 
 
 
 
 
Thanks! That helped. Not an issue anymore for me. I think it would make sense to add to ComplexPhraseQueryParser's javadoc the following comment (or something alike): 
 
Special care has to be given when escaping: because some parts of the query might be parsed multiple times, these parts have to be escaped as often.
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

VOTE: Apache Solr Ref Guide for 6.4

[Cassandra Targett]

Please vote to release the Apache Solr Ref Guide for Solr 6.4.

Artifacts can be found at:
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.4-RC0/

$ cat apache-solr-ref-guide-6.4-RC0/apache-solr-ref-guide-6.4.pdf.sha1
2e5f27c1aae36fde5717dd01a4495c5e299c9407  apache-solr-ref-guide-6.4.pdf

I'm not a huge fan of releasing with issues found at the last minute
such as the one Erick E filed last night (SOLR-10061, about issues
with the CoreAdmin API docs), but in this case I have a bunch of other
stuff to do this week & next at the day job, I don't know the
CoreAdmin API that well, and when SOLR-8029 (v2 API) is backported to
6.x, we will likely revamp ALL of the API pages, including that one.

So, that said, here's +1 from me.

Cassandra

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

[jira] (SOLR-8581) Integration tests for rolling upgrades

[Kevin Risden (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Kevin Risden edited a comment on  SOLR-8581 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Integration tests for rolling upgrades  
 
 
 
 
 
 
 
 
 
 It should  not  now  be testing against master and 6.x last successful builds.  
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-8581) Integration tests for rolling upgrades

[Kevin Risden (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Kevin Risden commented on  SOLR-8581 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Integration tests for rolling upgrades  
 
 
 
 
 
 
 
 
 
 
It should not be testing against master and 6.x last successful builds.  
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-8581) Integration tests for rolling upgrades

[Kevin Risden (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Kevin Risden commented on  SOLR-8581 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Integration tests for rolling upgrades  
 
 
 
 
 
 
 
 
 
 
I setup a Travis CI build to run daily against 6.4.0 to the latest nightly. It probably makes sense to point at the 6x branch instead of master but its a start. 
https://travis-ci.org/risdenk/solr_upgrade_test 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

Re: Disable HTML mails

[Adrien Grand]

+1 to Steve's point

Le mar. 31 janv. 2017 à 16:19, Steve Rowe  a écrit :

> My opinion is that majority vote is the wrong model here.  HTML looks
> prettier for some while making it painful for others to participate.  This
> is a no-brainer.  We should switch back to text immediately.  We should
> actively widen access, not the reverse.
>
> --
> Steve
> www.lucidworks.com
>
> On Tue, Jan 31, 2017 at 10:00 AM Christine Poerschke (BLOOMBERG/ LONDON) <
> cpoersc...@bloomberg.net> wrote:
>
> +1 for text.
>
> From: dev@lucene.apache.org At: 01/31/17 14:56:51
> To: dev@lucene.apache.org
> Subject: RE: Disable HTML mails
>
> Yes,
>
>
>
> that was meant as a majority vote, or not? Vetoing makes no sense here!
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* David Smiley [mailto:david.w.smi...@gmail.com]
> *Sent:* Tuesday, January 31, 2017 3:53 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: Disable HTML mails
>
>
>
> I was wondering the same thing.  I think this should be a majority
> preference thing.
>
>
>
> On Tue, Jan 31, 2017 at 8:37 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
> Hi Uwe,
>
>
>
> > It sends mails to the dev@lao mailing list in HTML
>
> Thanks for the explanation, it makes sense.
>
> > -1 for TEXT
>
> Is that a veto? If not, does a voting, to determine what works for most,
> make sense?
>
>
>
> Regards,
>
> Ishan
>
>
>
> On Mon, Jan 30, 2017 at 11:43 PM, Uwe Schindler  wrote:
>
> Hi,
>
> -1 for TEXT
> +1 for HTML
>
> I am very used to the fact of having HTML mails for all JIRA systems I
> work with, so I was happy that ASF suddenly sent them as HTML (funny: I did
> not even notice).
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
> > Sent: Monday, January 30, 2017 6:26 PM
> > To: dev@lucene.apache.org
> > Subject: RE: Disable HTML mails
> >
> >
> >
> > : It sends mails to the dev@lao mailing list in HTML (which I really
> > : like!), but you can still configure the ones sent to yourself as TXT
> > : only. Not sure how to change the mailing list ones to be text only!
> >
> > I agree with ishan -- the new HTML formatted mails to the list are pretty
> > much impossible for me to read in my mail client.
> >
> > They are also now about 5X larger then before for a single one line
> > comment, and the subject formatting is completely broken and no longer
> > includes the Created/Commented/Resolved/Closed action details.
> >
> > If it's at all possible to get infra to change this back, then i am
> > absolutely +1 to doing so for the jira emails to dev@
> >
> >
> > -Hoss
> > http://www.lucidworks.com/
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
>
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>

[jira] (SOLR-10061) Core admin API documentation needs to be updated

[Cassandra Targett (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Cassandra Targett updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10061 
 
 
 
  Core admin API documentation needs to be updated  
 
 
 
 
 
 
 
 
 

Change By:
 
 Cassandra Targett 
 
 
 

Component/s:
 
 documentation 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

Re: Disable HTML mails

[Steve Rowe]

My opinion is that majority vote is the wrong model here.  HTML looks
prettier for some while making it painful for others to participate.  This
is a no-brainer.  We should switch back to text immediately.  We should
actively widen access, not the reverse.

--
Steve
www.lucidworks.com

On Tue, Jan 31, 2017 at 10:00 AM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> +1 for text.
>
> From: dev@lucene.apache.org At: 01/31/17 14:56:51
> To: dev@lucene.apache.org
> Subject: RE: Disable HTML mails
>
> Yes,
>
>
>
> that was meant as a majority vote, or not? Vetoing makes no sense here!
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* David Smiley [mailto:david.w.smi...@gmail.com]
> *Sent:* Tuesday, January 31, 2017 3:53 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: Disable HTML mails
>
>
>
> I was wondering the same thing.  I think this should be a majority
> preference thing.
>
>
>
> On Tue, Jan 31, 2017 at 8:37 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
> Hi Uwe,
>
>
>
> > It sends mails to the dev@lao mailing list in HTML
>
> Thanks for the explanation, it makes sense.
>
> > -1 for TEXT
>
> Is that a veto? If not, does a voting, to determine what works for most,
> make sense?
>
>
>
> Regards,
>
> Ishan
>
>
>
> On Mon, Jan 30, 2017 at 11:43 PM, Uwe Schindler  wrote:
>
> Hi,
>
> -1 for TEXT
> +1 for HTML
>
> I am very used to the fact of having HTML mails for all JIRA systems I
> work with, so I was happy that ASF suddenly sent them as HTML (funny: I did
> not even notice).
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
> > Sent: Monday, January 30, 2017 6:26 PM
> > To: dev@lucene.apache.org
> > Subject: RE: Disable HTML mails
> >
> >
> >
> > : It sends mails to the dev@lao mailing list in HTML (which I really
> > : like!), but you can still configure the ones sent to yourself as TXT
> > : only. Not sure how to change the mailing list ones to be text only!
> >
> > I agree with ishan -- the new HTML formatted mails to the list are pretty
> > much impossible for me to read in my mail client.
> >
> > They are also now about 5X larger then before for a single one line
> > comment, and the subject formatting is completely broken and no longer
> > includes the Created/Commented/Resolved/Closed action details.
> >
> > If it's at all possible to get infra to change this back, then i am
> > absolutely +1 to doing so for the jira emails to dev@
> >
> >
> > -Hoss
> > http://www.lucidworks.com/
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
>
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Ishan Chattopadhyaya (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ishan Chattopadhyaya commented on  SOLR-10053 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: TestSolrCloudWithDelegationTokens failures  
 
 
 
 
 
 
 
 
 
 
Hrishikesh Gadre, I'll try to beast the test using your patch with Mark's "the most awesome beasting script ever TM" (or similarly named, forgot exactly). 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Mark Miller (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Mark Miller updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10053 
 
 
 
  TestSolrCloudWithDelegationTokens failures  
 
 
 
 
 
 
 
 
 
 
Failed run log attached. 
 
 
 
 
 
 
 
 
 

Change By:
 
 Mark Miller 
 
 
 

Attachment:
 
 fail.log 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7444) Remove StopFilter from StandardAnalyzer in Lucene-Core

[Alan Woodward (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Alan Woodward commented on  LUCENE-7444 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Remove StopFilter from StandardAnalyzer in Lucene-Core  
 
 
 
 
 
 
 
 
 
 
All tests pass if I apply the following to master: 

 

diff --git a/lucene/core/src/java/org/apache/lucene/analysis/standard/StandardAnalyzer.java b/lucene/core/src/java/org/apache/lucene/analysis/standard/StandardAnalyzer.java
index fb57573..321cb8e 100644
--- a/lucene/core/src/java/org/apache/lucene/analysis/standard/StandardAnalyzer.java
+++ b/lucene/core/src/java/org/apache/lucene/analysis/standard/StandardAnalyzer.java
@@ -70,7 +70,7 @@ public final class StandardAnalyzer extends StopwordAnalyzerBase {
   /** Builds an analyzer with the default stop words ({@link #STOP_WORDS_SET}).
*/
   public StandardAnalyzer() {
-this(STOP_WORDS_SET);
+this(CharArraySet.EMPTY_SET);
   }

   /** Builds an analyzer with the stop words from the given reader.
 

 
I guess this should be a master-only change? Plus appropriate javadocs and CHANGES mods as well. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Mark Miller (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Mark Miller commented on  SOLR-10053 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: TestSolrCloudWithDelegationTokens failures  
 
 
 
 
 
 
 
 
 
 
In my testing, I found this test to be 'flakey' with 3% of runs failing out of 30. Not so bad, though of course it would be nice to get better. I can upload the test logs for those fails. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10032) Create report to assess Solr test quality at a commit point.

[Mark Miller (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Mark Miller commented on  SOLR-10032 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Create report to assess Solr test quality at a commit point.  
 
 
 
 
 
 
 
 
 
 
One thing that has surprised me is how stable the tests actually are. I ran this on a 16 core machine, but it is also generally 12 of the same test at a time, 12 again, and then 6 at a time. It's a fairly aggressive environment to survive for 30 runs. Given 876 tests, the number that have passed this test is very, very high when you consider the many ignored and nightly tests listed as failed. 
Our jenkins cluster will probably keep finding rarer fails over time, but getting the average developer in good shape looks very tractable. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

RE: Disable HTML mails

[Christine Poerschke (BLOOMBERG/ LONDON)]

+1 for text.

From: dev@lucene.apache.org At: 01/31/17 14:56:51
To: dev@lucene.apache.org
Subject: RE: Disable HTML mails


Yes,
 
that was meant as a majority vote, or not? Vetoing makes no sense here!
 
Uwe
 
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
 

From: David Smiley [mailto:david.w.smi...@gmail.com] 
Sent: Tuesday, January 31, 2017 3:53 PM
To: dev@lucene.apache.org
Subject: Re: Disable HTML mails
 

I was wondering the same thing.  I think this should be a majority preference 
thing.
 

On Tue, Jan 31, 2017 at 8:37 AM Ishan Chattopadhyaya 
 wrote:

Hi Uwe,


> It sends mails to the dev@lao mailing list in HTML

Thanks for the explanation, it makes sense.

> -1 for TEXT
Is that a veto? If not, does a voting, to determine what works for most, make 
sense?

 
Regards,
Ishan

 

On Mon, Jan 30, 2017 at 11:43 PM, Uwe Schindler  wrote:

Hi,

-1 for TEXT
+1 for HTML

I am very used to the fact of having HTML mails for all JIRA systems I work 
with, so I was happy that ASF suddenly sent them as HTML (funny: I did not even 
notice).

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
> Sent: Monday, January 30, 2017 6:26 PM
> To: dev@lucene.apache.org
> Subject: RE: Disable HTML mails
>
>
>
> : It sends mails to the dev@lao mailing list in HTML (which I really
> : like!), but you can still configure the ones sent to yourself as TXT
> : only. Not sure how to change the mailing list ones to be text only!
>
> I agree with ishan -- the new HTML formatted mails to the list are pretty
> much impossible for me to read in my mail client.
>
> They are also now about 5X larger then before for a single one line
> comment, and the subject formatting is completely broken and no longer
> includes the Created/Commented/Resolved/Closed action details.
>
> If it's at all possible to get infra to change this back, then i am
> absolutely +1 to doing so for the jira emails to dev@
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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

 

-- 

Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

RE: Disable HTML mails

[Uwe Schindler]

Yes,

 

that was meant as a majority vote, or not? Vetoing makes no sense here!

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: David Smiley [mailto:david.w.smi...@gmail.com] 
Sent: Tuesday, January 31, 2017 3:53 PM
To: dev@lucene.apache.org
Subject: Re: Disable HTML mails

 

I was wondering the same thing.  I think this should be a majority preference 
thing.

 

On Tue, Jan 31, 2017 at 8:37 AM Ishan Chattopadhyaya  > wrote:

Hi Uwe,



> It sends mails to the dev@lao mailing list in HTML

Thanks for the explanation, it makes sense.

> -1 for TEXT

Is that a veto? If not, does a voting, to determine what works for most, make 
sense?

 

Regards,

Ishan

 

On Mon, Jan 30, 2017 at 11:43 PM, Uwe Schindler  > wrote:

Hi,

-1 for TEXT
+1 for HTML

I am very used to the fact of having HTML mails for all JIRA systems I work 
with, so I was happy that ASF suddenly sent them as HTML (funny: I did not even 
notice).

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de  

> -Original Message-
> From: Chris Hostetter [mailto:hossman_luc...@fucit.org 
>  ]
> Sent: Monday, January 30, 2017 6:26 PM
> To: dev@lucene.apache.org  
> Subject: RE: Disable HTML mails
>
>
>
> : It sends mails to the dev@lao mailing list in HTML (which I really
> : like!), but you can still configure the ones sent to yourself as TXT
> : only. Not sure how to change the mailing list ones to be text only!
>
> I agree with ishan -- the new HTML formatted mails to the list are pretty
> much impossible for me to read in my mail client.
>
> They are also now about 5X larger then before for a single one line
> comment, and the subject formatting is completely broken and no longer
> includes the Created/Commented/Resolved/Closed action details.
>
> If it's at all possible to get infra to change this back, then i am
> absolutely +1 to doing so for the jira emails to dev@
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>  
> For additional commands, e-mail: dev-h...@lucene.apache.org 
>  


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

 

-- 

Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com